Re: RE : draft-vasseur-ccamp-te-router-info-00
Dimitri.Papadimitriou@alcatel.be Fri, 30 July 2004 10:12 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27451 for <ccamp-archive@ietf.org>; Fri, 30 Jul 2004 06:12:44 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqUPm-00050C-4u for ccamp-archive@ietf.org; Fri, 30 Jul 2004 06:15:04 -0400
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqU63-0008zk-BW for ccamp-data@psg.com; Fri, 30 Jul 2004 09:54:39 +0000
Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqU5k-0008sM-Dw; Fri, 30 Jul 2004 09:54:20 +0000
Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i6U9rxZu009699; Fri, 30 Jul 2004 11:53:59 +0200
To: Jean Philippe Vasseur <jvasseur@cisco.com>
Cc: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@francetelecom.com>, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
From: Dimitri.Papadimitriou@alcatel.be
Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00
MIME-Version: 1.0
Date: Fri, 30 Jul 2004 11:53:57 +0200
Message-ID: <OFF6AE66FC.642B5656-ONC1256EE1.003660A2-C1256EE1.003660FE@netfr.alcatel.fr>
X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/30/2004 11:54:02
Content-type: text/plain; charset="us-ascii"
X-Alcanet-MTA-scanned-and-authorized: yes
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
hi jp, see in-line starting with [DP] >[snip] > >>>>>> M bit: Multiple Path Computation. When set, this flag indicates >>>>>> that the PCE is capable of computing more than one path obeying a >>>>>> set of specified constraints (in a single pass), provided that >>>>>> they exist. >>>>> >>>>> [DP] so it is a multi-path, multi-constraint computation ? >>>> >>>> It means that the LSR can compute a set of constrained path in a >>>> coordinated manner. This bit does not indicate wether or not the >>>> PCE can compute paths with multiple additive constaints (also an >>>> NP-Hard problem) like e.g. minimum cost bounded delay paths. This >>>> may require an additional bit. >>> >>> [DP] ok thanks for the clarification; would it be possible then to >>> indicate (or something equivalent at your discretion) >>> >>> "M bit: indicates that the LSR can compute a set of constrained path >>> in a coordinated manner. >>> >>> Note: The M bit does not indicate whether or not the PCE can compute >>> a set of paths with multiple additive constaints (also an NP-Hard >>> problem) like e.g. minimum cost bounded delay paths. This requires >>> an additional bit." >> >> The aim of the M bit is just to mention that the PCE has the ability >> to compute a set of M paths, considering that those paths may have >> different constraints *and* could be related (ex: compute a set of N >> link diverse paths). > > [DP] the interpretation i made from jean-louis response, the draft and > yours is different, at the end the point is to achieve a unique > interpretation we will clarify, adding a few words in the next revision, no pb. [DP] ok - even if i'm not sure one can clarify this with a few words but let us see first what it gives [snip] >>>>> another aspect is to distinguish between multi-AS single carrier >>>>> and multi-AS multi-carrier, and restrict the latter to stringent >>>>> policy rules in terms of AS path considered for LSP >>>> >>>> Yes, but again the goal of this information is more a way to allow >>>> an LSR selecting the appropriate PCE among a set of candidate PCE, >>>> when the computation load is balanced based on the destination AS. >>>> Policy rules for AS-path selection are beyond the scope of this ID, >>>> and should be addressed in separate drafts >>> >>> [DP] i understand that policy for AS path selection is beyond the >>> scope of this document but the relevance of including this >>> information as part of the IGP flooded information should be also >>> clarified at some point in time but outside of the scope of the IGP >>> flooding. > > [DP] well i'd like to make a point clearer in this context it is not > because a specific capability is not related to the flooding mechanism > but only to the carried information that the rationales for carrying > this information shouldn't be provided with a non ambiguous semantic > > in addition it is not because policying of information is outside the > scope of this document that any information should be part of this > document without any discussion well .. .not sure of what you would want to see added there ... Again, AS path selection is out of the scope and not related to IGP flooding which is what this draft is about. [DP] that there is an assumption that there is already a distinction between PCEs in terms of destination AS computation capabilities, while i still do not see what it brings in terms of load balancing wrt to the case the AS path list wouldn't be advertized and assumption is made that those PCEs have the same information (i don't say capability) within a single AS - the discussion shift to a policy issue of using the information i'm still questioning about the relevance and consequence of advertizing it (no assessment provided in the document) >>>>>=> 5.3. Procedure >>>>> >>>>>>The PCE Discovery Information TLV is carried in Link State >>>>>>Advertisements. A router MUST originate a new Link State >>>>>>Advertisement whenever the content of this information changes, or >>>>>>whenever required by regular routing procedure (e.g. refresh) >>>>>>The PCE Discovery Information TLV is optional. >>>>>> >>>>>>If the PCE can compute an intra-area TE LSP path, the L bit MUST >>>>>>be set.If it can compute an intra-area TE LSP path only for the >>>>>>LSRs in the area it resides in, then the PCE Discovery Information >>>>>>must be contained within an area. Otherwise, if the PCE can >>>>>>compute intra-area TE LSP paths for the whole AS, then the PCE >>>>>>Discovery Information TLV must be flooded across the whole AS. >>>>> >>>>>[DP] how do you ensure that LSR's not being part of this area can >>>>>reach the >>>>>PCE (i.e. is there not a reachability constraint to be added here ? >>>>>in particular in case of non-co-located PCE identified by an IP >>>>>address) - i guess this point should be somehow clarified >>>> >>>>A PCE, supporting this draft, either LSR or centralized, will run >>>>the IGP. Thus it will be reacheable. We will clarify this point. >>> >>>[DP] but then you have to ensure that no IP data traffic could reach >>>the centralized PCE (since by definition it will be only capable to >>>process IP control messages request/response, etc.) ie one has to >>>exluce IP data traffic from the corresponding IP control channels >> >>Well, no, it is the choice of the operator to choose a PCE dedicated >>for path computation or to activate the PCE function on an LSR >>forwarding packets. > >[DP] i was discussing the non co-located case which does not get >clarified by your response is there a redirection provided and the LSR >acts as a proxy (or is it not within the scope of this document ?) is your question to know how one can ensure in this case the PCE will not receive any data traffic ? [DP] yes, that's part of the problem raised [snip] thanks, - dimitri. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Jul 2004 09:55:51 +0000 To: Jean Philippe Vasseur <jvasseur@cisco.com> Cc: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@francetelecom.com>, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org From: Dimitri.Papadimitriou@alcatel.be Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00 MIME-Version: 1.0 Date: Fri, 30 Jul 2004 11:53:57 +0200 Message-ID: <OFF6AE66FC.642B5656-ONC1256EE1.003660A2-C1256EE1.003660FE@netfr.alcatel.fr> Content-type: text/plain; charset=us-ascii hi jp, see in-line starting with [DP] >[snip] > >>>>>> M bit: Multiple Path Computation. When set, this flag indicates >>>>>> that the PCE is capable of computing more than one path obeying a >>>>>> set of specified constraints (in a single pass), provided that >>>>>> they exist. >>>>> >>>>> [DP] so it is a multi-path, multi-constraint computation ? >>>> >>>> It means that the LSR can compute a set of constrained path in a >>>> coordinated manner. This bit does not indicate wether or not the >>>> PCE can compute paths with multiple additive constaints (also an >>>> NP-Hard problem) like e.g. minimum cost bounded delay paths. This >>>> may require an additional bit. >>> >>> [DP] ok thanks for the clarification; would it be possible then to >>> indicate (or something equivalent at your discretion) >>> >>> "M bit: indicates that the LSR can compute a set of constrained path >>> in a coordinated manner. >>> >>> Note: The M bit does not indicate whether or not the PCE can compute >>> a set of paths with multiple additive constaints (also an NP-Hard >>> problem) like e.g. minimum cost bounded delay paths. This requires >>> an additional bit." >> >> The aim of the M bit is just to mention that the PCE has the ability >> to compute a set of M paths, considering that those paths may have >> different constraints *and* could be related (ex: compute a set of N >> link diverse paths). > > [DP] the interpretation i made from jean-louis response, the draft and > yours is different, at the end the point is to achieve a unique > interpretation we will clarify, adding a few words in the next revision, no pb. [DP] ok - even if i'm not sure one can clarify this with a few words but let us see first what it gives [snip] >>>>> another aspect is to distinguish between multi-AS single carrier >>>>> and multi-AS multi-carrier, and restrict the latter to stringent >>>>> policy rules in terms of AS path considered for LSP >>>> >>>> Yes, but again the goal of this information is more a way to allow >>>> an LSR selecting the appropriate PCE among a set of candidate PCE, >>>> when the computation load is balanced based on the destination AS. >>>> Policy rules for AS-path selection are beyond the scope of this ID, >>>> and should be addressed in separate drafts >>> >>> [DP] i understand that policy for AS path selection is beyond the >>> scope of this document but the relevance of including this >>> information as part of the IGP flooded information should be also >>> clarified at some point in time but outside of the scope of the IGP >>> flooding. > > [DP] well i'd like to make a point clearer in this context it is not > because a specific capability is not related to the flooding mechanism > but only to the carried information that the rationales for carrying > this information shouldn't be provided with a non ambiguous semantic > > in addition it is not because policying of information is outside the > scope of this document that any information should be part of this > document without any discussion well .. .not sure of what you would want to see added there ... Again, AS path selection is out of the scope and not related to IGP flooding which is what this draft is about. [DP] that there is an assumption that there is already a distinction between PCEs in terms of destination AS computation capabilities, while i still do not see what it brings in terms of load balancing wrt to the case the AS path list wouldn't be advertized and assumption is made that those PCEs have the same information (i don't say capability) within a single AS - the discussion shift to a policy issue of using the information i'm still questioning about the relevance and consequence of advertizing it (no assessment provided in the document) >>>>>=> 5.3. Procedure >>>>> >>>>>>The PCE Discovery Information TLV is carried in Link State >>>>>>Advertisements. A router MUST originate a new Link State >>>>>>Advertisement whenever the content of this information changes, or >>>>>>whenever required by regular routing procedure (e.g. refresh) >>>>>>The PCE Discovery Information TLV is optional. >>>>>> >>>>>>If the PCE can compute an intra-area TE LSP path, the L bit MUST >>>>>>be set.If it can compute an intra-area TE LSP path only for the >>>>>>LSRs in the area it resides in, then the PCE Discovery Information >>>>>>must be contained within an area. Otherwise, if the PCE can >>>>>>compute intra-area TE LSP paths for the whole AS, then the PCE >>>>>>Discovery Information TLV must be flooded across the whole AS. >>>>> >>>>>[DP] how do you ensure that LSR's not being part of this area can >>>>>reach the >>>>>PCE (i.e. is there not a reachability constraint to be added here ? >>>>>in particular in case of non-co-located PCE identified by an IP >>>>>address) - i guess this point should be somehow clarified >>>> >>>>A PCE, supporting this draft, either LSR or centralized, will run >>>>the IGP. Thus it will be reacheable. We will clarify this point. >>> >>>[DP] but then you have to ensure that no IP data traffic could reach >>>the centralized PCE (since by definition it will be only capable to >>>process IP control messages request/response, etc.) ie one has to >>>exluce IP data traffic from the corresponding IP control channels >> >>Well, no, it is the choice of the operator to choose a PCE dedicated >>for path computation or to activate the PCE function on an LSR >>forwarding packets. > >[DP] i was discussing the non co-located case which does not get >clarified by your response is there a redirection provided and the LSR >acts as a proxy (or is it not within the scope of this document ?) is your question to know how one can ensure in this case the PCE will not receive any data traffic ? [DP] yes, that's part of the problem raised [snip] thanks, - dimitri. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Jul 2004 05:19:49 +0000 Message-Id: <4.3.2.7.2.20040730011022.04123ae8@wells.cisco.com> Date: Fri, 30 Jul 2004 01:17:33 -0400 To: dpapadimitirou@psg.com, dimitri.papadimitriou@alcatel.be From: Jean Philippe Vasseur <jvasseur@cisco.com> Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00 Cc: dimitri.papadimitriou@alcatel.be, LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@francetelecom.com>, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Dimitri, At 07:00 PM 7/29/2004 +0200, dimitri papadimitriou wrote: >hi jp, see in-line (i have shorten the size of the mail) > >[snip] > >>>>>>M bit: Multiple Path Computation. When set, this flag indicates that the >>>>>>PCE is capable of computing more than one path obeying a set of specified >>>>>>constraints (in a single pass), provided that they exist. >>>>> >>>>>[DP] so it is a multi-path, multi-constraint computation ? >>>> >>>>It means that the LSR can compute a set of constrained path in a >>>>coordinated >>>>manner. This bit does not indicate wether or not the PCE can compute paths >>>>with multiple additive constaints (also an NP-Hard problem) like e.g. >>>>minimum >>>>cost bounded delay paths. This may require an additional bit. >>> >>>[DP] ok thanks for the clarification; would it be possible then to >>>indicate (or something equivalent at your discretion) >>> >>>"M bit: indicates that the LSR can compute a set of constrained path in >>>a coordinated manner. >>> >>>Note: The M bit does not indicate whether or not the PCE can compute a >>>set of paths with multiple additive constaints (also an NP-Hard problem) >>>like e.g. minimum cost bounded delay paths. This requires an additional bit." >> >>The aim of the M bit is just to mention that the PCE has the ability to >>compute a set of M paths, considering that those paths may have different >>constraints *and* could be related (ex: compute a set of N link diverse paths). > >[DP] the interpretation i made from jean-louis response, the draft and >yours is different, at the end the point is to achieve a unique interpretation we will clarify, adding a few words in the next revision, no pb. >>>>>>D bit: Diversity. When set, this flag indicates that the PCE is capable >>>>>>of computing diversely routed paths (link, node, SRLG). The PCC may >>>>>>request the PCE to compute N diversely routed paths obeying a set of >>>>>>specified constraints. Such N paths may not exist of course depending on >>>>>>the current state of the network. >>>>> >>>>>[DP] is that not a particular case of the previous bit ? >>>> >>>>Yes it is, if D is set M must also be set. >>> >>>[DP] ok, useful to indicate this specific case >>ok > >[DP] thanks > >>>>>>If the PCE is capable of computing inter-AS TE LSP path, the PCE >>>>>>Discovery Information TLV MAY also contain the list of AS numbers >>>>>>identifying the AS for which the PCE can compute inter-AS TE LSP paths >>>>>>(TE-LSPs having their destination address in this AS). This set is >>>>>>optional and should be included only when the A bit is set. >>>>> >>>>>[DP] did you evaluate the potential length of such advertisement ? and the >>>>>"loop" created with BGP information ? since the text says "MAY also >>>>>contain >>>>>the list of AS numbers identifying the AS for which the PCE can compute >>>>>inter-AS TE LSP paths" so each time new AS's will be known this list >>>>>will potentially be updated, drawing some lines along this point will >>>>>help here; >>>> >>>>In practice an inter-AS TE "domain", will contained a limited number of >>>>ASes. Also, in case a PCE can compute an inter-AS Path for any destination >>>>AS, then destination ASes are not included. >>>>Further more the objective of this information is to allow balcaning path >>>>computation load among a set of PCEs in a given AS, based on destination >>>>ASes. For instance, an AS could contain 5 PCEs, each one being responsible >>>>for the computation of inter-AS LSPs to 20 destination ASes. This would >>>>allow >>>>supporting an inter-AS TE "domain" comprising 100 ASes, with only 20 ASes >>>>listed per PCE. >>>>We will add some text on this point >>> >>>[DP] ok, this text will be useful - also, when you mention "inter-AS TE >>>domain" do you mean a multi-AS single carrier environment ? or do you >>>refer to something else ? >>May be multiple AS of the same SP or multiple AS of different SP. > >[DP] thanks to clarify in the text > >>>>>another aspect is to distinguish between multi-AS single carrier and >>>>>multi-AS multi-carrier, and restrict the latter to stringent policy rules >>>>>in terms of AS path considered for LSP >>>> >>>>Yes, but again the goal of this information is more a way to allow an LSR >>>>selecting the appropriate PCE among a set of candidate PCE, when the >>>>computation load is balanced based on the destination AS. Policy rules for >>>>AS-path selection are beyond the scope of this ID, and should be >>>>addressed in >>>>separate drafts >>> >>>[DP] i understand that policy for AS path selection is beyond the scope >>>of this document but the relevance of including this information as part >>>of the IGP flooded information should be also clarified at some point in time >>but outside of the scope of the IGP flooding. > >[DP] well i'd like to make a point clearer in this context it is not >because a specific capability is not related to the flooding mechanism but >only to the carried information that the rationales for carrying this >information shouldn't be provided with a non ambiguous semantic > >in addition it is not because policying of information is outside the >scope of this document that any information should be part of this >document without any discussion well .. .not sure of what you would want to see added there ... Again, AS path selection is out of the scope and not related to IGP flooding which is what this draft is about. >>>>>=> 5.3. Procedure >>>>> >>>>>>The PCE Discovery Information TLV is carried in Link State >>>>>>Advertisements. A router MUST originate a new Link State Advertisement >>>>>>whenever the content of this information changes, or whenever required by >>>>>> regular routing procedure (e.g. refresh) >>>>>>The PCE Discovery Information TLV is optional. >>>>>>If the PCE can compute an intra-area TE LSP path, the L bit MUST be >>>>>>set.If it can compute an intra-area TE LSP path only for the LSRs in the >>>>>>area it resides in, then the PCE Discovery Information must be contained >>>>>>within an area. Otherwise, if the PCE can compute intra-area TE LSP >>>>>>paths for the whole AS, then the PCE Discovery Information TLV must be >>>>>>flooded across the whole AS. >>>>> >>>>>[DP] how do you ensure that LSR's not being part of this area can >>>>>reach the >>>>>PCE (i.e. is there not a reachability constraint to be added here ? in >>>>>particular in case of non-co-located PCE identified by an IP address) - i >>>>>guess this point should be somehow clarified >>>> >>>>A PCE, supporting this draft, either LSR or centralized, will run the IGP. >>>>Thus it will be reacheable. We will clarify this point. >>> >>>[DP] but then you have to ensure that no IP data traffic could reach the >>>centralized PCE (since by definition it will be only capable to process >>>IP control messages request/response, etc.) ie one has to exluce IP data >>>traffic from the corresponding IP control channels >>Well, no, it is the choice of the operator to choose a PCE dedicated for >>path computation or to activate the PCE function on an LSR forwarding packets. > >[DP] i was discussing the non co-located case which does not get clarified >by your response is there a redirection provided and the LSR acts as a >proxy (or is it not within the scope of this document ?) is your question to know how one can ensure in this case the PCE will not receive any data traffic ? thanks. JP. >[snip] > >>>>>>-A Tail-end name: string used to ease the TE-LSP naming (e.g. >>>>>>'head-name->tail-name'). >>>>> >>>>>[DP] is this to be used as part of the Session name field of the SESSION >>>>>ATTRIBUTE object or the Extended Tunnel ID ? >>>> >>>>Yes >>> >>>[DP] thanks for the clarification >>note that the head-end may or not decide to signal it in the SESSION >>ATTRIBUTE. > >[DP] ok > >thanks, >- dimitri. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Jul 2004 19:15:25 +0000 Message-ID: <41094C15.1050807@psg.com> Date: Thu, 29 Jul 2004 21:12:21 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Arthi Ayyangar <arthi@juniper.net> CC: Adrian Farrel <adrian@olddog.co.uk>, 'Jean Philippe Vasseur' <jvasseur@cisco.com>, ccamp@ops.ietf.org Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi arthi - see in-line Arthi Ayyangar wrote: > Hi Adrian, > > Thanks for reviewing the document and providing feedback. > > >>As has been discussed on the list already, I think it would be really >>helpful to have a brief architectural description of how stitched LSPs >>work. This is probably best suited to a separate draft. > > --------> I thought that it was a private e-mail exchange. Anyway, this is > probably a good point to be discussed during the meeting next week. > > >>In the Abstract you say... >> This document describes extensions to Generalized Multi-Protocol Label >> Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering >> (RSVP-TE) signaling required to support mechanisms for the establishment >> and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths >> (LSPs), both packet and non-packet, that traverse multiple domains. >>...in the Introduction >> This document presents the RSVP-TE signaling extensions for the setup >> and maintenance of TE LSPs that span multiple domains. The signaling >> procedures described in this document are applicable to both packet >> LSPs ([RSVP-TE]) and non-packet LSPs that use RSVP-TE GMPLS >> extensions as described in [RSVP-GMPLS]. Three different signaling >> methods along with the corresponding RSVP-TE extensions and >> procedures are proposed in this document. There seems to be some mix >>up between MPLS and GMPLS. Presumably we want to support this work in >>all MPLS TE and all GMPLS (i.e. PSC and non-PSC). > > ------------> I agree, that this needs to be re-worded. Will do so in the > next revision. > > >>LSP_ATTRIBUTES bits. You may recall that I am tracking provisional >>assignments of LAP Attributes bits at www.olddog.co.uk/lsp-attrib.txt. >>This enables people to go ahead with provisional implementations without >>seeing a conflict of meaning, and handles the situation until IANA has >>control of these bits. I have added your two uses to the list at values >>5 and 6 > > --------> Thanks! > > >>Nits >>=== >>Copyright date at the head of the document is wrong. > > --------> Will fix. > > >>1.2. Terminology >> LSR: Label Switch Router >>"Switching" > > -----------> Will fix. > > I also noticed that section 3.2 has been titled as "Stitching of packet > LSPs"...I think that needs to be fixed as well. There are some aspects > there which only apply to packet LSPs, but some other aspects which apply > to both packet and non-packet LSPs. So, this needs to be clarified as > well. but the whole document is oriented towards RSVP-TE signaling only RFC 3473 is only referenced in the introduction several additional comments here below 1) section 3.1 "A mid-point LSR not supporting contiguous TE LSP MUST send a Path Error message upstream with an error code of "Routing Problem" and error sub- code=17 (TBD) (Contiguous LSP type not supported). This bit MUST not be modified by any downstream node." first tiem the term "mid-point" LSR is used but the major point is that 1) there is a difference between capability and policy 2) there is from point 1) a distinction to be made from which entry point we're speaking about in brief as in the most common contiguous LSP is supported by any LSR, the above rule should be refined 2) would it be possible to replace the section with the examples by the generic operations to be performed ? 3) how FRR section applies to non-PSC environments ? 4) in the re-optimization part it is unclear how in a multi-domain context one constraints the head-end to use the same entry point as the one from which re- optimization has been initiated ? wouldn't it be better to focus on setup and recovery and come up in a next step with a re-optimization solution that applies once the former items get more stable ? thanks, - dimitri. > thanks, > -arthi > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Jul 2004 18:12:14 +0000 Date: Thu, 29 Jul 2004 11:10:41 -0700 (PDT) From: Arthi Ayyangar <arthi@juniper.net> To: Adrian Farrel <adrian@olddog.co.uk> cc: "'Jean Philippe Vasseur'" <jvasseur@cisco.com>, ccamp@ops.ietf.org Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt Message-ID: <20040729110313.H35634@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Adrian, Thanks for reviewing the document and providing feedback. > As has been discussed on the list already, I think it would be really > helpful to have a brief architectural description of how stitched LSPs > work. This is probably best suited to a separate draft. --------> I thought that it was a private e-mail exchange. Anyway, this is probably a good point to be discussed during the meeting next week. > In the Abstract you say... > This document describes extensions to Generalized Multi-Protocol Label > Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering > (RSVP-TE) signaling required to support mechanisms for the establishment > and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths > (LSPs), both packet and non-packet, that traverse multiple domains. > ...in the Introduction > This document presents the RSVP-TE signaling extensions for the setup > and maintenance of TE LSPs that span multiple domains. The signaling > procedures described in this document are applicable to both packet > LSPs ([RSVP-TE]) and non-packet LSPs that use RSVP-TE GMPLS > extensions as described in [RSVP-GMPLS]. Three different signaling > methods along with the corresponding RSVP-TE extensions and > procedures are proposed in this document. There seems to be some mix > up between MPLS and GMPLS. Presumably we want to support this work in > all MPLS TE and all GMPLS (i.e. PSC and non-PSC). ------------> I agree, that this needs to be re-worded. Will do so in the next revision. > LSP_ATTRIBUTES bits. You may recall that I am tracking provisional > assignments of LAP Attributes bits at www.olddog.co.uk/lsp-attrib.txt. > This enables people to go ahead with provisional implementations without > seeing a conflict of meaning, and handles the situation until IANA has > control of these bits. I have added your two uses to the list at values > 5 and 6 --------> Thanks! > Nits > === > Copyright date at the head of the document is wrong. --------> Will fix. > 1.2. Terminology > LSR: Label Switch Router > "Switching" -----------> Will fix. I also noticed that section 3.2 has been titled as "Stitching of packet LSPs"...I think that needs to be fixed as well. There are some aspects there which only apply to packet LSPs, but some other aspects which apply to both packet and non-packet LSPs. So, this needs to be clarified as well. thanks, -arthi Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Jul 2004 17:27:16 +0000 Message-ID: <41093308.8030308@psg.com> Date: Thu, 29 Jul 2004 19:25:28 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitirou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> CC: Zafar Ali <zali@cisco.com>, Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel.be>, 'Danny Prairie' <dprairie@cisco.com>, Reshad Rahman <rrahman@cisco.com>, ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian, sorry for the delayed response - see in-line > 2. Introduction > Even in the case of packet MPLS, when link failure detection is > performed by some means other than RSVP Hellos (e.g., [BFD]), the use > of node-id based Hellos is also optimal for detection of signaling > adjacency failures for RSVP-TE. > This optimally only applies when there is more than one link between a pair of node, > right? > Say so? > Ditto section 3. yes and here also one has to clarify the GMPLS PSC vs MPLS point already raised > 2. Introduction > This document also clarifies the use of node-id based Hellos when all > or a sub-set of TE links are unnumbered. This draft also clarifies > use of node-id based Hellos in these scenarios. > Repeated? > > 3. Node-id based RSVP Hellos > When a node receives a Hello packet where the destination IP address > is its local node-id as advertised in the IGP-TE topology, the node > MUST use its node-id in replying to the Hello message. > This is an interesting use of MUST when the receiving node knows that the use of node-id > is inappropriate. yes this part of the text needs to be clarified (this paragraph as well as the previous would benefit from this revision thanks, - dimitri. > I think it is really cute that Danny and Reshad have decided to swap email addresses :-) > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Jul 2004 17:01:20 +0000 Message-ID: <41092D21.1040504@psg.com> Date: Thu, 29 Jul 2004 19:00:17 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitirou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Jean Philippe Vasseur <jvasseur@cisco.com> CC: dimitri.papadimitriou@alcatel.be, LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@francetelecom.com>, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi jp, see in-line (i have shorten the size of the mail) [snip] >>>>> M bit: Multiple Path Computation. When set, this flag indicates >>>>> that the >>>>> PCE is capable of computing more than one path obeying a set of >>>>> specified >>>>> constraints (in a single pass), provided that they exist. >>>> >>>> [DP] so it is a multi-path, multi-constraint computation ? >>> >>> It means that the LSR can compute a set of constrained path in a >>> coordinated >>> manner. This bit does not indicate wether or not the PCE can compute >>> paths >>> with multiple additive constaints (also an NP-Hard problem) like e.g. >>> minimum >>> cost bounded delay paths. This may require an additional bit. >> >> [DP] ok thanks for the clarification; would it be possible then to >> indicate (or something equivalent at your discretion) >> >> "M bit: indicates that the LSR can compute a set of constrained path >> in a coordinated manner. >> >> Note: The M bit does not indicate whether or not the PCE can compute a >> set of paths with multiple additive constaints (also an NP-Hard >> problem) like e.g. minimum cost bounded delay paths. This requires an >> additional bit." > > The aim of the M bit is just to mention that the PCE has the ability to > compute a set of M paths, considering that those paths may have > different constraints *and* could be related (ex: compute a set of N > link diverse paths). [DP] the interpretation i made from jean-louis response, the draft and yours is different, at the end the point is to achieve a unique interpretation >>>>> D bit: Diversity. When set, this flag indicates that the PCE is >>>>> capable >>>>> of computing diversely routed paths (link, node, SRLG). The PCC may >>>>> request the PCE to compute N diversely routed paths obeying a set of >>>>> specified constraints. Such N paths may not exist of course >>>>> depending on >>>>> the current state of the network. >>>> >>>> [DP] is that not a particular case of the previous bit ? >>> >>> Yes it is, if D is set M must also be set. >> >> [DP] ok, useful to indicate this specific case > > ok [DP] thanks >>>>> If the PCE is capable of computing inter-AS TE LSP path, the PCE >>>>> Discovery Information TLV MAY also contain the list of AS numbers >>>>> identifying the AS for which the PCE can compute inter-AS TE LSP paths >>>>> (TE-LSPs having their destination address in this AS). This set is >>>>> optional and should be included only when the A bit is set. >>>> >>>> [DP] did you evaluate the potential length of such advertisement ? >>>> and the >>>> "loop" created with BGP information ? since the text says "MAY also >>>> contain >>>> the list of AS numbers identifying the AS for which the PCE can compute >>>> inter-AS TE LSP paths" so each time new AS's will be known this list >>>> will potentially be updated, drawing some lines along this point >>>> will help here; >>> >>> In practice an inter-AS TE "domain", will contained a limited number of >>> ASes. Also, in case a PCE can compute an inter-AS Path for any >>> destination >>> AS, then destination ASes are not included. >>> Further more the objective of this information is to allow balcaning >>> path >>> computation load among a set of PCEs in a given AS, based on destination >>> ASes. For instance, an AS could contain 5 PCEs, each one being >>> responsible >>> for the computation of inter-AS LSPs to 20 destination ASes. This >>> would allow >>> supporting an inter-AS TE "domain" comprising 100 ASes, with only 20 >>> ASes >>> listed per PCE. >>> We will add some text on this point >> >> [DP] ok, this text will be useful - also, when you mention "inter-AS >> TE domain" do you mean a multi-AS single carrier environment ? or do >> you refer to something else ? > > May be multiple AS of the same SP or multiple AS of different SP. [DP] thanks to clarify in the text >>>> another aspect is to distinguish between multi-AS single carrier and >>>> multi-AS multi-carrier, and restrict the latter to stringent policy >>>> rules >>>> in terms of AS path considered for LSP >>> >>> Yes, but again the goal of this information is more a way to allow an >>> LSR >>> selecting the appropriate PCE among a set of candidate PCE, when the >>> computation load is balanced based on the destination AS. Policy >>> rules for >>> AS-path selection are beyond the scope of this ID, and should be >>> addressed in >>> separate drafts >> >> [DP] i understand that policy for AS path selection is beyond the >> scope of this document but the relevance of including this information >> as part of the IGP flooded information should be also clarified at >> some point in time > > but outside of the scope of the IGP flooding. [DP] well i'd like to make a point clearer in this context it is not because a specific capability is not related to the flooding mechanism but only to the carried information that the rationales for carrying this information shouldn't be provided with a non ambiguous semantic in addition it is not because policying of information is outside the scope of this document that any information should be part of this document without any discussion >>>> => 5.3. Procedure >>>> >>>>> The PCE Discovery Information TLV is carried in Link State >>>>> Advertisements. A router MUST originate a new Link State Advertisement >>>>> whenever the content of this information changes, or whenever >>>>> required by >>>>> regular routing procedure (e.g. refresh) >>>>> The PCE Discovery Information TLV is optional. >>>>> If the PCE can compute an intra-area TE LSP path, the L bit MUST be >>>>> set.If it can compute an intra-area TE LSP path only for the LSRs >>>>> in the >>>>> area it resides in, then the PCE Discovery Information must be >>>>> contained >>>>> within an area. Otherwise, if the PCE can compute intra-area TE LSP >>>>> paths for the whole AS, then the PCE Discovery Information TLV >>>>> must be >>>>> flooded across the whole AS. >>>> >>>> [DP] how do you ensure that LSR's not being part of this area can >>>> reach the >>>> PCE (i.e. is there not a reachability constraint to be added here ? in >>>> particular in case of non-co-located PCE identified by an IP >>>> address) - i >>>> guess this point should be somehow clarified >>> >>> A PCE, supporting this draft, either LSR or centralized, will run the >>> IGP. >>> Thus it will be reacheable. We will clarify this point. >> >> [DP] but then you have to ensure that no IP data traffic could reach >> the centralized PCE (since by definition it will be only capable to >> process IP control messages request/response, etc.) ie one has to >> exluce IP data traffic from the corresponding IP control channels > > Well, no, it is the choice of the operator to choose a PCE dedicated for > path computation or to activate the PCE function on an LSR forwarding > packets. [DP] i was discussing the non co-located case which does not get clarified by your response is there a redirection provided and the LSR acts as a proxy (or is it not within the scope of this document ?) [snip] >>>>> -A Tail-end name: string used to ease the TE-LSP naming (e.g. >>>>> 'head-name->tail-name'). >>>> >>>> [DP] is this to be used as part of the Session name field of the >>>> SESSION >>>> ATTRIBUTE object or the Extended Tunnel ID ? >>> >>> Yes >> >> [DP] thanks for the clarification > > note that the head-end may or not decide to signal it in the SESSION > ATTRIBUTE. [DP] ok thanks, - dimitri. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Jul 2004 16:56:33 +0000 To: "Adrian Farrel" <adrian@olddog.co.uk> Cc: "Arthi Ayyangar" <arthi@juniper.net>, "'Jean Philippe Vasseur'" <jvasseur@cisco.com>, <ccamp@ops.ietf.org> From: Dimitri.Papadimitriou@alcatel.be Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt MIME-Version: 1.0 Date: Thu, 29 Jul 2004 18:53:27 +0200 Message-ID: <OFC4E14ED2.C7C980A9-ONC1256EE0.005CC8C9-C1256EE0.005CC8F6@netfr.alcatel.fr> Content-type: text/plain; charset=us-ascii hi adrian, all > Hi Arthi and Jean-Philippe, > > Thanks for putting this draft together; a good start. > > A few thoughts. > > Cheers, > Adrian > > As has been discussed on the list already, I think it would be really > helpful to have a brief architectural description of how stitched LSPs work. > This is probably best suited to a separate draft. in any case a description of stitching of PSC, and non-PSC LSPs should be detailed - ideally operations should be as common as possible > In the Abstract you say... > > This document describes extensions to Generalized Multi-Protocol Label > Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering > (RSVP-TE) signaling required to support mechanisms for the establishment > and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths > (LSPs), both packet and non-packet, that traverse multiple domains. > > ...in the Introduction > > This document presents the RSVP-TE signaling extensions for the setup > and maintenance of TE LSPs that span multiple domains. The signaling > procedures described in this document are applicable to both packet > LSPs ([RSVP-TE]) and non-packet LSPs that use RSVP-TE GMPLS > extensions as described in [RSVP-GMPLS]. Three different signaling > methods along with the corresponding RSVP-TE extensions and > procedures are proposed in this document. > > There seems to be some mix up between MPLS and GMPLS. Presumably we > want to support this work in all MPLS TE and all GMPLS (i.e. PSC and > non-PSC). at least i'm not the only one thinking that at some point in time this ambiguity should be removed in particular within the CCAMP WG context but even the title of the document is ambiguous from that perspective > LSP_ATTRIBUTES bits. > You may recall that I am tracking provisional assignments of LAP > Attributes bits at <www.olddog.co.uk/lsp-attrib.txt>. > This enables people to go ahead with provisional implementations without > seeing a conflict of meaning, and handles the situation until IANA has > control of these bits. > > I have added your two uses to the list at values 5 and 6 i could also be interesting to have a bit more details on "NULL" label and related processing - other comments to follow > Nits > ==== > Copyright date at the head of the document is wrong. > > 1.2. Terminology > LSR: Label Switch Router "Switching" Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Jul 2004 14:17:07 +0000 Message-ID: <000501c47575$d44f5990$54f6690c@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Arthi Ayyangar" <arthi@juniper.net>, "'Jean Philippe Vasseur'" <jvasseur@cisco.com> Cc: <ccamp@ops.ietf.org> Subject: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt Date: Wed, 28 Jul 2004 16:13:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Arthi and Jean-Philippe, Thanks for putting this draft together; a good start. A few thoughts. Cheers, Adrian As has been discussed on the list already, I think it would be really helpful to have a brief architectural description of how stitched LSPs work. This is probably best suited to a separate draft. In the Abstract you say... This document describes extensions to Generalized Multi-Protocol Label Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support mechanisms for the establishment and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths (LSPs), both packet and non-packet, that traverse multiple domains. ...in the Introduction This document presents the RSVP-TE signaling extensions for the setup and maintenance of TE LSPs that span multiple domains. The signaling procedures described in this document are applicable to both packet LSPs ([RSVP-TE]) and non-packet LSPs that use RSVP-TE GMPLS extensions as described in [RSVP-GMPLS]. Three different signaling methods along with the corresponding RSVP-TE extensions and procedures are proposed in this document. There seems to be some mix up between MPLS and GMPLS. Presumably we want to support this work in all MPLS TE and all GMPLS (i.e. PSC and non-PSC). LSP_ATTRIBUTES bits. You may recall that I am tracking provisional assignments of LAP Attributes bits at www.olddog.co.uk/lsp-attrib.txt. This enables people to go ahead with provisional implementations without seeing a conflict of meaning, and handles the situation until IANA has control of these bits. I have added your two uses to the list at values 5 and 6 Nits === Copyright date at the head of the document is wrong. 1.2. Terminology LSR: Label Switch Router "Switching" Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Jul 2004 20:58:33 +0000 Date: Wed, 28 Jul 2004 13:56:39 -0700 (PDT) From: Arthi Ayyangar <arthi@juniper.net> To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be cc: ccamp@ops.ietf.org Subject: Re: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt Message-ID: <20040728135520.I66527@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Dimitri, I think the LSP_ATTRIBUTES and the corresponding bit in the RRO Attributes Sub-object should be used. thanks, -arthi > All, there is one issue that is flagged in Section 7.1 in this draft > > <http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt> > > as needing to poll from the working group to see whether to use Session_ > Attributes or LSP_Attributes to flag component link recording and close accordingly > > " If a node desires component link recording, the "Component Link > Recording desired" flag (value TBD) should be set in the > LSP_ATTRIBUTES object, object that is defined in [RSVP-TE- > ATTRIBUTE]. Another alternate is to use an available flag in the > SESSION_ATTRIBUTE object [RFC3209]. The later makes the component > link recording request similar to the label recording request." > > thanks for the feedback, > - dimitri > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Jul 2004 07:30:38 +0000 Message-Id: <6.0.0.20.2.20040728133201.0460aa08@172.19.83.4> Date: Wed, 28 Jul 2004 15:25:31 +0900 To: Tomohiro Otani <otani@kddilabs.jp>, "Adrian Farrel" <adrian@olddog.co.uk>, <mc-hayashi@kddilabs.jp>, <okamoto.satoru@lab.ntt.co.jp> From: ogino <ogino@kddilabs.jp> Subject: Re: draft-otani-ccamp-interas-gmpls-te-00.txt Cc: <ccamp@ops.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian and Tomo, Thank you for your interesting discussion. Though I am not an EGP expert, I suspect that it will be problematic to advertise the TE information by an EGP-TE from the viewpoints of scalability and complexity. Particularly, the TE information will be confidential in the Inter-Provider case even if such TE information can be aggregated. The PCE model can solve this problem because no TE information is advertised to the externals and only the result of path computation is notified to the external node requesting the path computation (Head-end LSR, ASBRs, other PCEs, etc.). Even in the PCE model, the crankback function is necessary because the TE sate may change rapidly and the time lag between the path computation and the path establishemt may be relatively large. As you pointed out, different SPs may have TE links included in the same SRLG. Moreover, even if appropriate SRLG can be allocated to each TE-link gloabally, such SRLG information will also be confidential in the Inter-Provider environment. At least, the SRLG can be allocated appropriately within a provider's network according to the provider's policy, and multi-paths with the SRLG diversity can be correctly established within a provider's network. Thus, it is practical to establish the working path and the corresponding backup path through the same sequence of provider's networks in the case of Inter-Provider LSP establishment. Anyway, if both the working path and the backup path have damage simultaneously, dynamic re-routing is necessary. As you pointed out, it is required to develop the SRLG encoding that can indicate the SRLG level (area, duct, cable, fiber, etc.). Each SP can establish a pair of working path and backup path with the appropriate SRLG diversity and satsfying the SLA when he/she can recognise the level of each SRLG. Best regards, Nagao Ogino At 10:44 04/07/28, Tomohiro Otani wrote: >Hi Adrian, > >Thank you for your comments. > >Some of SPs including ourselves have a plan to introduce GMPLS control plane >technologies for a NGN, and even NGNs should be interconnected with each other, >as SONET/SDH networks are as well as IP/MPLS networks are. > >Your supposed model is another example to reveal the necessity of Inter AS TE. >I agree that a crankback mechanism is one of the ways to achieve this. > >In terms of the amount of computation by the ASBR, we have to investigate >the impact on the load to the ASBR, hearing from the routing (EGP: BGP4?) >expert. >That's why, in the draft, we described that the TE information may be >statically or >dynamically exchanged. Operators would like to know the route of a GMPLS LSP >within an AS and the pair of ASBR in advance, if the LSP is established across >the inter AS, especially multiple ISPs, resulting in the implementation >of TE extensions. > >The network resiliency is getting significant more and more in a SP environment. >There was a big discussion about SRLGs among us and so far, as you pointed out, >we do not have any solutions for this. Altouhgh each SP believes that >these TE links >are not a SRLG because these are belonging to a different SP, fibers >accommodating >such TE links may be laid in the same duct otherwise the same tunnel >under the road. >Our conclusion is that the level of SRLG is another issue.....(one issue >is indeed how >to assign SRLG IDs to each SP) > >Regards, > >tomo > > > > >At 18:41 04/07/27, Adrian Farrel wrote: >>Hi, >> >>A nice short draft. Congratulations! >> >>Also, it is very good to see SPs bringing forward requirement drafts. >>Thank you. >> >>I understand the point you are making in the draft, but I am not sure >>it is specific to GMPLS and switching capabilities. >> >>For example, suppose we modify the bandwidth in your MPLS example network to: >> >> +----+ +----+ | +----+ +----+ >> | A1 |----//----| A3 |---------| B1 |----//----| B3 | >> +----+ 10G +----+ 10G +----+ 2.5G +----+ >> | | | | | >> =2.5G =10G | =2.5G =2.5G >> | | | | | >> +----+ +----+ | +----+ +----+ >> | A2 |----//----| A4 |---------| B2 |----//----| B4 | >> +----+ 2.5G +----+ 10G +----+ 10G +----+ >> | >> MPLS AS 1 | MPLS AS 2 >>Now, set up a 10G service from A1 to B4. >>AS 1 is going to select the ASBR pair A3/B1 as the shortest path out of AS 1. >>But B1 will fail the setup. >>We must rely on crankback or a wider view (PCE, TE aggregation, etc.) >>in order to be successful. >> >> >>I think what your draft points out, however, is that the complexity for >>GMPLS is increased considerably (perhaps to a power of three). It is >>further worth noting that if we added some speculative future routing >>constraints (such as source-based lambda selection, optical impairments, >>etc.) the problem would get even more complex. >> >>Essentially, however, the problem is the same: IP route aggregation is >>not sufficient to enable inter-domain TE and some other solution is >>needed. Your proposal for EGP extensions to general reachability >>information is certainly one option. >> >>The concern that I have heard voiced is that there may be significant >>churn in this information, and this would result in a significant amount >>of aggregation computation by the ASBRs. My view is that: >>- in a non-PSC GMPLS network the rate of change is >> not likely to be significant >>- we should, in any case, specify damping of computation >> and updates if we proceed with this approach. >>But I would be interested to hear this debated further especially by >>the EGP experts. >> >> >> >>Your point about SRLGs is very valid. Currently, however, (as I >>understand it) we don't have a satisfactory encoding for SRLG IDs to >>allow an ID to be globally unique *and* to allow an SRLG to span ASs. >> >>Thanks, >>Adrian > >****************************** >Nagao Ogino, Dr. Eng. >KDDI R&D Laboratories Inc. >2-1-15 Ohara, Kamifukuoka-shi, >Saitama 356-8502 Japan >TEL +81 49 278 7860 >FAX +81 49 278 7811 >E-mail ogino@kddilabs.jp >****************************** Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Jul 2004 01:45:23 +0000 Message-Id: <6.0.0.20.2.20040728094655.048b55f8@mail.onw.kddlabs.co.jp> Date: Wed, 28 Jul 2004 10:44:24 +0900 To: "Adrian Farrel" <adrian@olddog.co.uk>, <mc-hayashi@kddilabs.jp>, <okamoto.satoru@lab.ntt.co.jp> From: Tomohiro Otani <otani@kddilabs.jp> Subject: Re: draft-otani-ccamp-interas-gmpls-te-00.txt Cc: <ccamp@ops.ietf.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_7216640==.ALT" --=====================_7216640==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, Thank you for your comments. Some of SPs including ourselves have a plan to introduce GMPLS control plane technologies for a NGN, and even NGNs should be interconnected with each other, as SONET/SDH networks are as well as IP/MPLS networks are. Your supposed model is another example to reveal the necessity of Inter AS TE. I agree that a crankback mechanism is one of the ways to achieve this. In terms of the amount of computation by the ASBR, we have to investigate the impact on the load to the ASBR, hearing from the routing (EGP: BGP4?) expert. That's why, in the draft, we described that the TE information may be statically or dynamically exchanged. Operators would like to know the route of a GMPLS LSP within an AS and the pair of ASBR in advance, if the LSP is established across the inter AS, especially multiple ISPs, resulting in the implementation of TE extensions. The network resiliency is getting significant more and more in a SP environment. There was a big discussion about SRLGs among us and so far, as you pointed out, we do not have any solutions for this. Altouhgh each SP believes that these TE links are not a SRLG because these are belonging to a different SP, fibers accommodating such TE links may be laid in the same duct otherwise the same tunnel under the road. Our conclusion is that the level of SRLG is another issue.....(one issue is indeed how to assign SRLG IDs to each SP) Regards, tomo At 18:41 04/07/27, Adrian Farrel wrote: >Hi, > >A nice short draft. Congratulations! > >Also, it is very good to see SPs bringing forward requirement drafts. Thank you. > >I understand the point you are making in the draft, but I am not sure it >is specific to GMPLS and switching capabilities. > >For example, suppose we modify the bandwidth in your MPLS example network to: > > +----+ +----+ | +----+ +----+ > | A1 |----//----| A3 |---------| B1 |----//----| B3 | > +----+ 10G +----+ 10G +----+ 2.5G +----+ > | | | | | > =2.5G =10G | =2.5G =2.5G > | | | | | > +----+ +----+ | +----+ +----+ > | A2 |----//----| A4 |---------| B2 |----//----| B4 | > +----+ 2.5G +----+ 10G +----+ 10G +----+ > | > MPLS AS 1 | MPLS AS 2 >Now, set up a 10G service from A1 to B4. >AS 1 is going to select the ASBR pair A3/B1 as the shortest path out of AS 1. >But B1 will fail the setup. >We must rely on crankback or a wider view (PCE, TE aggregation, etc.) in >order to be successful. > > >I think what your draft points out, however, is that the complexity for >GMPLS is increased considerably (perhaps to a power of three). It is >further worth noting that if we added some speculative future routing >constraints (such as source-based lambda selection, optical impairments, >etc.) the problem would get even more complex. > >Essentially, however, the problem is the same: IP route aggregation is >not sufficient to enable inter-domain TE and some other solution is >needed. Your proposal for EGP extensions to general reachability >information is certainly one option. > >The concern that I have heard voiced is that there may be significant >churn in this information, and this would result in a significant amount >of aggregation computation by the ASBRs. My view is that: >- in a non-PSC GMPLS network the rate of change is > not likely to be significant >- we should, in any case, specify damping of computation > and updates if we proceed with this approach. >But I would be interested to hear this debated further especially by the >EGP experts. > > > >Your point about SRLGs is very valid. Currently, however, (as I >understand it) we don't have a satisfactory encoding for SRLG IDs to allow >an ID to be globally unique *and* to allow an SRLG to span ASs. > >Thanks, >Adrian --=====================_7216640==.ALT Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <html> <body> Hi Adrian, <br><br> Thank you for your comments.<br><br> Some of SPs including ourselves have a plan to introduce GMPLS control plane<br> technologies for a NGN, and even NGNs should be interconnected with each other,<br> as SONET/SDH networks are as well as IP/MPLS networks are. <br><br> Your supposed model is another example to reveal the necessity of Inter AS TE.<br> I agree that a crankback mechanism is one of the ways to achieve this. <br><br> In terms of the amount of computation by the ASBR, we have to investigate<br> the impact on the load to the ASBR, hearing from the routing (EGP: BGP4?) expert.<br> That's why, in the draft, we described that the TE information may be statically or <br> dynamically exchanged. Operators would like to know the route of a GMPLS LSP <br> within an AS and the pair of ASBR in advance, if the LSP is established across <br> the inter AS, especially multiple ISPs, resulting in the implementation of TE extensions. <br><br> The network resiliency is getting significant more and more in a SP environment.<br> There was a big discussion about SRLGs among us and so far, as you pointed out,<br> we do not have any solutions for this. Altouhgh each SP believes that these TE links<br> are not a SRLG because these are belonging to a different SP, fibers accommodating<br> such TE links may be laid in the same duct otherwise the same tunnel under the road.<br> Our conclusion is that the level of SRLG is another issue.....(one issue is indeed how<br> to assign SRLG IDs to each SP)<br><br> Regards,<br><br> tomo<br><br> <br><br> <br> At 18:41 04/07/27, Adrian Farrel wrote:<br> <blockquote type=cite><font face="courier" size=2>Hi,<br> </font> <br> <font face="courier" size=2>A nice short draft. Congratulations!<br> </font> <br> <font face="courier" size=2>Also, it is very good to see SPs bringing forward requirement drafts. Thank you.<br> </font> <br> <font face="courier" size=2>I understand the point you are making in the draft, but I am not sure it is specific to GMPLS and switching capabilities.<br> </font> <br> <font face="courier" size=2>For example, suppose we modify the bandwidth in your MPLS example network to:<br> </font> <br> <font face="courier" size=2> +----+ +----+ | +----+ +----+ <br> | A1 |----//----| A3 |---------| B1 |----//----| B3 | <br> +----+ 10G +----+ 10G +----+ 2.5G +----+ <br> | | | | | <br> =2.5G =10G | =2.5G =2.5G <br> | | | | | <br> +----+ +----+ | +----+ +----+ <br> | A2 |----//----| A4 |---------| B2 |----//----| B4 | <br> +----+ 2.5G +----+ 10G +----+ 10G +----+ <br> | <br> MPLS AS 1 | MPLS AS 2 <br> Now, set up a 10G service from A1 to B4.<br> AS 1 is going to select the ASBR pair A3/B1 as the shortest path out of AS 1.<br> But B1 will fail the setup.<br> We must rely on crankback or a wider view (PCE, TE aggregation, etc.) in order to be successful.<br> </font> <br> <font face="courier" size=2> <br> I think what your draft points out, however, is that the complexity for GMPLS is increased considerably (perhaps to a power of three). It is further worth noting that if we added some speculative future routing constraints (such as source-based lambda selection, optical impairments, etc.) the problem would get even more complex.<br> </font> <br> <font face="courier" size=2>Essentially, however, the problem is the same: IP route aggregation is not sufficient to enable inter-domain TE and some other solution is needed. Your proposal for EGP extensions to general reachability information is certainly one option. <br> </font> <br> <font face="courier" size=2>The concern that I have heard voiced is that there may be significant churn in this information, and this would result in a significant amount of aggregation computation by the ASBRs. My view is that:<br> - in a non-PSC GMPLS network the rate of change is <br> not likely to be significant<br> - we should, in any case, specify damping of computation<br> and updates if we proceed with this approach.<br> But I would be interested to hear this debated further especially by the EGP experts.<br> </font> <br> <br> <br> <font face="courier" size=2>Your point about SRLGs is very valid. Currently, however, (as I understand it) we don't have a satisfactory encoding for SRLG IDs to allow an ID to be globally unique *and* to allow an SRLG to span ASs.<br> </font> <br> <font face="courier" size=2>Thanks,<br> Adrian</font></blockquote></body> </html> --=====================_7216640==.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Jul 2004 00:13:15 +0000 Message-Id: <4.3.2.7.2.20040725151801.0332c610@wells.cisco.com> Date: Tue, 27 Jul 2004 20:11:28 -0400 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be From: Jean Philippe Vasseur <jvasseur@cisco.com> Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00 Cc: LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@francetelecom.com>, Dimitri.Papadimitriou@alcatel.be, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Dimitri, Thanks for your comments - see in line. At 07:13 PM 7/25/2004 +0200, dimitri papadimitriou wrote: >hi jean-louis, much thanks for your reply and suggestions, see in-line > >LE ROUX Jean-Louis RD-CORE-LAN wrote: > >>Hi Dimitri and all, >>Thanks a lot for these really useful comments Please see inline >> >>>-----Message d'origine----- De : Dimitri.Papadimitriou@alcatel.be=20 >>>[mailto:Dimitri.Papadimitriou@alcatel.be] Envoy=E9 : jeudi 22 juillet= 2004 >>>20:43 =C0 : Adrian Farrel Cc : ccamp@ops.ietf.org; 'Jean Philippe= Vasseur'; >>>LE ROUX Jean-Louis RD-CORE-LAN Objet : Re: >>>draft-vasseur-ccamp-te-router-info-00 >>>hi adrian, all, >>>here below a bunch of comments on this documents: >>>=3D> 3. Introduction >>> >>>>- Data plane capabilities related to the node itself and not to its=20 >>>>links, such as the capability to be a branch node or a bud LSR of a P2MP >>>>LSP tunnel (see [P2MP-REQ]). These node capabilities should be= advertised >>>>by the IGP for path selection. It would also be highly useful to=20 >>>>advertise control plane node Capabilities; for instance, the capability >>>>to support GMPLS signaling for a packet LSR, or the capability to >>>>support P2MP signaling. This would ease backward compatibility. For >>>>instance this would allow selecting a path that would avoid nodes that= do >>>>not support a given signaling feature, or automatically triggering a >>>>mechanism that would handle these nodes on the path. >>>[DP] suggest to translate the protocol specific also within the above= text >>>with something like >>>- Nodal capabilities >>>1) control plane >>>2) data plane >>In 4.2 we define two distinct pieces of Information: Control Plane= Capability >>Flags and Data Plane Capability Flags, but agree that this separation= should >>appear more clearly in the intro. Will update > >[DP] ok > >>>=3D> 4.1. Description >>> >>>>LSRs in a network may have distinct control plane and data plane Traffic >>>>Engineering capabilities. The TE Node capability Descriptor TLV= describes >>>>data and control plane capabilities of an LSR. Such information can be >>>>used for instance for path computation algorithm so as to avoid nodes >>>>that do not support a given TE feature either in the control or data >>>>plane or to trigger procedure to handle these nodes. In some case, this >>>>may also be useful for backward compatibility. >>>[DP] suggest to detail the backward compatibility aspects ? i guess it is >>>to provide support of legacy LSRs ? >>Definitely, the goal of this information is to ease operations in a mixed >>environment made of capable and incapable nodes, wrt several control plane >>capabilities. Knowledge of incapable nodes, allows capable nodes either >>triggering mechanisms in order to support these nodes, or computing a path >>avoiding these nodes >>For instance, If P2MP capable nodes are aware of non P2MP capable nodes,= then >>they can automatically trigger a mechanism allowing support for non P2MP >>capable nodes (e.g. trigger a FA-LSP or LSP-segment to the next P2MP= capable >>node), or they may compute a Tree avoiding these nodes. > >[DP] ok and inline with the P2MP developments > >>>=3D> 4.2. Required Information >>> >>>>The TE Node Capability Descriptor TLV contains two variable length sets >>>>of bit flags: the Control Plane Capability flags and the Data Plane=20 >>>>Capability flags. Each flag corresponds to a given capability. Two flags >>>>are currently defined in the Data Plane Capability Flags: >>>>B bit: when set, this flag indicates that the LSR can act as a branch >>>>node on a P2MP LSP (see [P2MP-REQ]) and [RSVP-P2MP]). >>>>E bit: when set, this flag indicates that the LSR can act as a bud LSR= on >>>>a P2MP LSP, i.e. and LSR that is both transit and egress. >>>[DP] if your point is that a branch LSR could not necessarily be an= egress >>>then for a branch being also an egress both E and B bits should be set ? >>Yes, for a branch and egress capable node, both E and B bits should be= set. > >[DP] ok > >>>the question is related to the atomicity of the bits, i understand the B >>>bit (it means i can be a branch node in addition to a pre-defined set of >>>tapabilities assumed by default, in my view this should be spelled out or >>>pointed from the P2MP docs), in brief: B bit =3D branch node but doesn't= say >>>capability in terms of ending streams E bit =3D transit + egress >>>so probably B bit should also say branch + egress and then E bit would= only >>>appear as particular case of the B bit - do you see any restriction here= ? >>There may be cases where a node can act as a branch node but cannot act as= an >>egress (ie cannot end the stream), and we should handle these cases.=20 >>Basically we have two distinct capabilities, so we need two bits. (see >>section 5.12 of the P2MP requirements ID). > >[DP] if we consider branch that can't be egresses shall we then consider= that >any node should be by default able to be an egress ? > >>>>Three flags are currently defined in the Control Plane Capability Flags: >>>>M bit: when set, this flag indicates that the LSR supports MPLS-TE=20 >>>>signalling ([RSVP-TE]). >>>>G bit: when set this flag indicates that the LSR supports GMPLS=20 >>>>signalling ([RSVP-G]). >>>>P bit: when set, this flag indicates that the LSR supports P2MP MPLS-TE >>>>signalling ([RSVP-P2MP]). >>>[DP] is the P bit expected to be used only when the M bit is set ? >>The P2MP requirement document points out, in backward compatibility= section: >>"Unless administratively prohibited, P2P TE LSPs MUST be supported through= a >>P2MP network." >>So when the P bit is set the M bit should be set, but there may be= particular >>cases where the operator wants to dedicate an LSR for P2MP, and in that= case >>P is set and M is not set. > >[DP] ok > >>>also in that case P bit should refer also to GMPLS =3D> "P bit: when set, >>>this flag indicates that the LSR supports P2MP G/MPLS-TE signalling >>>([RSVP-P2MP])" >>Shouldn't we handle cases where an LSR support [RSVP-P2MP] for MPLS-TE but >>not for GMPLS (ie no support of 3473) ? > >[DP] but then we would need the counter-part for GMPLS RSVP P2MP, so=20 >basically can we expect nodes having MPLS for P2P & P2MP and GMPLS for P2P= only > >>>>Note that new flags may be added if required. >>>[DP] would be probably useful to indicate the criteria to be part of this >>>TLV >>Criteria =3D Any control plane capability that can be identified by a= single >>bit. We will add a sentence in next revision > >[DP] ok > >>>=3D> 4.3. Procedure >>> >>>>The TE Node Capability Descriptor TLV is carried in Link State=20 >>>>Advertisements. A router MUST originate a new Link State Advertisement >>>>whenever the content of this information changes, or whenever required= by >>>>regular routing procedure (e.g. refresh). >>>[DP] would you indicate that scaling should be preserved by this >>>advertisement since 1) it is not expected that it's variation be much >>>smaller than refresh time ans 2) usage of this information does not= trigger >>>generation (delayed via pacing or not) of a new advertisement) >>Agree, thanks, we will add some text on this point > >[DP] in the context of this functional document i would suggest to expand= on >this since it is one of the turn key to make this approach workable > >>>>TE Node Capability Descriptor TLVs are optional. When a Link State=20 >>>>Advertisement does not contain any TE Node capability Descriptor TLV,=20 >>>>this means that the TE Capabilities of that LSR are unknown. >>>[DP] what would extinction reflect in this context ? it would be >>>interesting to detail the expected behaviour of extinction (i.e. LSR lost >>>its capability) >>Once an LSR loose a given capability, an updated Link State Advertisement >>must be immediately flooded. The way how to handle such extinction (e.g.= LSP >>rerouting...) is beyond the scope of this draft. > >[DP] since this document describes functionality could be advisable to=20 >include the above statement in the text > >>>=3D> 5.1. Description >>> >>>>The PCE Discovery Information allows for the auto-discovery of one or >>>>more Path Computation Element(s). In various MPLS and GMPLS situations, >>>>such as inter-domain TE or backup path computation, an LSR may require >>>>to send a request to a Path Computation Element (PCE) to compute one or >>>>more TE LSPs paths obeying a set of specified constraints. Note that a >>>>PCE can be an LSR or an offline tool without any forwarding capability. >>>[DP] instead of mentioning "LSR or an offline tool" it would be better to >>>refer to co-located or a non-co-located tool because the accessibility is >>>independent on the location - the point is to avoid mentioning the TE= tool >>>access mode and make it independent from its localisation and= distribution >>Agree that the term "offline tool" is not appropriate here. What about "A= PCE >>can be a centralized tool, not forwarding packets, or an LSR" > >[DP] ok > >>>=3D> 5.2. Required Information >>> >>>>[...] >>>>L bit: Local scope. When set, this flag indicates that the PCE can=20 >>>>compute paths for the area/level the PCE Discovery Information TLV is >>>>flooded into (the PCE can compute TE LSP paths for intra-area TE LSPs). >>>>I bit: Inter-area scope. When set, the PCE can perform TE LSP path=20 >>>>computation for inter-area TE LSPs but within the same AS. >>>>A bit: Inter-AS scope. When set, the PCE can perform path computation= for >>>>inter-AS TE LSPs. >>>>Note that those flags are not exclusive (a PCE may set one or more= flags). >>>[DP] so imagine an inter-AS LSP for which an expansion (intra-area) has= to >>>be performed normal the L bit should be used however, it doesn't seem to= be >>>possible since restricted to intra-area LSPs so the above classification= is >>>imho performed in terms of "LSP scope" while it should also be provided= in >>>terms of computational scope no matter the type of LSP - so i would= suggest >>>to rework the text here above and decouple computation capability (scope) >>>from the LSP scope in its description >>>the issue is that we have "expansions" and "destination" (session= end-point) >>>- expansion of the ERO can be in the present context: intra-area or >>>multi-area which is coupled to the PCE capability - destination can be in >>>the same area (intra-area LSP), in a different area i.e. same AS >>>(multi-area LSP) and in a different AS (multi-AS LSP) >>>i think this point of discussion should be processed around these lines >>>(note that there are cases in the matrix that can be built from the above >>>that are unapplicable or simply irrelevant) >>Actually these bits refer to the capability of a PCE to process a request= for >>an intra/inter area/AS LSP, ie to participate in the computation of an >>intra/inter area/AS LSP, whatever the scope of its own computation= capability >>(ie it can compute it alone, or needs collaboration with other PCEs (ex an >>ABR)) >>Basically when a PCED capability TLV with the I bit set is flooded within= an >>area, this means that this PCE can handle an inter-area path computation >>request, and that all LSR in the area can send an inter-area Path= computation >>request to this PCE. LSRs don't need to known if this PCE can compute the >>path alone (e.g it has knwoledge of the topology of all areas) or if >>collaboration with other PCEs is required (e.g. an ABR). >>But I Agree that the current definitions do not well reflect that, and= have >>to be updated. >>E.g. for the I bit: >>"I bit: Inter-area support. When set, this flag indicates that the PCE can >>handle requests for computation of inter-area paths within the same AS (It >>can contribute partially or entirely in the computation of an inter-area >>path)" > >[DP] ok, would be clearer with this update (in addition to the=20 >corresponding revision of the definition for the L bit) > >>>>P bit: Request Priority. The notion of request priority allows a PCC to >>>>specify the degree of urgency of a particular request. When set, this >>>>flag indicates that the PCE takes into account the 'request priority' in >>>>its scheduling of the various requests. >>>[DP] would you clarify here - because if all routers receive this >>>information all of them can potentially make use of this information so= it >>>is not helping in solving the request scheduling in sequencing of the >>>request one may face with a PCE >>Some request are more urgent than others, for instance backup path >>computation requests. Some PCE may be able to prioritize requests and= others >>no. This flag allows an LSR selecting a PCE that can take into account >>request priority among a set of candidate PCEs >>Basically a Request priority policy can be configured on each LSR, for >>instance: Backup Computation: High priority Intra-area computation: Medium >>priority Inter-area computation: Low priority > >[DP] ok this clarifies the point - this bit is relevant when used in=20 >combination with request priority policy on PCC's > >>In case of LSP failure, the head-end will send a request with a high= priority >>to a PCE that support request prioritization >>Some policing may be also used on the PCE in order to avoid any priority >>abuse > >[DP] this would make sense in order to avoid any priority overload so it=20 >is also expected to be used in combination with policing on PCE's to=20 >ensure that the adertized capability can be met > >>>>M bit: Multiple Path Computation. When set, this flag indicates that the >>>>PCE is capable of computing more than one path obeying a set of= specified >>>>constraints (in a single pass), provided that they exist. >>>[DP] so it is a multi-path, multi-constraint computation ? >>It means that the LSR can compute a set of constrained path in a= coordinated >>manner. This bit does not indicate wether or not the PCE can compute paths >>with multiple additive constaints (also an NP-Hard problem) like e.g.= minimum >>cost bounded delay paths. This may require an additional bit. > >[DP] ok thanks for the clarification; would it be possible then to=20 >indicate (or something equivalent at your discretion) > >"M bit: indicates that the LSR can compute a set of constrained path in a= =20 >coordinated manner. > >Note: The M bit does not indicate whether or not the PCE can compute a set= =20 >of paths with multiple additive constaints (also an NP-Hard problem) like= =20 >e.g. minimum cost bounded delay paths. This requires an additional bit." The aim of the M bit is just to mention that the PCE has the ability to=20 compute a set of M paths, considering that those paths may have different=20 constraints *and* could be related (ex: compute a set of N link diverse= paths). >>>>D bit: Diversity. When set, this flag indicates that the PCE is capable >>>>of computing diversely routed paths (link, node, SRLG). The PCC may=20 >>>>request the PCE to compute N diversely routed paths obeying a set of >>>>specified constraints. Such N paths may not exist of course depending= on >>>>the current state of the network. >>>[DP] is that not a particular case of the previous bit ? >>Yes it is, if D is set M must also be set. > >[DP] ok, useful to indicate this specific case ok >>>>If the PCE is capable of computing inter-AS TE LSP path, the PCE=20 >>>>Discovery Information TLV MAY also contain the list of AS numbers >>>>identifying the AS for which the PCE can compute inter-AS TE LSP paths >>>>(TE-LSPs having their destination address in this AS). This set is >>>>optional and should be included only when the A bit is set. >>>[DP] did you evaluate the potential length of such advertisement ? and= the >>>"loop" created with BGP information ? since the text says "MAY also= contain >>>the list of AS numbers identifying the AS for which the PCE can compute >>>inter-AS TE LSP paths" so each time new AS's will be known this list=20 >>>will potentially be updated, drawing some lines along this point will=20 >>>help here; >>In practice an inter-AS TE "domain", will contained a limited number of >>ASes. Also, in case a PCE can compute an inter-AS Path for any destination >>AS, then destination ASes are not included. >>Further more the objective of this information is to allow balcaning path >>computation load among a set of PCEs in a given AS, based on destination >>ASes. For instance, an AS could contain 5 PCEs, each one being responsible >>for the computation of inter-AS LSPs to 20 destination ASes. This would= allow >>supporting an inter-AS TE "domain" comprising 100 ASes, with only 20 ASes >>listed per PCE. >>We will add some text on this point > >[DP] ok, this text will be useful - also, when you mention "inter-AS TE=20 >domain" do you mean a multi-AS single carrier environment ? or do you=20 >refer to something else ? May be multiple AS of the same SP or multiple AS of different SP. >>>another aspect is to distinguish between multi-AS single carrier and >>>multi-AS multi-carrier, and restrict the latter to stringent policy rules >>>in terms of AS path considered for LSP >>Yes, but again the goal of this information is more a way to allow an LSR >>selecting the appropriate PCE among a set of candidate PCE, when the >>computation load is balanced based on the destination AS. Policy rules for >>AS-path selection are beyond the scope of this ID, and should be addressed= in >>separate drafts > >[DP] i understand that policy for AS path selection is beyond the scope of= =20 >this document but the relevance of including this information as part of=20 >the IGP flooded information should be also clarified at some point in time but outside of the scope of the IGP flooding. >>>=3D> 5.3. Procedure >>> >>>>The PCE Discovery Information TLV is carried in Link State=20 >>>>Advertisements. A router MUST originate a new Link State Advertisement >>>>whenever the content of this information changes, or whenever required= by >>>> regular routing procedure (e.g. refresh) >>>>The PCE Discovery Information TLV is optional. >>>>If the PCE can compute an intra-area TE LSP path, the L bit MUST be=20 >>>>set.If it can compute an intra-area TE LSP path only for the LSRs in the >>>>area it resides in, then the PCE Discovery Information must be contained >>>>within an area. Otherwise, if the PCE can compute intra-area TE LSP >>>>paths for the whole AS, then the PCE Discovery Information TLV must be >>>>flooded across the whole AS. >>>[DP] how do you ensure that LSR's not being part of this area can reach= the >>>PCE (i.e. is there not a reachability constraint to be added here ? in >>>particular in case of non-co-located PCE identified by an IP address) - i >>>guess this point should be somehow clarified >>A PCE, supporting this draft, either LSR or centralized, will run the IGP. >>Thus it will be reacheable. We will clarify this point. > >[DP] but then you have to ensure that no IP data traffic could reach the=20 >centralized PCE (since by definition it will be only capable to process IP= =20 >control messages request/response, etc.) ie one has to exluce IP data=20 >traffic from the corresponding IP control channels Well, no, it is the choice of the operator to choose a PCE dedicated for=20 path computation or to activate the PCE function on an LSR forwarding= packets. >>>>If the PCE can compute an inter-area TE LSP path, the I bit MUST be set. >>>>If it can compute an inter-area TE LSP path only for the LSRs in the=20 >>>>area(s) it resides in (for instance the PCE is an ABR computing an=20 >>>>inter-area TE LSP path for its area), then the PCE Discovery= Information >>>>must be contained within this or these area(s). Else, if it can compute >>>>an inter-area TE LSP path for the whole AS, then the PCE Discovery=20 >>>>Information must be flooded across the whole AS. If the PCE can compute >>>>an inter-AS TE LSP path, the A bit MUST be set, and the PCE Discovery >>>>Information must be flooded across the whole AS. >>>[DP] probably it would be then be preferable to refer an "external AS"= path >>>since the PCE is able to perform three expansions: intra-area, inter-area >>>(single AS) and inter-AS (where AS in the latter refers to "external AS" >>>from the one of the path computation requestor)- see also above comment= =20 >>>concerning expansion vs session >>See above answser > >[DP] ok > >>>[...] =3D> 6.2. Required Information >>> >>>>The TE Mesh Group Information TLV allows an LSR to advertise the set of >>>>TE mesh-groups it belongs to. For each mesh group announced by the LSR, >>>>the TE Mesh Group Information TLV carries the following set of= information: >>> >>>>-A Mesh-Group number identifying the TE mesh-group, -A Tail-end address >>>>(address used as a tail end address by other LSRs belonging to the same >>>>mesh-group), >>>[DP] is this not part of the advertising router information, or you are >>>looking for an additional auxiliary information here to be used a Tunnel >>>end point address ? >>This is basically a 32 bit id used to identify a mesh-group >> >>>my concern is that there should be a statement then saying the Mesh group >>>ID must 1) be taken from a flat 32 bit id space 2) non routable= information >>>3) unicity on a per AS basis and 4) there is no containment relationship >>>wrt to the tail-end address space >>Agree, will add such statement > >[DP] ok > >>>>-A Tail-end name: string used to ease the TE-LSP naming (e.g.=20 >>>>'head-name->tail-name'). >>>[DP] is this to be used as part of the Session name field of the SESSION >>>ATTRIBUTE object or the Extended Tunnel ID ? >>Yes > >[DP] thanks for the clarification note that the head-end may or not decide to signal it in the SESSION= ATTRIBUTE. >>>=3D> 6.3. Procedure >>>[DP] here i am concerned with an operational aspect what happens when= this >>>information is not refreshed do the LSP have to be torn down, stay >>>unaffected ? >>They have to be torn down > >[DP] ok that it is expected to (potentially) trigger a subsequent=20 >signaling operation > >>>since as stated above "The TE Mesh-Group Information allows an LSR to >>>advertise its desire to join/leave one or more TE mesh-groups." >>>[DP] also a rule could be defined something like "A given TE Mesh Group= ID >>>information is to be considered by a node X for setting up n LSPs from= this >>>node X to a set of destination LSRs n if this TE mesh group ID value has >>>been advertised by that node X and received from a set of n nodes (n =3D<= N) >>>being part of that set" in order to clarify these procedures >>This is already implicitely mentionned in section 6.1 But actually such= rules >>are related to TE mesh group processing and not to IGP processing, and are >>thus beyond the scope of this draft. Maybe we need to detail a little bit >>more these TE-mesh group procedures, in the description section, in order= to >>allow for better understanding of the uses of this info. > >[DP] i agree it falls at the boundary on the other hand as there are no=20 >specific document for TE mesh groups this > >>Again thanks a lot for these highly relevant comments, Thanks for your comments. JP. >thanks, >- dimitri. > >>JL Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Jul 2004 00:08:12 +0000 Message-ID: <001601c47436$5ab25870$6f849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <aruns@movaz.com> Cc: <lb@movaz.com>, "Dimitri Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, "Dimitri Papadimitriou" <dpapadimitriou@psg.com>, "Reshad Rahman" <rrahman@cisco.com>, "'Anca Zamfir'" <ancaz@cisco.com>, <jisrar@cisco.com>, <ccamp@ops.ietf.org> Subject: draft-aruns-ccamp-rsvp-restart-ext-01.txt Date: Tue, 27 Jul 2004 20:05:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Thanks for coalescing your ideas into a single draft. Here are some random thoughts and questions for you to parse and then discard :-) Cheers, Adrian What if restarted node was doing PHP? Does egress (i.e. downstream node) have any record of the LSP? Presume so, and will be able to send back Resv saying implicit null. Need to describe procedures for multiple node restart? Although the procedures build on RFC3473, I detect some pressures to integrate this work into MPLS implementations. That is: RFC3209-based implementations intend to take the Hello processing and nodal restart function from RFC3473 and also the new processing described in this draft. How do we feel about this? Is this pick-and-mix approach OK or should we say that it is time for packet-based solutions to cut over to GMPLS PSC? Section 2.3 In the sender descriptor, the Recovery Label object MUST be included, with the label value copied from the label value in the Label object in the most recent associated Resv message sent to the restarted node, for the LSP being recovered. Arguably you are trying to carry this single piece of Resv state on the RecoveryPath message. I guess you might that this is information that will be added to the first Path message sent by the restarted node, but this is not true. You must make a clear case for needing this information in advance of the Resv that you will receive in due course. I don't think that section 2.4.2 does this. Section 2.3 I think you need to exclude <MESSAGE_ID_ACK> and <MESSAGE_ID_NACK> as copied objects and allow them as defined by RFC2961. Section 2.3 All other objects from the most recent received Path message MUST be included in the RecoveryPath message. I think you need to future-proof this by saying that the definition of new objects MAY specify that those objects MUST be omitted from the RecoveryPath message. Section 2.3 After sending a RecoveryPath message and during the Recovery Period, the node SHOULD periodically re-send the RecoveryPath message until it receives a corresponding response. A corresponding response is a Message ID acknowledgment or a Path message matching the RecoveryPath message. - Need to define whether it should continue to re-send for the whole period. Compare with the relatively short duration implied in MsgID retransmission - Need to define "periodically" Compare with the relatively rapid retransmission in MsgID retransmission - Need to define "matching". Is it enough that the received Path is for the same LSP, or does it need to match the RecoveryPath in more detail? 2.4. Procedures for the Restarting Node These procedures apply during the "state recovery process" and "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any RecoveryPath message received after the Recovery Period has expired MUST be discarded. A node MAY send a PathTear message downstream matching the discarded message. This is somewhat ambiguous. After all, a node MAY send a PathTear downstream at any time. If you are trying to say something more specific, please say it (e.g. "if there is no matching local LSP state"). 2.4.2. Re-Synchronization Procedures After receipt of the RecoveryPath message and, for non-ingress LSPs, the corresponding Path message with a Recovery Label object, the restarting node SHOULD Although it may be obvious, you should say how a node determines that it is the ingress for this LSP. 2.4.2 needs to describe what to do if the RecoveryPath (and/or recovery Path) can be matched to a LSP for which state is known, but does not completely match the record that the restarting node has. The most pressing example is what to do when the control plane state recovered through RFC3473 and these extensions does not match the data plane state in the restarting node. There may be a judgment call here since the upstream and downstream neighbors clearly know what they are talking about, yet the data plane may be carrying active traffic. Is it worth noting that when moving from 3473 to include these extensions, it may be necessary to increase the recovery period as there is more processing to be done? 2.4.3 Is it the case that we may receive a Path message with Recovery_Label from upstream and not match state. If so, we wait to receive a RecoveryPath message. If we do not receive one in the Recovery Period, we treat the Path message as if we were processing according to RFC3473. BUT, if we are processing according to RFC3473 and we have not responded to a Path message received with Recovery_Label in the Recovery Period, isn't the LSP abandoned? In other words, we will not send Resv for such an LSP until after the end of the Recovery Period. This is worse in section 2.5 if the downstream node does not support these extensions, when we will send no Resv for any recovered LSPs until after the Recovery Period. Would like to be able to globally de-select recovery path messages (if I have retained full state). Ideally this would be the default position so that RecoveryPath messages are not sent to a legacy node. I think Hello Capabilities should be used to select the willingness to receive RecoveryPath. (This would also ease the previous issue). Section 3 I think you have one more message exchange than you need. Imagine you have just one LSP. In the normal case you have just one message sent (RecoverySrefresh). In the non-recovered case you have three messages (RecoverySrefreh, Ack[Nack], RecoveryPath). *However* if the RecoverySrefresh was sent by the restarting node you would still have one message on the main case, and could drop to two messages in the non-recovered case (RecoverySrefresh, RecoveryPath). This would also make the RecoverySrefresh identical to the Srefresh, Further, since we know that this is used when only some of the state has been retained, it cuts down on the size of the RecoverySrefresh. Section 3 There is a slight issue with the Nack. We need to distinguish a Nack to an Srefresh (uses Message ID from a previous Resv) and a Nack to a RecoverySrefresh (uses Message ID from a previous Path). This is admittedly only a rare problem, but might occur with clashes of epoch and Message ID. This may be what you are trying to resolve using the new bit in the various Message ID objects (see below) but the reasoning is not clear from the text. Hint: if you use my proposal immediately above, this issue goes away and the new flag simplifies as below... 3.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects The trouble with defining an additional bit like this is we have to define the meaning of the bit on *any* Message_ID. Since (presumably) ordinary Srefresh messages may (might?) be interspersed with RecoverySrefresh why don't we have a way of distinguishing the messages rather than the contents of the object? Actually, I would argue that it is only the List Object that needs to be distinguished (with the caveat of the previous point). 3.2. Capability Object One of the lessons of the Restart_Cap Object is that we should be careful with the specification of capabilities objects. So, I am concerned that your new object is defined as a fixed length object with space for another 31 bits of information. How about TLVs? 3.2.2. Compatibility You missed forwards compatibility. That is: reserved bits MUST be set to zero on transmission and MUST be ignored on receipt. Nits === Need to expand citations in the Abstract. The Abstract could probably be usefully made shorter. Section 3, second para. I don't think we need the description of Srefresh in normal processing. Section 9. IANA Could you beef up this section please. The ideal is to show the names and characteristics of new messages/objects in this section so that IANA does not have to ask any further questions. You might like to reference draft-kompella-zinin-early-allocation-02.txt and draft-kompella-rsvp-change-02.txt to sort out values to use for pre-RFC work. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Jul 2004 00:08:04 +0000 Message-ID: <001701c47436$5d128f90$6f849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Zafar Ali" <zali@cisco.com>, "Dimitri Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, "Dimitri Papadimitriou" <dpapadimitriou@psg.com>, "'Danny Prairie'" <dprairie@cisco.com>, "Reshad Rahman" <rrahman@cisco.com> Cc: <ccamp@ops.ietf.org> Subject: draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt Date: Tue, 27 Jul 2004 20:20:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Just a couple of comments. Cheers, Adrian 2. Introduction Even in the case of packet MPLS, when link failure detection is performed by some means other than RSVP Hellos (e.g., [BFD]), the use of node-id based Hellos is also optimal for detection of signaling adjacency failures for RSVP-TE. This optimally only applies when there is more than one link between a pair of node, right? Say so? Ditto section 3. 2. Introduction This document also clarifies the use of node-id based Hellos when all or a sub-set of TE links are unnumbered. This draft also clarifies use of node-id based Hellos in these scenarios. Repeated? 3. Node-id based RSVP Hellos When a node receives a Hello packet where the destination IP address is its local node-id as advertised in the IGP-TE topology, the node MUST use its node-id in replying to the Hello message. This is an interesting use of MUST when the receiving node knows that the use of node-id is inappropriate. I think it is really cute that Danny and Reshad have decided to swap email addresses :-) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Jul 2004 09:44:27 +0000 Message-ID: <004c01c473be$0e9f5500$455708c3@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org>, <mpls@ietf.org>, "TEWG" <te-wg@ops.ietf.org> Subject: PCE BOF date/time Date: Tue, 27 Jul 2004 10:17:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Apologies for the confusion about the date and time of this BOF. The latest version of the agenda appears to have moved it to THURSDAY, August 5, 2004 1300-1500 Afternoon Sessions I RTG pce Path Computation Element BOF No idea whether this is final. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Jul 2004 09:44:19 +0000 Message-ID: <004d01c473be$0fbb7360$455708c3@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Tomohiro Otani" <otani@kddilabs.jp>, <mc-hayashi@kddilabs.jp>, <okamoto.satoru@lab.ntt.co.jp> Cc: <ccamp@ops.ietf.org> Subject: draft-otani-ccamp-interas-gmpls-te-00.txt Date: Tue, 27 Jul 2004 10:41:28 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C473C6.45FDB430" This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C473C6.45FDB430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, A nice short draft. Congratulations! Also, it is very good to see SPs bringing forward requirement drafts. = Thank you. I understand the point you are making in the draft, but I am not sure it = is specific to GMPLS and switching capabilities. For example, suppose we modify the bandwidth in your MPLS example = network to: +----+ +----+ | +----+ +----+=20 | A1 |----//----| A3 |---------| B1 |----//----| B3 |=20 +----+ 10G +----+ 10G +----+ 2.5G +----+=20 | | | | | =20 =3D2.5G =3D10G | =3D2.5G =3D2.5G=20 | | | | | =20 +----+ +----+ | +----+ +----+=20 | A2 |----//----| A4 |---------| B2 |----//----| B4 |=20 +----+ 2.5G +----+ 10G +----+ 10G +----+=20 |=20 MPLS AS 1 | MPLS AS 2=20 Now, set up a 10G service from A1 to B4. AS 1 is going to select the ASBR pair A3/B1 as the shortest path out of = AS 1. But B1 will fail the setup. We must rely on crankback or a wider view (PCE, TE aggregation, etc.) in = order to be successful. I think what your draft points out, however, is that the complexity for = GMPLS is increased considerably (perhaps to a power of three). It is = further worth noting that if we added some speculative future routing = constraints (such as source-based lambda selection, optical impairments, = etc.) the problem would get even more complex. Essentially, however, the problem is the same: IP route aggregation is = not sufficient to enable inter-domain TE and some other solution is = needed. Your proposal for EGP extensions to general reachability = information is certainly one option.=20 The concern that I have heard voiced is that there may be significant = churn in this information, and this would result in a significant amount = of aggregation computation by the ASBRs. My view is that: - in a non-PSC GMPLS network the rate of change is=20 not likely to be significant - we should, in any case, specify damping of computation and updates if we proceed with this approach. But I would be interested to hear this debated further especially by the = EGP experts. Your point about SRLGs is very valid. Currently, however, (as I = understand it) we don't have a satisfactory encoding for SRLG IDs to = allow an ID to be globally unique *and* to allow an SRLG to span ASs. Thanks, Adrian ------=_NextPart_000_0049_01C473C6.45FDB430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY> <DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>A nice short draft. = Congratulations!</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Also, it is very good to see SPs = bringing forward=20 requirement drafts. Thank you.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>I understand the point you are making = in the=20 draft, but I am not sure it is specific to GMPLS and switching=20 capabilities.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>For example, suppose we modify the = bandwidth in=20 your MPLS example network to:</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2> =20 +----+ =20 +----+ | =20 +----+ =20 +----+ <BR> | A1 |----//----| A3 |---------| B1 |----//----| = B3=20 | <BR> +----+ 10G +----+ = 10G +----+ 2.5G =20 +----+ <BR> =20 | = =20 | = | =20 | = =20 | <BR> =20 =3D2.5G = =3D10G =20 | =20 =3D2.5G =20 =3D2.5G <BR> =20 | = =20 | = | =20 | = =20 | <BR> =20 +----+ =20 +----+ | =20 +----+ =20 +----+ <BR> | A2 |----//----| A4 |---------| B2 |----//----| = B4=20 | <BR> +----+ 2.5G +----+ = 10G +----+ 10G =20 +----+ <BR> =20 &= nbsp; =20 | <BR> MPLS AS=20 1 =20 | MPLS AS 2 = <BR></FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Now, set up a 10G service from = A1 to=20 B4.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>AS 1 is going to select the ASBR pair = A3/B1 as=20 the shortest path out of AS 1.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>But B1 will fail the = setup.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>We must rely on crankback or a wider = view (PCE,=20 TE aggregation, etc.) in order to be successful.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2> </DIV></FONT> <DIV><FONT face=3DCourier size=3D2>I think what your draft points out, = however, is=20 that the complexity for GMPLS is increased considerably (perhaps to a = power of=20 three). It is further worth noting that if we added some speculative = future=20 routing constraints (such as source-based lambda selection, optical = impairments,=20 etc.) the problem would get even more complex.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Essentially, however, the problem is = the same: IP=20 route aggregation is not sufficient to enable inter-domain TE and some = other=20 solution is needed. Your proposal for EGP extensions to general = reachability=20 information is certainly one option. </FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>The concern that I have heard voiced = is that=20 there may be significant churn in this information, and this would = result in a=20 significant amount of aggregation computation by the ASBRs. My view is=20 that:</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>- in a non-PSC GMPLS network the rate = of change=20 is </FONT></DIV> <DIV><FONT face=3DCourier size=3D2> not likely to be=20 significant</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>- we should, in any case, specify = damping of=20 computation</FONT></DIV> <DIV><FONT face=3DCourier size=3D2> and updates if we proceed = with this=20 approach.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>But I would be interested to hear = this debated=20 further especially by the EGP experts.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Your point about SRLGs is very valid. = Currently,=20 however, (as I understand it) we don't have a satisfactory encoding for = SRLG IDs=20 to allow an ID to be globally unique *and* to allow an SRLG to span=20 ASs.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV></BODY></HTML> ------=_NextPart_000_0049_01C473C6.45FDB430-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Jul 2004 21:58:18 +0000 Message-Id: <4.3.2.7.2.20040726175746.033cd1b8@wells.cisco.com> Date: Mon, 26 Jul 2004 17:58:05 -0400 To: ccamp@ops.ietf.org, OSPF@DISCUSS.MICROSOFT.COM, isis-wg@ietf.org From: Jean Philippe Vasseur <jvasseur@cisco.com> Subject: Update on the IGP TE capability drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >X-BrightmailFiltered: true >X-BrightmailFiltered: true >X-Sender: jvasseur@wells.cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >Date: Mon, 26 Jul 2004 17:53:53 -0400 >Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM> >Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM> >From: Jean Philippe Vasseur <jvasseur@cisco.com> >Subject: Update on the ISIS TE capability draft >Comments: To: ccamp@ops.ietf.org, OSPF@DISCUSS.MICROSOFT.COM, isis-wg@ietf.org >Comments: cc: zinin@psg.com >To: OSPF@PEACH.EASE.LSOFT.COM >X-PMX-Version: 4.6.1.107272 >X-from-outside-Cisco: 128.107.250.145 > >Hi, > >A quick update on the IGP TE capability drafts. > >There used to be two drafts proposing several TE-related extensions: > draft-vasseur-ccamp-isis-te-caps > draft-vasseur-ccamp-ospf-te-caps > >Based on the input from our AD and WG chairs, we restructured this work and >came up with three drafts: > draft-vasseur-ccamp-te-router-info-00 (discussed in CCAMP) > >and the IGP specific (sub)TLV encoding and elements of procedure are >defined in: > draft-vasseur-isis-te-caps-00 (in ISIS) > draft-vasseur-ospf-te-caps-00 (in OSPF) > >Comments are of course very welcome. > >JP and al. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Jul 2004 21:57:04 +0000 Message-Id: <4.3.2.7.2.20040726174734.05ffa730@wells.cisco.com> Date: Mon, 26 Jul 2004 17:53:53 -0400 To: ccamp@ops.ietf.org, OSPF@DISCUSS.MICROSOFT.COM, isis-wg@ietf.org From: Jean Philippe Vasseur <jvasseur@cisco.com> Subject: Update on the ISIS TE capability draft Cc: zinin@psg.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, A quick update on the IGP TE capability drafts. There used to be two drafts proposing several TE-related extensions: draft-vasseur-ccamp-isis-te-caps draft-vasseur-ccamp-ospf-te-caps Based on the input from our AD and WG chairs, we restructured this work and came up with three drafts: draft-vasseur-ccamp-te-router-info-00 (discussed in CCAMP) and the IGP specific (sub)TLV encoding and elements of procedure are defined in: draft-vasseur-isis-te-caps-00 (in ISIS) draft-vasseur-ospf-te-caps-00 (in OSPF) Comments are of course very welcome. JP and al. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Jul 2004 17:18:13 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01B753DB@nimbus.chromisys.com> From: John Drake <jdrake@calient.net> To: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org Subject: RE: Draft agenda for San Diego Date: Mon, 26 Jul 2004 10:16:07 -0700 MIME-Version: 1.0 Content-Type: text/plain Adrian, The agenda looks fine to me. Thanks, John > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, July 21, 2004 9:09 AM > To: ccamp@ops.ietf.org > Subject: Draft agenda for San Diego > > Hi, > > Here is an early draft agenda for CCAMP in San Diego. > > As usual there is a high volume of drafts that people want to 'present'. > Of necessity, > therefore, some of you must be disappointed. The usual comments apply: > > - The main place for presentation of your draft is the mailing list > - Discussion of your draft needs to be on the mailing list > (discussions at the meetings don't carry much weight) > > In order to make sure that drafts that do not get explicit slots on the > agenda are not > forgotten, the chairs will attempt to mention some of the key ones, give > status, and > encourage debate on the mailing list. > > (The larger amounts of time dedicated to inter-domain is in anticipation > of a healthy > degree of debate.) > > Thanks, > Adrian > > === > > CCAMP 60 - San Diego - Draft Agenda > [running total 150 / 150] > > Group Admin (Chairs) > Admin and agenda bash (5 mins) > Status of WG and drafts (5 mins) > http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-te-router- > info-00.txt > http://www.ietf.org/internet-drafts/draft-vasseur-isis-te-caps- > 00.txt > http://www.ietf.org/internet-drafts/draft-vasseur-ospf-te-caps- > 00.txt > http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-loose- > path-reopt-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm- > spec-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback- > 02.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te- > exclude-route-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib- > 05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr- > mib-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib- > 05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tunproto- > 00.txt > > http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te- > bundled-links-00.txt > http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip- > interworking-03.txt > > http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-misconnection- > analysis-00.txt > http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier- > survey-00.txt > > Milestones and objectives (5 mins) > > ASON Requirements and Solutions > ASON Signaling and Routing Requirements and other cooked drafts (Adrian) > (2 mins) > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts- > 06.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason- > routing-reqts-04.txt > http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control- > 02.txt > > ASON Signaling Solutions (Dimitri Papadimitriou) (5 mins) > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te- > ason-01.txt > > ASON Routing Solutions Design Team status (Dimitri Papadimitriou) (10 > mins) > - charter & team > - plans > - drafts > > A Transport Network View of LMP (Don Fedyk) (5 minutes) > http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-transport- > lmp-02.txt > - why this draft? > - adopt as WG draft? > > SG15 liaison (Wesam Alanqar 5 mins) > > Protection and Restoration > Drafts in AD review (Adrian) (2 mins) > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery- > analysis-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery- > functional-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery- > terminology-03.txt > > End-to-end recovery (Dimitri Papadimitriou) (5 mins) > > http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e- > signaling-02.txt > - ready for last call? > > Segment Recovery (Lou Berger) (5 mins) > http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment- > recovery-00.txt > - ready for last call? > > Hello Protocol and Graceful Restart > Graceful restart (Lou Berger) (10 minutes) > http://www.ietf.org/internet-drafts/draft-aruns-ccamp-rsvp-restart- > ext-01.txt > - good ideas? > - adopt as WG draft? > Node-id-based Hello (Zafar Ali) (5 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id- > based-hello-00.txt > - implementation status > - ready for last call > Graceful restart (Zafar Ali / Anca Zamfir) (5 minutes) > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful- > shutdown-00.txt > - good ideas? > - adopt as WG draft? > > Inter-Area/AS > Strategy (Kireeti) (10 minutes) > - definitions and overview > - simple requirements first > - protection and other diverse path requirements later > - PCE BOF > > Inter-domain Framework (Adrian) (15 minutes) > http://www.ietf.org/internet-drafts/draft-farrel-ccamp-inter-domain- > framework-01.txt > - generality of "domain" > - separation of routing, path computation and signaling > - no attention to diverse paths at this stage > - WG adopt? > > Inter-domain RSVP-TE (Arthi Ayyangar) (15 minutes) > http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain- > rsvp-te-00.txt > - Purpose of draft? > - Main issues > - WG adopt? > > Inter-domain TE LSP path computation methods (JP Vasseur) (15 minutes) > http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-inter-domain- > path-comp-00.txt > - Purpose of draft? > - Main issues > - Overlap with PCE BOF? > - WG adopt? > > GMPLS Inter-AS requirements (Tomohiro Otani) (10 minutes) > http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls- > te-00.txt > - Why a separate draft? > - What are the main features? > > Summary of other work > Layer 2 GMPLS (Dimitri Papadimitriou) (5 mins) > http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls- > l2sc-lsp-02.txt > - what's it about? > - adopt as WG draft? > > Layer 1 VPNs (Tomonori Takeda) (5 mins) > - status and plans > - still progressing "under the care of CCAMP" > - mailing list > http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework- > 01.txt > http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability- > 00.txt > http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn- > bgpgmpls-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay- > 04.txt > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 25 Jul 2004 17:21:00 +0000 Message-ID: <4103EBED.4080703@psg.com> Date: Sun, 25 Jul 2004 19:20:45 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> CC: dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org Subject: Re: Waveband Switching [Was Re: draft-douville-ccamp-gmpls-waveband-extensions-05.txt] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian, see in-line for additional clarifications on the reasoning Adrian Farrel wrote: > Hi Dimitri, > > I'm not sure what you are asking. > > I think you are asking "Does anyone out there care about waveband switching?" > > We might refine this question for: > a. now > b. in the next two years > c. sometime > d. never. > > It is slightly interesting to look at the 9/22 respondents to the GMPLS implementation > survey (November 2002). > Of these, two are software vendors and one a test tool manufacturer. All are forced to > implement, by definition. > Of the others, one flagged "future", one was a CR-LDP product, and one a research > implementation. > So I could argue that this leaves us with just three. question is also that i found 9 waveband labels but as implied from existing document only inverse mux or concatenated wavelength (i.e. no real band mux/ demux) can be supported as no WBSC capability has been defined > But it is probably more important to find out where we stand now. agreed > So, question to the list... > > Who believes that we need to complete the work on waveband switching in order to meet real > implementation or deployment requirements? interestingly i found also 9 implementations supporting FSC, 7 of which were the same as those supporting Waveband label (LSC being covered by all of them except 1) this reinforces the initial assumption thanks, - dimitri. > Thanks, > Adrian > > >>as mentioned in the additional ccamp webpage, this draft plugs a hole however >>interest shown on this list is certainly low >> >>but so at the end of the day one may ask if this is the case >> >>1) how implementations that have been reported in >><http://www.ietf.org/IESG/Implementations/MPLS-SIGNALING-Implementation.txt> >> >>9 supports waveband labels so do we have to make the assumption that all of them >>support only inverse multiplexing mechanism and/or wavelength concatenation ? >> >>2) then what about Fiber SC ? >> >>this leaves the impression that the FSC value has been sometimes used when >>switching the whole content of the container (ie the fiber) while following a >>strict interpretation it is meant to only address spatial switching per GMPLS ARCH: >> >>"5. Fiber-Switch Capable (FSC) interfaces: >> >> Interfaces that switch data based on a position of the data in the >> (real world) physical spaces. An example of such an interface is >> that of a PXC or OXC that can operate at the level of a single or >> multiple fibers." >> >>thanks, >>- dimitri. >> >>-------- Original Message -------- >>Subject: I-D ACTION:draft-douville-ccamp-gmpls-waveband-extensions-05.txt >>Date: Thu, 22 Jul 2004 15:33:35 -0400 >>From: Internet-Drafts@ietf.org >>To: i-d-announce@ietf.org >> >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >>Title : Extensions to Generalized Multi-Protocol Label Switching >> in support of Waveband Switching >>Author(s) : R. Douville, et al. >>Filename : draft-douville-ccamp-gmpls-waveband-extensions-05.txt >>Pages : 11 >>Date : 2004-7-22 >> >>Generalized Multi-Protocol Label Switching (GMPLS) extends the MPLS >> control plane to encompass layer 2, time-division, wavelength and >> spatial switching. Along with the current development on IP over >> optical switching, considerable advances in optical transport >> systems based on the multiple optical switching granularities have >> been developed. >> >> Currently, GMPLS considers two layers of optical granularity using >> wavelengths and fibers. By introducing an extended definition of >> waveband switching, this document specifies the corresponding GMPLS >> extensions, to further integrate optical multi-granularity and >> benefit from the features of the corresponding switching layers. >> >>A URL for this Internet-Draft is: >> > > http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-05.txt > >>To remove yourself from the I-D Announcement list, send a message to >>i-d-announce-request@ietf.org with the word unsubscribe in the body of the >>message. >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>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-douville-ccamp-gmpls-waveband-extensions-05.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-douville-ccamp-gmpls-waveband-extensions-05.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. >> >> >> > > > > -------------------------------------------------------------------------------- > > > >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 25 Jul 2004 17:17:22 +0000 Message-Id: <5.1.1.11.2.20040726013912.00cf56c8@cronos.ocn.ne.jp> Date: Mon, 26 Jul 2004 01:47:32 +0900 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be From: Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp> Subject: Re: [L1vpn] Fwd: I-D ACTION:draft-takeda-l1vpn-framework-01.txt Cc: l1vpn@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Hi Dimitri, (Now cced to the CCAMP mailing list as well) Thank you for your comments. We would like to consider text for security section based on the content of section 8, as you suggested. I would expect we need to cover control plane, data plane and management plane aspects, as well as configuration (e.g., addition of new CE/VPN) and access control (e.g., signaling). And as you suggested, it would better to inform the status of documents on the CCAMP maling list as well. [L1VPN Framework draft] http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-01.txt Updates in 01 version: o Clarification and enhancements for comments received: - Addition of definition for new/different terminologies (section 2) - Addition of more detailed requirements from ITU-T SG13 (section 8) - Clear description of virtual link service model and per VPN peer service model (sections 7.3.2 and 7.3.3) - Text clarfication (i.e., shared control link, performance) o More description on virtual node service model (section 7.3.1) o Modification of table 1 in section 8 (inclusion of virtual node service model in the table, etc.) o Bunch of editorial enhancements [L1VPN applicabilty draft] http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-00.txt - Shows how existing GMPLS architectures and protocols can be applied to L1VPNs - Identifies any areas where additional protocol extensions or procedures are necessary to support L1VPNs Comments are highly appreciated. Best regards, At 14:57 04/07/23 +0200, dimitri papadimitriou wrote: >hi, i was looking at the security section and it is said TBD, it would imho interesting to see what are the specific aspects here as pointed out in section 8: "- Security: The communication between the customer and the provider >must be secure." and expand on it, also in terms of inband communication security over DCC/GCC channels > >note: as this document is still under the care of the CCAMP WG would it be possible to give a status of the document progress on the CCAMP mailing list > >much thanks, >- dimitri. > >Tomonori TAKEDA wrote: > >> Hi, >> We have submitted the revised version of L1VPN framework draft. >> As I posted previously, >> Updates in 01 version: >> o Clarification and enhancements for comments received: >> - Addition of definition for new/different terminologies (section 2) >> - Addition of more detailed requirements from ITU-T SG13 (section 8) >> - Clear description of virtual link service model and per VPN peer service model (sections 7.3.2 and 7.3.3) >> - Text clarfication (i.e., shared control link, performance) >> o More description on virtual node service model (section 7.3.1) >> o Modification of table 1 in section 8 (inclusion of virtual node service model in the table, etc.) >> o Bunch of editorial enhancements >> Comments are highly appreciated. >> Best regards, >> >To: i-d-announce@ietf.org >> >From: Internet-Drafts@ietf.org >> >Date: Thu, 22 Jul 2004 15:33:44 -0400 >> >Subject: I-D ACTION:draft-takeda-l1vpn-framework-01.txt >> >X-BeenThere: i-d-announce@ietf.org >> >X-Mailman-Version: 2.1.5 >> >Reply-To: internet-drafts@ietf.org >> >List-Id: i-d-announce.ietf.org >> >List-Unsubscribe: >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:i-d-announce-request@ietf.org?subject=unsubscribe> >> >List-Post: <mailto:i-d-announce@ietf.org> >> >List-Help: <mailto:i-d-announce-request@ietf.org?subject=help> >> >List-Subscribe: >> ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:i-d-announce-request@ietf.org?subject=subscribe> >> >Sender: i-d-announce-bounces@ietf.org >> > >> >A New Internet-Draft is available from the on-line Internet-Drafts directories. >> > >> > >> > Title : Framework for Layer 1 Virtual Private Networks >> > Author(s) : T. Takeda >> > Filename : draft-takeda-l1vpn-framework-01.txt >> > Pages : 23 >> > Date : 2004-7-22 >> > >> >This document provides a framework for Layer 1 Virtual Private >> > Networks (L1VPNs). This framework is intended to aid in developing >> > and standardizing protocols and mechanisms to support interoperable >> > L1VPNs. >> > >> > The document examines motivations for L1VPNs, high level (service >> > level) requirements, and outlines some of the architectural models >> > that might be used to build L1VPNs. >> > >> >A URL for this Internet-Draft is: >> >http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-01.txt >> > >> >To remove yourself from the I-D Announcement list, send a message to >> >i-d-announce-request@ietf.org with the word unsubscribe in the body of the >> >message. >> >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> >to change your subscription settings. >> > >> > >> >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-takeda-l1vpn-framework-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-takeda-l1vpn-framework-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. >> > >> >Content-Type: text/plain >> >Content-ID: <2004-7-22145222.I-D@ietf.org> >> > >> >ENCODING mime >> >FILE /internet-drafts/draft-takeda-l1vpn-framework-01.txt >> > >> > >> ><ftp://ftp.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-01.txt> >> >_______________________________________________ >> >I-D-Announce mailing list >> >I-D-Announce@ietf.org >> >https://www1.ietf.org/mailman/listinfo/i-d-announce >> ----- >> Tomonori TAKEDA >> NTT Network Service Systems Lab. >> Phone: +81-422-59-7434 >> >> _______________________________________________ >> L1vpn mailing list >> L1vpn@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/l1vpn >> . >> ----- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 25 Jul 2004 17:13:38 +0000 Message-ID: <4103EA33.1020206@psg.com> Date: Sun, 25 Jul 2004 19:13:23 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@francetelecom.com> CC: Dimitri.Papadimitriou@alcatel.be, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org, Jean Philippe Vasseur <jvasseur@cisco.com> Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit hi jean-louis, much thanks for your reply and suggestions, see in-line LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Dimitri and all, > > Thanks a lot for these really useful comments Please see inline > >> -----Message d'origine----- De : Dimitri.Papadimitriou@alcatel.be >> [mailto:Dimitri.Papadimitriou@alcatel.be] Envoyé : jeudi 22 juillet 2004 >> 20:43 À : Adrian Farrel Cc : ccamp@ops.ietf.org; 'Jean Philippe Vasseur'; >> LE ROUX Jean-Louis RD-CORE-LAN Objet : Re: >> draft-vasseur-ccamp-te-router-info-00 >> >> hi adrian, all, >> >> here below a bunch of comments on this documents: >> >> => 3. Introduction >> >>> - Data plane capabilities related to the node itself and not to its >>> links, such as the capability to be a branch node or a bud LSR of a P2MP >>> LSP tunnel (see [P2MP-REQ]). These node capabilities should be advertised >>> by the IGP for path selection. It would also be highly useful to >>> advertise control plane node Capabilities; for instance, the capability >>> to support GMPLS signaling for a packet LSR, or the capability to >>> support P2MP signaling. This would ease backward compatibility. For >>> instance this would allow selecting a path that would avoid nodes that do >>> not support a given signaling feature, or automatically triggering a >>> mechanism that would handle these nodes on the path. >> >> [DP] suggest to translate the protocol specific also within the above text >> with something like >> >> - Nodal capabilities >> >> 1) control plane >> >> 2) data plane > > In 4.2 we define two distinct pieces of Information: Control Plane Capability > Flags and Data Plane Capability Flags, but agree that this separation should > appear more clearly in the intro. Will update [DP] ok >> => 4.1. Description >> >>> LSRs in a network may have distinct control plane and data plane Traffic >>> Engineering capabilities. The TE Node capability Descriptor TLV describes >>> data and control plane capabilities of an LSR. Such information can be >>> used for instance for path computation algorithm so as to avoid nodes >>> that do not support a given TE feature either in the control or data >>> plane or to trigger procedure to handle these nodes. In some case, this >>> may also be useful for backward compatibility. >> >> [DP] suggest to detail the backward compatibility aspects ? i guess it is >> to provide support of legacy LSRs ? > > Definitely, the goal of this information is to ease operations in a mixed > environment made of capable and incapable nodes, wrt several control plane > capabilities. Knowledge of incapable nodes, allows capable nodes either > triggering mechanisms in order to support these nodes, or computing a path > avoiding these nodes > > For instance, If P2MP capable nodes are aware of non P2MP capable nodes, then > they can automatically trigger a mechanism allowing support for non P2MP > capable nodes (e.g. trigger a FA-LSP or LSP-segment to the next P2MP capable > node), or they may compute a Tree avoiding these nodes. [DP] ok and inline with the P2MP developments >> => 4.2. Required Information >> >>> The TE Node Capability Descriptor TLV contains two variable length sets >>> of bit flags: the Control Plane Capability flags and the Data Plane >>> Capability flags. Each flag corresponds to a given capability. Two flags >>> are currently defined in the Data Plane Capability Flags: >>> >>> B bit: when set, this flag indicates that the LSR can act as a branch >>> node on a P2MP LSP (see [P2MP-REQ]) and [RSVP-P2MP]). >>> >>> E bit: when set, this flag indicates that the LSR can act as a bud LSR on >>> a P2MP LSP, i.e. and LSR that is both transit and egress. >> >> [DP] if your point is that a branch LSR could not necessarily be an egress >> then for a branch being also an egress both E and B bits should be set ? > > Yes, for a branch and egress capable node, both E and B bits should be set. [DP] ok >> the question is related to the atomicity of the bits, i understand the B >> bit (it means i can be a branch node in addition to a pre-defined set of >> tapabilities assumed by default, in my view this should be spelled out or >> pointed from the P2MP docs), in brief: B bit = branch node but doesn't say >> capability in terms of ending streams E bit = transit + egress >> >> so probably B bit should also say branch + egress and then E bit would only >> appear as particular case of the B bit - do you see any restriction here ? > > There may be cases where a node can act as a branch node but cannot act as an > egress (ie cannot end the stream), and we should handle these cases. > Basically we have two distinct capabilities, so we need two bits. (see > section 5.12 of the P2MP requirements ID). [DP] if we consider branch that can't be egresses shall we then consider that any node should be by default able to be an egress ? >>> Three flags are currently defined in the Control Plane Capability Flags: >>> >>> M bit: when set, this flag indicates that the LSR supports MPLS-TE >>> signalling ([RSVP-TE]). >>> >>> G bit: when set this flag indicates that the LSR supports GMPLS >>> signalling ([RSVP-G]). >>> >>> P bit: when set, this flag indicates that the LSR supports P2MP MPLS-TE >>> signalling ([RSVP-P2MP]). >> >> [DP] is the P bit expected to be used only when the M bit is set ? > > The P2MP requirement document points out, in backward compatibility section: > "Unless administratively prohibited, P2P TE LSPs MUST be supported through a > P2MP network." > > So when the P bit is set the M bit should be set, but there may be particular > cases where the operator wants to dedicate an LSR for P2MP, and in that case > P is set and M is not set. [DP] ok >> also in that case P bit should refer also to GMPLS => "P bit: when set, >> this flag indicates that the LSR supports P2MP G/MPLS-TE signalling >> ([RSVP-P2MP])" > > Shouldn't we handle cases where an LSR support [RSVP-P2MP] for MPLS-TE but > not for GMPLS (ie no support of 3473) ? [DP] but then we would need the counter-part for GMPLS RSVP P2MP, so basically can we expect nodes having MPLS for P2P & P2MP and GMPLS for P2P only >>> Note that new flags may be added if required. >> >> [DP] would be probably useful to indicate the criteria to be part of this >> TLV > > Criteria = Any control plane capability that can be identified by a single > bit. We will add a sentence in next revision [DP] ok >> => 4.3. Procedure >> >>> The TE Node Capability Descriptor TLV is carried in Link State >>> Advertisements. A router MUST originate a new Link State Advertisement >>> whenever the content of this information changes, or whenever required by >>> regular routing procedure (e.g. refresh). >> >> [DP] would you indicate that scaling should be preserved by this >> advertisement since 1) it is not expected that it's variation be much >> smaller than refresh time ans 2) usage of this information does not trigger >> generation (delayed via pacing or not) of a new advertisement) > > Agree, thanks, we will add some text on this point [DP] in the context of this functional document i would suggest to expand on this since it is one of the turn key to make this approach workable >>> TE Node Capability Descriptor TLVs are optional. When a Link State >>> Advertisement does not contain any TE Node capability Descriptor TLV, >>> this means that the TE Capabilities of that LSR are unknown. >> >> [DP] what would extinction reflect in this context ? it would be >> interesting to detail the expected behaviour of extinction (i.e. LSR lost >> its capability) > > Once an LSR loose a given capability, an updated Link State Advertisement > must be immediately flooded. The way how to handle such extinction (e.g. LSP > rerouting...) is beyond the scope of this draft. [DP] since this document describes functionality could be advisable to include the above statement in the text >> => 5.1. Description >> >>> The PCE Discovery Information allows for the auto-discovery of one or >>> more Path Computation Element(s). In various MPLS and GMPLS situations, >>> such as inter-domain TE or backup path computation, an LSR may require >>> to send a request to a Path Computation Element (PCE) to compute one or >>> more TE LSPs paths obeying a set of specified constraints. Note that a >>> PCE can be an LSR or an offline tool without any forwarding capability. >> >> [DP] instead of mentioning "LSR or an offline tool" it would be better to >> refer to co-located or a non-co-located tool because the accessibility is >> independent on the location - the point is to avoid mentioning the TE tool >> access mode and make it independent from its localisation and distribution > > Agree that the term "offline tool" is not appropriate here. What about "A PCE > can be a centralized tool, not forwarding packets, or an LSR" [DP] ok >> => 5.2. Required Information >> >>> [...] >>> >>> L bit: Local scope. When set, this flag indicates that the PCE can >>> compute paths for the area/level the PCE Discovery Information TLV is >>> flooded into (the PCE can compute TE LSP paths for intra-area TE LSPs). >>> >>> I bit: Inter-area scope. When set, the PCE can perform TE LSP path >>> computation for inter-area TE LSPs but within the same AS. >>> >>> A bit: Inter-AS scope. When set, the PCE can perform path computation for >>> inter-AS TE LSPs. >>> >>> Note that those flags are not exclusive (a PCE may set one or more >>> flags). >> >> [DP] so imagine an inter-AS LSP for which an expansion (intra-area) has to >> be performed normal the L bit should be used however, it doesn't seem to be >> possible since restricted to intra-area LSPs so the above classification is >> imho performed in terms of "LSP scope" while it should also be provided in >> terms of computational scope no matter the type of LSP - so i would suggest >> to rework the text here above and decouple computation capability (scope) >> from the LSP scope in its description >> >> the issue is that we have "expansions" and "destination" (session >> end-point) >> >> - expansion of the ERO can be in the present context: intra-area or >> multi-area which is coupled to the PCE capability - destination can be in >> the same area (intra-area LSP), in a different area i.e. same AS >> (multi-area LSP) and in a different AS (multi-AS LSP) >> >> i think this point of discussion should be processed around these lines >> (note that there are cases in the matrix that can be built from the above >> that are unapplicable or simply irrelevant) > > Actually these bits refer to the capability of a PCE to process a request for > an intra/inter area/AS LSP, ie to participate in the computation of an > intra/inter area/AS LSP, whatever the scope of its own computation capability > (ie it can compute it alone, or needs collaboration with other PCEs (ex an > ABR)) > > Basically when a PCED capability TLV with the I bit set is flooded within an > area, this means that this PCE can handle an inter-area path computation > request, and that all LSR in the area can send an inter-area Path computation > request to this PCE. LSRs don't need to known if this PCE can compute the > path alone (e.g it has knwoledge of the topology of all areas) or if > collaboration with other PCEs is required (e.g. an ABR). > > But I Agree that the current definitions do not well reflect that, and have > to be updated. > > E.g. for the I bit: > > "I bit: Inter-area support. When set, this flag indicates that the PCE can > handle requests for computation of inter-area paths within the same AS (It > can contribute partially or entirely in the computation of an inter-area > path)" [DP] ok, would be clearer with this update (in addition to the corresponding revision of the definition for the L bit) >>> P bit: Request Priority. The notion of request priority allows a PCC to >>> specify the degree of urgency of a particular request. When set, this >>> flag indicates that the PCE takes into account the 'request priority' in >>> its scheduling of the various requests. >> >> [DP] would you clarify here - because if all routers receive this >> information all of them can potentially make use of this information so it >> is not helping in solving the request scheduling in sequencing of the >> request one may face with a PCE > > Some request are more urgent than others, for instance backup path > computation requests. Some PCE may be able to prioritize requests and others > no. This flag allows an LSR selecting a PCE that can take into account > request priority among a set of candidate PCEs > > Basically a Request priority policy can be configured on each LSR, for > instance: Backup Computation: High priority Intra-area computation: Medium > priority Inter-area computation: Low priority [DP] ok this clarifies the point - this bit is relevant when used in combination with request priority policy on PCC's > In case of LSP failure, the head-end will send a request with a high priority > to a PCE that support request prioritization > > Some policing may be also used on the PCE in order to avoid any priority > abuse [DP] this would make sense in order to avoid any priority overload so it is also expected to be used in combination with policing on PCE's to ensure that the adertized capability can be met >>> M bit: Multiple Path Computation. When set, this flag indicates that the >>> PCE is capable of computing more than one path obeying a set of specified >>> constraints (in a single pass), provided that they exist. >> >> [DP] so it is a multi-path, multi-constraint computation ? > > It means that the LSR can compute a set of constrained path in a coordinated > manner. This bit does not indicate wether or not the PCE can compute paths > with multiple additive constaints (also an NP-Hard problem) like e.g. minimum > cost bounded delay paths. This may require an additional bit. [DP] ok thanks for the clarification; would it be possible then to indicate (or something equivalent at your discretion) "M bit: indicates that the LSR can compute a set of constrained path in a coordinated manner. Note: The M bit does not indicate whether or not the PCE can compute a set of paths with multiple additive constaints (also an NP-Hard problem) like e.g. minimum cost bounded delay paths. This requires an additional bit." >>> D bit: Diversity. When set, this flag indicates that the PCE is capable >>> of computing diversely routed paths (link, node, SRLG). The PCC may >>> request the PCE to compute N diversely routed paths obeying a set of >>> specified constraints. Such N paths may not exist of course depending on >>> the current state of the network. >> >> [DP] is that not a particular case of the previous bit ? > > Yes it is, if D is set M must also be set. [DP] ok, useful to indicate this specific case >>> If the PCE is capable of computing inter-AS TE LSP path, the PCE >>> Discovery Information TLV MAY also contain the list of AS numbers >>> identifying the AS for which the PCE can compute inter-AS TE LSP paths >>> (TE-LSPs having their destination address in this AS). This set is >>> optional and should be included only when the A bit is set. >> >> [DP] did you evaluate the potential length of such advertisement ? and the >> "loop" created with BGP information ? since the text says "MAY also contain >> the list of AS numbers identifying the AS for which the PCE can compute >> inter-AS TE LSP paths" so each time new AS's will be known this list will >> potentially be updated, drawing some lines along this point will help here; > > In practice an inter-AS TE "domain", will contained a limited number of > ASes. Also, in case a PCE can compute an inter-AS Path for any destination > AS, then destination ASes are not included. > > Further more the objective of this information is to allow balcaning path > computation load among a set of PCEs in a given AS, based on destination > ASes. For instance, an AS could contain 5 PCEs, each one being responsible > for the computation of inter-AS LSPs to 20 destination ASes. This would allow > supporting an inter-AS TE "domain" comprising 100 ASes, with only 20 ASes > listed per PCE. > > We will add some text on this point [DP] ok, this text will be useful - also, when you mention "inter-AS TE domain" do you mean a multi-AS single carrier environment ? or do you refer to something else ? >> another aspect is to distinguish between multi-AS single carrier and >> multi-AS multi-carrier, and restrict the latter to stringent policy rules >> in terms of AS path considered for LSP > > Yes, but again the goal of this information is more a way to allow an LSR > selecting the appropriate PCE among a set of candidate PCE, when the > computation load is balanced based on the destination AS. Policy rules for > AS-path selection are beyond the scope of this ID, and should be addressed in > separate drafts [DP] i understand that policy for AS path selection is beyond the scope of this document but the relevance of including this information as part of the IGP flooded information should be also clarified at some point in time >> => 5.3. Procedure >> >>> The PCE Discovery Information TLV is carried in Link State >>> Advertisements. A router MUST originate a new Link State Advertisement >>> whenever the content of this information changes, or whenever required by >>> regular routing procedure (e.g. refresh) >>> >>> The PCE Discovery Information TLV is optional. >>> >>> If the PCE can compute an intra-area TE LSP path, the L bit MUST be >>> set.If it can compute an intra-area TE LSP path only for the LSRs in the >>> area it resides in, then the PCE Discovery Information must be contained >>> within an area. Otherwise, if the PCE can compute intra-area TE LSP >>> paths for the whole AS, then the PCE Discovery Information TLV must be >>> flooded across the whole AS. >> >> [DP] how do you ensure that LSR's not being part of this area can reach the >> PCE (i.e. is there not a reachability constraint to be added here ? in >> particular in case of non-co-located PCE identified by an IP address) - i >> guess this point should be somehow clarified > > A PCE, supporting this draft, either LSR or centralized, will run the IGP. > Thus it will be reacheable. We will clarify this point. [DP] but then you have to ensure that no IP data traffic could reach the centralized PCE (since by definition it will be only capable to process IP control messages request/response, etc.) ie one has to exluce IP data traffic from the corresponding IP control channels >>> If the PCE can compute an inter-area TE LSP path, the I bit MUST be set. >>> If it can compute an inter-area TE LSP path only for the LSRs in the >>> area(s) it resides in (for instance the PCE is an ABR computing an >>> inter-area TE LSP path for its area), then the PCE Discovery Information >>> must be contained within this or these area(s). Else, if it can compute >>> an inter-area TE LSP path for the whole AS, then the PCE Discovery >>> Information must be flooded across the whole AS. If the PCE can compute >>> an inter-AS TE LSP path, the A bit MUST be set, and the PCE Discovery >>> Information must be flooded across the whole AS. >> >> [DP] probably it would be then be preferable to refer an "external AS" path >> since the PCE is able to perform three expansions: intra-area, inter-area >> (single AS) and inter-AS (where AS in the latter refers to "external AS" >> from the one of the path computation requestor)- see also above comment >> concerning expansion vs session > > See above answser [DP] ok >> [...] => 6.2. Required Information >> >>> The TE Mesh Group Information TLV allows an LSR to advertise the set of >>> TE mesh-groups it belongs to. For each mesh group announced by the LSR, >>> the TE Mesh Group Information TLV carries the following set of >>> information: >> >>> -A Mesh-Group number identifying the TE mesh-group, -A Tail-end address >>> (address used as a tail end address by other LSRs belonging to the same >>> mesh-group), >> >> [DP] is this not part of the advertising router information, or you are >> looking for an additional auxiliary information here to be used a Tunnel >> end point address ? > > This is basically a 32 bit id used to identify a mesh-group > >> my concern is that there should be a statement then saying the Mesh group >> ID must 1) be taken from a flat 32 bit id space 2) non routable information >> 3) unicity on a per AS basis and 4) there is no containment relationship >> wrt to the tail-end address space > > Agree, will add such statement [DP] ok >>> -A Tail-end name: string used to ease the TE-LSP naming (e.g. >>> 'head-name->tail-name'). >> >> [DP] is this to be used as part of the Session name field of the SESSION >> ATTRIBUTE object or the Extended Tunnel ID ? > > Yes [DP] thanks for the clarification >> => 6.3. Procedure >> >> [DP] here i am concerned with an operational aspect what happens when this >> information is not refreshed do the LSP have to be torn down, stay >> unaffected ? > > They have to be torn down [DP] ok that it is expected to (potentially) trigger a subsequent signaling operation >> since as stated above "The TE Mesh-Group Information allows an LSR to >> advertise its desire to join/leave one or more TE mesh-groups." >> >> [DP] also a rule could be defined something like "A given TE Mesh Group ID >> information is to be considered by a node X for setting up n LSPs from this >> node X to a set of destination LSRs n if this TE mesh group ID value has >> been advertised by that node X and received from a set of n nodes (n =< N) >> being part of that set" in order to clarify these procedures > > This is already implicitely mentionned in section 6.1 But actually such rules > are related to TE mesh group processing and not to IGP processing, and are > thus beyond the scope of this draft. Maybe we need to detail a little bit > more these TE-mesh group procedures, in the description section, in order to > allow for better understanding of the uses of this info. [DP] i agree it falls at the boundary on the other hand as there are no specific document for TE mesh groups this > Again thanks a lot for these highly relevant comments, thanks, - dimitri. > JL Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 25 Jul 2004 17:11:25 +0000 Message-ID: <0e0701c47268$830fc2f0$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Agenda and slides on-line Date: Sun, 25 Jul 2004 17:57:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, The agenda may be viewed on-line at http://www.olddog.co.uk/ccamp-60.htm It contains links to the drafts that will be discussed. I will up-load the slides and link to them as I receive them. (It is fixed for the mis-representation of the e2e signaling draft shown on the submitted agenda) For those of you who want/need it, there is a suggested template for slides at http://www.olddog.co.uk/ccamp-template.ppt Please note that: - We MUST have your slides well in advance. I would prefer to have them by Sunday evening. - You SHOULD limit your slides recalling that - a slide takes about 2 minutes - you want time for discussion Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 25 Jul 2004 17:11:18 +0000 Message-ID: <0dff01c47266$4f08bd60$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <agenda@ietf.org> Cc: <ccamp@ops.ietf.org> Subject: CCAMP Agenda for San Diego Date: Sun, 25 Jul 2004 17:36:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Please find attached the agenda for the CCAMP WG meeting in San Diego. Thanks, Adrian === CCAMP 60 - San Diego - Draft Agenda [running total 150 / 150] Group Admin Chairs Admin and agenda bash (5 mins) Status of WG (10 mins) - drafts not in this meeting (Adrian) - milestones and objectives (Kireeti) ASON Requirements and Solutions ASON Signaling and Routing Requirements and other cooked drafts (Adrian) (2 mins) http://www.olddog.co.uk/draft-ietf-ccamp-gmpls-ason-reqts-07.txt http://www.olddog.co.uk/draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt http://www.ietf.org/internet-drafts/draft-ietf-gmpls-egress-control-02.txt ASON Signaling Solutions (Dimitri Papadimitriou) (5 mins) http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt ASON Routing Solutions Design Team status (Dimitri Papadimitriou) (10 mins) http://www.olddog.co.uk/draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt A Transport Network View of LMP (Don Fedyk) (5 minutes) http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-transport-lmp-02.txt SG15 liaison (Wesam Alanqar 5 mins) Protection and Restoration Drafts in AD review (Adrian) (2 mins) http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-03.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-04.txt End-to-end recovery (Dimitri Papadimitriou) (5 mins) http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt Hello Protocol and Graceful Restart Graceful restart (Lou Berger) (10 minutes) http://www.ietf.org/internet-drafts/draft-aruns-ccamp-rsvp-restart-ext-01.txt Node-id-based Hello (Zafar Ali) (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt - implementation status - ready for last call Inter-Area/AS Strategy (Kireeti) (10 minutes) Inter-domain Framework (Adrian) (15 minutes) http://www.ietf.org/internet-drafts/draft-farrel-ccamp-inter-domain-framework-01.txt Inter-domain RSVP-TE (Arthi Ayyangar) (15 minutes) http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt Inter-domain TE LSP path computation methods (JP Vasseur) (15 minutes) http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-inter-domain-path-comp-00.txt GMPLS Inter-AS requirements (Tomohiro Otani) (10 minutes) http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-00.txt Summary of other work Layer 2 GMPLS (Dimitri Papadimitriou) (5 mins) http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt Layer 1 VPNs (Tomonori Takeda) (5 mins) http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-01.txt http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-00.txt http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt Segment Recovery (Lou Berger) (5 mins) http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-00.txt Graceful restart (Zafar Ali / Anca Zamfir) (5 minutes) http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-00.txt Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 25 Jul 2004 14:22:39 +0000 Message-ID: <0dee01c47252$9677b9d0$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <dimitri.papadimitriou@alcatel.be> Cc: <ccamp@ops.ietf.org>, <dpapadimitriou@psg.com> Subject: Waveband Switching [Was Re: draft-douville-ccamp-gmpls-waveband-extensions-05.txt] Date: Sun, 25 Jul 2004 15:14:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Dimitri, I'm not sure what you are asking. I think you are asking "Does anyone out there care about waveband switching?" We might refine this question for: a. now b. in the next two years c. sometime d. never. It is slightly interesting to look at the 9/22 respondents to the GMPLS implementation survey (November 2002). Of these, two are software vendors and one a test tool manufacturer. All are forced to implement, by definition. Of the others, one flagged "future", one was a CR-LDP product, and one a research implementation. So I could argue that this leaves us with just three. But it is probably more important to find out where we stand now. So, question to the list... Who believes that we need to complete the work on waveband switching in order to meet real implementation or deployment requirements? Thanks, Adrian > as mentioned in the additional ccamp webpage, this draft plugs a hole however > interest shown on this list is certainly low > > but so at the end of the day one may ask if this is the case > > 1) how implementations that have been reported in > <http://www.ietf.org/IESG/Implementations/MPLS-SIGNALING-Implementation.txt> > > 9 supports waveband labels so do we have to make the assumption that all of them > support only inverse multiplexing mechanism and/or wavelength concatenation ? > > 2) then what about Fiber SC ? > > this leaves the impression that the FSC value has been sometimes used when > switching the whole content of the container (ie the fiber) while following a > strict interpretation it is meant to only address spatial switching per GMPLS ARCH: > > "5. Fiber-Switch Capable (FSC) interfaces: > > Interfaces that switch data based on a position of the data in the > (real world) physical spaces. An example of such an interface is > that of a PXC or OXC that can operate at the level of a single or > multiple fibers." > > thanks, > - dimitri. > > -------- Original Message -------- > Subject: I-D ACTION:draft-douville-ccamp-gmpls-waveband-extensions-05.txt > Date: Thu, 22 Jul 2004 15:33:35 -0400 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Extensions to Generalized Multi-Protocol Label Switching > in support of Waveband Switching > Author(s) : R. Douville, et al. > Filename : draft-douville-ccamp-gmpls-waveband-extensions-05.txt > Pages : 11 > Date : 2004-7-22 > > Generalized Multi-Protocol Label Switching (GMPLS) extends the MPLS > control plane to encompass layer 2, time-division, wavelength and > spatial switching. Along with the current development on IP over > optical switching, considerable advances in optical transport > systems based on the multiple optical switching granularities have > been developed. > > Currently, GMPLS considers two layers of optical granularity using > wavelengths and fibers. By introducing an extended definition of > waveband switching, this document specifies the corresponding GMPLS > extensions, to further integrate optical multi-granularity and > benefit from the features of the corresponding switching layers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-05.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-douville-ccamp-gmpls-waveband-extensions-05.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-douville-ccamp-gmpls-waveband-extensions-05.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. > > > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 25 Jul 2004 11:30:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : draft-vasseur-ccamp-te-router-info-00 Date: Sun, 25 Jul 2004 13:29:17 +0200 Message-ID: <D109C8C97C15294495117745780657AE68E4A0@ftrdmel1.rd.francetelecom.fr> Thread-Topic: draft-vasseur-ccamp-te-router-info-00 Thread-Index: AcRwG7vGEslOrEsHR+6hMo9qDgwyFgCBzU/A From: "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@francetelecom.com> To: <Dimitri.Papadimitriou@alcatel.be>, "Adrian Farrel" <adrian@olddog.co.uk> Cc: <ccamp@ops.ietf.org>, "Jean Philippe Vasseur" <jvasseur@cisco.com> Hi Dimitri and all, Thanks a lot for these really useful comments Please see inline >-----Message d'origine----- >De : Dimitri.Papadimitriou@alcatel.be=20 >[mailto:Dimitri.Papadimitriou@alcatel.be]=20 >Envoy=E9 : jeudi 22 juillet 2004 20:43 >=C0 : Adrian Farrel >Cc : ccamp@ops.ietf.org; 'Jean Philippe Vasseur'; LE ROUX=20 >Jean-Louis RD-CORE-LAN >Objet : Re: draft-vasseur-ccamp-te-router-info-00 > > > >hi adrian, all, > >here below a bunch of comments on this documents: > >=3D> 3. Introduction >> - Data plane capabilities related to the node itself and not to its >links, >> such as the capability to be a branch node or a bud LSR of=20 >a P2MP LSP =20 >> tunnel (see [P2MP-REQ]). These node capabilities should be=20 >advertised=20 >> by the IGP for path selection. It would also be highly useful to=20 >> advertise control plane node Capabilities; for instance, the=20 >> capability to support GMPLS signaling for a packet LSR, or the=20 >> capability to support P2MP signaling. This would ease backward=20 >> compatibility. For instance this >would >> allow selecting a path that would avoid nodes that do not support a >given >> signaling feature, or automatically triggering a mechanism=20 >that would =20 >> handle these nodes on the path. > >[DP] suggest to translate the protocol specific also within=20 >the above text with something like > >- Nodal capabilities > > 1) control plane > > 2) data plane In 4.2 we define two distinct pieces of Information: Control Plane = Capability Flags and Data Plane Capability Flags, but agree that this separation should = appear more clearly in the intro.=20 Will update=20 > >=3D> 4.1. Description >> >> LSRs in a network may have distinct control plane and data plane=20 >> Traffic Engineering capabilities. The TE Node capability Descriptor=20 >> TLV >describes >> data and control plane capabilities of an LSR. Such =20 >information can=20 >> be used for instance for path computation algorithm so >as >> to avoid nodes that do not support a given TE feature either in the >control >> or data plane or to trigger procedure to handle these nodes. In some >case, >> this may also be useful for backward compatibility. > >[DP] suggest to detail the backward compatibility aspects ? i=20 >guess it is to provide support of legacy LSRs ? Definitely, the goal of this information is to ease operations in a = mixed environment made of capable and incapable nodes, wrt several control plane = capabilities. Knowledge of incapable nodes, allows capable nodes either triggering = mechanisms in order to support these nodes, or computing a path avoiding = these nodes For instance, If P2MP capable nodes are aware of non P2MP capable nodes, = then they can automatically trigger a mechanism allowing support for non = P2MP capable nodes (e.g. trigger a FA-LSP or LSP-segment to the next = P2MP capable node), or they may compute a Tree avoiding these nodes. > >=3D> 4.2. Required Information >> >> The TE Node Capability Descriptor TLV contains two variable length=20 >> sets >of >> bit flags: the Control Plane Capability flags and the Data Plane >Capability >> flags. Each flag corresponds to a given capability. >> >> Two flags are currently defined in the Data Plane Capability Flags: >> >> B bit: when set, this flag indicates that the LSR can act=20 >as a branch >node >> on a P2MP LSP (see [P2MP-REQ]) and [RSVP-P2MP]). >> >> E bit: when set, this flag indicates that the LSR can act as a bud=20 >> LSR >on a >> P2MP LSP, i.e. and LSR that is both transit and egress. > >[DP] if your point is that a branch LSR could not necessarily=20 >be an egress then for a branch being also an egress both E and=20 >B bits should be set ?=20 Yes, for a branch and egress capable node, both E and B bits should be = set. >the question is related to the=20 >atomicity of the bits, i understand the B bit (it means i can=20 >be a branch node in addition to a pre-defined set of=20 >tapabilities assumed by default, in my view this should be=20 >spelled out or pointed from the P2MP docs), in brief: B bit =3D=20 >branch node but doesn't say capability in terms of ending=20 >streams E bit =3D transit + egress > >so probably B bit should also say branch + egress and then E=20 >bit would only appear as particular case of the B bit - do you=20 >see any restriction here ? There may be cases where a node can act as a branch node but cannot act as an egress (ie cannot end the stream), and we should handle these = cases. Basically we have two distinct capabilities, so we need two bits. (see section 5.12 of the P2MP requirements ID). > >> Three flags are currently defined in the Control Plane Capability=20 >> Flags: >> >> M bit: when set, this flag indicates that the LSR supports MPLS-TE =20 >> signalling ([RSVP-TE]). >> >> G bit: when set this flag indicates that the LSR supports GMPLS >signalling >> ([RSVP-G]). >> >> P bit: when set, this flag indicates that the LSR supports=20 >P2MP MPLS-=20 >> TE signalling ([RSVP-P2MP]). > >[DP] is the P bit expected to be used only when the M bit is=20 >set ?=20 The P2MP requirement document points out, in backward compatibility = section:=20 "Unless administratively prohibited, P2P TE LSPs MUST be supported=20 through a P2MP network." =20 So when the P bit is set the M bit should be set, but there may be=20 particular cases where the operator wants to dedicate an LSR for P2MP,=20 and in that case P is set and M is not set. >also in that case P bit should refer also to GMPLS =3D> "P=20 >bit: when set, this flag indicates that the LSR supports P2MP=20 >G/MPLS-TE signalling ([RSVP-P2MP])" Shouldn't we handle cases where an LSR support [RSVP-P2MP] for MPLS-TE = but not for GMPLS (ie no support of 3473) ? > >> Note that new flags may be added if required. > >[DP] would be probably useful to indicate the criteria to be=20 >part of this TLV Criteria =3D Any control plane capability that can be identified by a = single bit. We will add a sentence in next revision > >=3D> 4.3. Procedure >> >> The TE Node Capability Descriptor TLV is carried in Link State =20 >> Advertisements. A router MUST originate a new Link State=20 >Advertisement =20 >> whenever the content of this information changes, or=20 >whenever required >by >> regular routing procedure (e.g. refresh). > >[DP] would you indicate that scaling should be preserved by=20 >this advertisement since 1) it is not expected that it's=20 >variation be much smaller than refresh time ans 2) usage of=20 >this information does not trigger generation (delayed via=20 >pacing or not) of a new advertisement) Agree, thanks, we will add some text on this point > >> TE Node Capability Descriptor TLVs are optional. When a Link State =20 >> Advertisement does not contain any TE Node capability Descriptor TLV, >this >> means that the TE Capabilities of that LSR are unknown. > >[DP] what would extinction reflect in this context ? it would=20 >be interesting to detail the expected behaviour of extinction=20 >(i.e. LSR lost its >capability) > Once an LSR loose a given capability, an updated Link State = Advertisement must be immediately flooded. The way how to handle such = extinction (e.g. LSP rerouting...) is beyond the scope of this draft. >=3D> 5.1. Description >> >> The PCE Discovery Information allows for the auto-discovery=20 >of one or >more >> Path Computation Element(s). In various MPLS and GMPLS situations,=20 >> such as inter-domain TE or backup path computation, an LSR >may >> require to send a request to a Path Computation Element (PCE) to=20 >> compute one or more TE LSPs paths obeying a set of specified=20 >> constraints. Note >that >> a PCE can be an LSR or an offline tool without any forwarding >capability. > >[DP] instead of mentioning "LSR or an offline tool" it would=20 >be better to refer to co-located or a non-co-located tool=20 >because the accessibility is independent on the location - the=20 >point is to avoid mentioning the TE tool access mode and make=20 >it independent from its localisation and distribution Agree that the term "offline tool" is not appropriate here. What about "A PCE can be a centralized tool, not forwarding packets, or = an LSR" > >=3D> 5.2. Required Information >> [...] >> >> L bit: Local scope. When set, this flag indicates that the PCE can >compute >> paths for the area/level the PCE Discovery Information TLV is flooded >into >> (the PCE can compute TE LSP paths for intra-area TE LSPs). >> >> I bit: Inter-area scope. When set, the PCE can perform TE LSP path=20 >> computation for inter-area TE LSPs but within the same AS. >> >> A bit: Inter-AS scope. When set, the PCE can perform path=20 >computation=20 >> for inter-AS TE LSPs. >> >> Note that those flags are not exclusive (a PCE may set one or more >flags). > >[DP] so imagine an inter-AS LSP for which an expansion=20 >(intra-area) has to be performed normal the L bit should be=20 >used however, it doesn't seem to be possible since restricted=20 >to intra-area LSPs so the above classification is imho=20 >performed in terms of "LSP scope" while it should also be=20 >provided in terms of computational scope no matter the type of=20 >LSP - so i would suggest to rework the text here above and=20 >decouple computation capability (scope) from the LSP scope in=20 >its description > >the issue is that we have "expansions" and "destination" (session >end-point) > >- expansion of the ERO can be in the present context:=20 >intra-area or multi-area > which is coupled to the PCE capability >- destination can be in the same area (intra-area LSP), in a=20 >different area > i.e. same AS (multi-area LSP) and in a different AS (multi-AS LSP) > >i think this point of discussion should be processed around=20 >these lines (note that there are cases in the matrix that can=20 >be built from the above that are unapplicable or simply irrelevant) Actually these bits refer to the capability of a PCE to process a = request for an intra/inter area/AS LSP, ie to participate in the = computation of an intra/inter area/AS LSP, whatever the scope of its own = computation capability (ie it can compute it alone, or needs = collaboration with other PCEs (ex an ABR)) Basically when a PCED capability TLV with the I bit set is flooded = within an area, this means that this PCE can handle an inter-area path = computation request, and that all LSR in the area can send an inter-area = Path computation request to this PCE. LSRs don't need to known if this PCE can compute the path alone (e.g it = has knwoledge of the topology of all areas) or if collaboration with = other PCEs is required (e.g. an ABR). But I Agree that the current definitions do not well reflect that, and = have to be updated. E.g. for the I bit: "I bit: Inter-area support. When set, this flag indicates that the PCE = can handle requests for computation of inter-area paths within the same AS (It can = contribute partially or entirely in the computation of an inter-area = path)" > >> P bit: Request Priority. The notion of request priority=20 >allows a PCC=20 >> to specify the degree of urgency of a particular request. When set,=20 >> this flag indicates that the PCE takes into account the 'request=20 >> priority' in its scheduling of the various requests. > >[DP] would you clarify here - because if all routers receive=20 >this information all of them can potentially make use of this=20 >information so it is not helping in solving the request=20 >scheduling in sequencing of the request one may face with a PCE Some request are more urgent than others, for instance backup path = computation requests. Some PCE may be able to prioritize requests and = others no. This flag allows an LSR selecting a PCE that can take into account = request priority among a set of candidate PCEs Basically a Request priority policy can be configured on each LSR, for = instance: Backup Computation: High priority Intra-area computation: Medium priority Inter-area computation: Low priority In case of LSP failure, the head-end will send a request with a high = priority to a PCE that support request prioritization Some policing may be also used on the PCE in order to avoid any priority = abuse > >> M bit: Multiple Path Computation. When set, this flag=20 >indicates that=20 >> the PCE is capable of computing more than one path obeying a set of >specified >> constraints (in a single pass), provided that they exist. > >[DP] so it is a multi-path, multi-constraint computation ? It means that the LSR can compute a set of constrained path in a = coordinated manner. This bit does not indicate wether or not the PCE can compute paths with = multiple additive constaints (also an NP-Hard problem) like e.g. minimum = cost bounded delay paths. This may require an additional bit. > >> D bit: Diversity. When set, this flag indicates that the PCE is=20 >> capable >of >> computing diversely routed paths (link, node, SRLG). The PCC may=20 >> request the PCE to compute N diversely routed paths obeying=20 >a set of=20 >> specified constraints. Such N paths may not exist of course=20 >depending=20 >> on the >current >> state of the network. > >[DP] is that not a particular case of the previous bit ? Yes it is, if D is set M must also be set. > >> If the PCE is capable of computing inter-AS TE LSP path, the PCE >Discovery >> Information TLV MAY also contain the list of AS numbers identifying=20 >> the >AS >> for which the PCE can compute inter-AS TE LSP paths (TE-LSPs having >their >> destination address in this AS). This set is optional and=20 >should be =20 >> included only when the A bit is set. > >[DP] did you evaluate the potential length of such=20 >advertisement ? and the "loop" created with BGP information ?=20 >since the text says "MAY also contain the list of AS numbers=20 >identifying the AS for which the PCE can compute inter-AS TE=20 >LSP paths" so each time new AS's will be known this list will=20 >potentially be updated, drawing some lines along this point=20 >will help here;=20 In practice an inter-AS TE "domain", will contained a limited number of = ASes. Also, in case a PCE can compute an inter-AS Path for any=20 destination AS, then destination ASes are not included. Further more the objective of this information is to allow balcaning = path computation load among a set of PCEs in a given AS, based on = destination ASes.=20 For instance, an AS could contain 5 PCEs, each one being responsible for = the computation of inter-AS LSPs to 20 destination ASes. This would = allow supporting an inter-AS TE "domain" comprising 100 ASes, with only = 20 ASes listed per PCE. We will add some text on this point >another aspect is to distinguish between=20 >multi-AS single carrier and multi-AS multi-carrier, and=20 >restrict the latter to stringent policy rules in terms of AS=20 >path considered for LSP Yes, but again the goal of this information is more a way to allow an = LSR selecting the appropriate PCE among a set of candidate PCE, when the = computation load is balanced based on the destination AS. Policy rules for AS-path selection are beyond the scope of this ID, and = should be addressed in separate drafts > >=3D> 5.3. Procedure >> >> The PCE Discovery Information TLV is carried in Link State >Advertisements. >> A router MUST originate a new Link State Advertisement whenever the >content >> of this information changes, or whenever required by=20 >regular routing =20 >> procedure (e.g. refresh) >> >> The PCE Discovery Information TLV is optional. >> >> If the PCE can compute an intra-area TE LSP path, the L bit MUST be=20 >> set. >If >> it can compute an intra-area TE LSP path only for the LSRs in the=20 >> area >it >> resides in, then the PCE Discovery Information must be contained=20 >> within >an >> area. Otherwise, if the PCE can compute intra-area TE LSP paths for=20 >> the whole AS, then the PCE Discovery Information TLV must=20 >be flooded=20 >> across >the >> whole AS. > >[DP] how do you ensure that LSR's not being part of this area=20 >can reach the PCE (i.e. is there not a reachability constraint=20 >to be added here ? in particular in case of non-co-located PCE=20 >identified by an IP address) - i guess this point should be=20 >somehow clarified A PCE, supporting this draft, either LSR or centralized, will run the = IGP. Thus it will be reacheable. We will clarify this point. > >> If the PCE can compute an inter-area TE LSP path, the I bit MUST be=20 >> set. >If >> it can compute an inter-area TE LSP path only for the LSRs in the >area(s) >> it resides in (for instance the PCE is an ABR computing an=20 >inter-area=20 >> TE LSP path for its area), then the PCE Discovery=20 >Information must be =20 >> contained within this or these area(s). Else, if it can compute an =20 >> inter-area TE LSP path for the whole AS, then the PCE Discovery >Information >> must be flooded across the whole AS. >> >> If the PCE can compute an inter-AS TE LSP path, the A bit MUST be=20 >> set, >and >> the PCE Discovery Information must be flooded across the whole AS. > >[DP] probably it would be then be preferable to refer an=20 >"external AS" path since the PCE is able to perform three=20 >expansions: intra-area, inter-area (single AS) and inter-AS=20 >(where AS in the latter refers to "external AS" from the one=20 >of the path computation requestor)- see also above comment=20 >concerning expansion vs session See above answser > >[...] >=3D> 6.2. Required Information >> >> The TE Mesh Group Information TLV allows an LSR to=20 >advertise the set=20 >> of >TE >> mesh-groups it belongs to. For each mesh group announced by=20 >the LSR,=20 >> the >TE >> Mesh Group Information TLV carries the following set of=20 >information:=20 >> -A Mesh-Group number identifying the TE mesh-group, -A Tail-end=20 >> address (address used as a tail end address by other LSRs belonging=20 >> to the same mesh-group), > >[DP] is this not part of the advertising router information,=20 >or you are looking for an additional auxiliary information=20 >here to be used a Tunnel end point address ? This is basically a 32 bit id used to identify a mesh-group > my concern is=20 >that there should be a statement then saying the Mesh group ID=20 >must 1) be taken from a flat 32 bit id space 2) non routable=20 >information 3) unicity on a per AS basis and 4) there is no=20 >containment relationship wrt to the tail-end address space > Agree, will add such statement >> -A Tail-end name: string used to ease the TE-LSP naming (e.g. =20 >> 'head-name->tail-name'). > >[DP] is this to be used as part of the Session name field of=20 >the SESSION ATTRIBUTE object or the Extended Tunnel ID ? Yes > >=3D> 6.3. Procedure > >[DP] here i am concerned with an operational aspect what=20 >happens when this information is not refreshed do the LSP have=20 >to be torn down, stay unaffected ?=20 They have to be torn down >since as stated above "The=20 >TE Mesh-Group Information allows an LSR to advertise its=20 >desire to join/leave one or more TE mesh-groups." > >[DP] also a rule could be defined something like "A given TE=20 >Mesh Group ID information is to be considered by a node X for=20 >setting up n LSPs from this node X to a set of destination=20 >LSRs n if this TE mesh group ID value has been advertised by=20 >that node X and received from a set of n nodes (n =3D< N) being=20 >part of that set" in order to clarify these procedures This is already implicitely mentionned in section 6.1 But actually such rules are related to TE mesh group processing and not = to IGP processing, and are thus beyond the scope of this draft. Maybe we = need to detail a little bit more these TE-mesh group procedures, in the = description section, in order to allow for better understanding of the = uses of this info. Again thanks a lot for these highly relevant comments, JL Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 24 Jul 2004 23:15:41 +0000 Message-ID: <0d3701c471d3$e2bc0eb0$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Greg Bernstein" <gregb@grotto-networking.com>, "Vishal Sharma \(E-mail 2\)" <v.sharma@ieee.org>, "Eric Mannie" <eric_mannie@hotmail.com> Cc: <ccamp@ops.ietf.org>, <zinin@psg.com> Subject: Post-AD markups review of draft-ietf-ccamp-sdhsonet-control-03.txt Date: Sun, 25 Jul 2004 00:13:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Thanks for making the changes to this draft as requested by the AD. I think this is a really useful draft that goes a long way to explain how the simple concepts of GMPLS in WDM are extended to GMPLS in TDM. Thanks for persevering with it. I have re-reviewed the draft to: - check that the changes made will address the AD's points - ensure that the draft is ready to progress to the IESG. Herewith a few comments. Can you please give me a schedule for making these minor changes (recalling that submission of drafts is embargoed until 9th August). I would really like to move this draft on now, so if you are short of bandwidth to make the changes, please say and I will get them done some other way. Cheers, Adrian = = = = = = = = = = = = AD comments ========== Technical Figure 1 - OK Section 3.4.3 - (Now 2.4.3) Slight improvement by use of parenthesis Section 3.5 New simplified encapsulation - (Now 2.5) Text struck. OK Section 3.5 Encapsulation of IP over WDM - (Now 2.5) OK Section 6 - (Now 5) Some new text added to help the issue, but no specific resolution of the question. Probably OK. Section 6.1 - (Now 5.1) The text has been expanded to explain why the text is present for data transport, but fails to address the two issues raised. a. In what way is this relevant to the control plane framework? b. How is the statement true when vcat is provided by services terminated on separate line cards? Section 6.3 - (Now 5.3) This section is still a problem. The issue has been resolved through a reference to two external sources neither of which is freely available. Since the authors are stating an opinion that the current GMPLS routing architecture/solution is deficient, it is important that this be clearly explained. Section 7.3 - (Now 6.3) Good new text added. Unfortunately a couple of editorial SNAFUs with cut and paste, and the references are still mixed up. Editorial: Section 3 - (Now 2) Improved, but still largely focused on MPLS not GMPLS (See my nits, below) Section 3.1 - (Now 2.1) OK Section 3.2 G.707 - (Now 2.2) OK Section 3.2 SDH->STS - (Now 2.2) OK Section 4.1 - (Now 3.1) OK Section 6 - (Now 5) OK Section 6.1 STS-3c - (Now 5.1) OK Section 6.1 "recently approved) - (Now 5.1) OK Section 6.1 STS-1-2v - (Now 5.1) OK Section 6.1 modify overhead bits - (Now 5.1) OK Section 6.1 multiplexing - (Now 5.1) OK Section 6.2 - (Now 5.2) OK Section 7 MPLS-HIER - (Now 6) OK Section 7 mixed SDH/SONET - (Now 6) Looks good to me Further Changes Needed ============== In summary of the above, further work is needed to address the following technical issues - Section 6.1 second issue - Section 6.3 - Section 7.3 and the editorial issue in - Section 3 Nits === Further nits from my review. Abstract. The suite of protocols that defines Multi-Protocol Label Switching (MPLS) is in the process of enhancement to generalize its applicability to the control of non-packet based switching, that is, optical switching. etc. Can you please re-cast this as a done deal and talk about GMPLS. I know this simply shows how old the draft is, but we need to look at the current position and that the RFC will (hopefully) be read for a few years to come. Index Please indent. Section 1 I am not sure what the purpose of this RFC2119 text is. I can't find any examples of uppercase terms used in the draft and this notation is normally used in requirements drafts or protocol specs. Section 2. As per abstract, the use of "is currently working on" does not future-proof the text as part of an RFC. Section 2.1 There is no need to talk about the advantages of the MPLS architecture and refer to [3]. We now have GMPLS and the GMPLS architecture document. In this context, this section is not very relevant to the discussion. Figure 1 It would be helpful to preserve this on one page. Add some blank lines (and maybe a note to the RFC Ed.) Table 1 Formatting Section 5.3 This is a WG document so MUST NOT contain phrases such as "the authors are of the opinion". It is either WG opinion (about which I'm not sure) or it should not be in the draft. Section 6 It is now appropriate to remove references to CR-LDP. Section 6.1 Reference to section 4 should be to section 3, I think. Please check all cross-references as you have renumbered the sections. Section 8 The wording here is a bit strange. Does it raise new security issues somewhere else? I think some more standardised text along the lines of "As an informational framework document, this document introduces no new security issues." However, as a framework document, I would expect to see an examination of the security issues that form part of GMPLS control of SDH/SONET. Are those issues identical to the security issues for GMPLS, are there additional issues specific to SDH/SONET, and are there GMPLS security issues that do not apply in this case? It is incumbent on us to expose security issues in this sort of document. Reference [9] Is this reference really normative? I believe it may give the RFC Ed a problem if it is, but the problem is not insurmountable. Reference to T1.105 Is this document publicly available? If it is available for cost-free down load, can you please give a *stable* URL (probably just the ANSI home page). If it is not publicly available, please move it to the informational references section. References to G.707 and G.841. Please move these to the informational references section and prefix with some text such as... For information on the availability of the following documents, please see http://www.itu.int. Please catch the reference to G.7715.1 in this, too. Section 13 Formatting Unprintable characters. Can you check for these and remove them. E.g. section 2.4 para 2. Also in the references section. References to "this draft" Please replace with (e.g.) "this document". E.g. sections 8 and 9. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 24 Jul 2004 21:03:32 +0000 Reply-To: <v.sharma@ieee.org> From: "Vishal Sharma" <v.sharma@ieee.org> To: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, "Kireeti Kompella" <kireeti@juniper.net> Cc: "Alex Zinin" <azinin@psg.com>, "Bill Fenner" <fenner@research.att.com> Subject: RE: Specific suggestions to improve San Diego agenda [Was RE: San Diego Agenda issues] Date: Sat, 24 Jul 2004 14:02:35 -0700 Message-ID: <MMECLKMDFPCEJFECIBCMCEOJEKAA.v.sharma@ieee.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian, Thanks for your detailed response. I recognize and appreciate the time you spent replying to it. At this time, I will reply to just one point, that I think is important to address. I will address the others (as appropriate) later, noting for now that we have identified at least 10 minutes on the current agenda that, if nothing else, can be devoted simply to a better discussion of remaining items on it. The drafts taking up that time could be held in abeyance, and discussed, if there is time remaining at the end to do so. Now to my point ... > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Saturday, July 24, 2004 12:21 PM > To: v.sharma@ieee.org; ccamp@ops.ietf.org; Kireeti Kompella > Cc: Alex Zinin; Bill Fenner > Subject: Re: Specific suggestions to improve San Diego agenda [Was RE: > San Diego Agenda issues] > > > Hi, > > > I am very disappointed to see your responses to my two previous > > emails, and take serious issue with the rather dismissive tone > > of your responses. > > I'm sorry that you interpret the tone of my response as rather dismissive. > > I understand that you are disappointed both that your survey > draft has not been allocated > a slot on the agenda and that I have not leapt to embrace your > suggested agenda > modifications. Just to be absolutely clear, I am _not disappointed_ on either of the two counts above that you continually seem to attribute my email about the agenda and the subsequent disappointment to. [First, my emails did not say anything at all about the carrier survey draft; they were (and are) purely a discussion of the overly full agenda, and how to free it up. Second, it is not "my" survey draft. -- Over a dozen people have contributed to it, all aware that they were giving their time and inputs with the purpose of eventually having the survey results published as a draft for discussion within the IETF/CCAMP, and all, the carriers especially, supporting such a discussion. -- One carrier representative (who is not a respondent) has already sent several comments on it to the list, supporting the document and supporting its disucssion at San Diego, and at least two other people have commended the draft on the list, and several others off list. Third, I had made it quite clear in my very first email that my suggested modifications were designed to facilitate discussion (which we are now having); there was no implication that they be accepted without discussion.] I was disappointed because as professionals engaged in a rational discourse, and as a Chair, I expected a better response from you (not necessarily a detailed one, but certainly a better one). Indeed, there are time constraints we all work under (Chairs and members alike), and, as you've observed, it takes non-trivial time, effort, and dedication to put serious comments/feedback together, and this is something we all should recognize when responding to such input. -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 24 Jul 2004 19:24:33 +0000 Message-ID: <0cdc01c471b3$82934230$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <v.sharma@ieee.org>, <ccamp@ops.ietf.org>, "Kireeti Kompella" <kireeti@juniper.net> Cc: "Alex Zinin" <azinin@psg.com>, "Bill Fenner" <fenner@research.att.com> Subject: Re: Specific suggestions to improve San Diego agenda [Was RE: San Diego Agenda issues] Date: Sat, 24 Jul 2004 20:20:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, > I am very disappointed to see your responses to my two previous > emails, and take serious issue with the rather dismissive tone > of your responses. I'm sorry that you interpret the tone of my response as rather dismissive. I understand that you are disappointed both that your survey draft has not been allocated a slot on the agenda and that I have not leapt to embrace your suggested agenda modifications. > It would be nice to put aside rhetoric and clever remarks to > focus constructively on the feedback at hand. > > The reality is that the feedback I provided is a very > serious attempt to advance the WG's goals and milestones. Then I will go through your mail and respond to each point in detail, below. > Not having an overcrowded agenda is one of the keys to > advancing WG work. Agree. > And, as an active and responsible contributing member of this WG and > the IETF, I believe it is incumbent to help structure what appears > to be a needlessly overcrowded CCAMP agenda. > > I would have provided this feedback regardless of whether or > not the you asked for it. I don't think the Chairs have to > ask for feedback from WG members, for us to provide it. > > (Note: > I have certainly done my share in contributing to progressing > several recent WG items, including TE requirements, inter-region TE, > P&R, ASON aspects, node ID and hellos, and the like -- one need only > go to the ML archives and minutes for that -- > so it is not as if my input is without basis or without the interests > of the CCAMP WG in mind. > > Of course, it is neither possible nor practical for everyone to > provide inputs on every WG item; nor, in my view, is it beneficial > for someone to attempt to do that.) All input from all sources is valuable. There is no need for anyone to stop providing input just because they have already made comments in many fields. In particular, people implementing or deploying the technology will have sound opinions across most of the workspace and should be encouraged to comment and contribute. > To address your specific points: > > i) It is never possible to finish all discussions during a WG meeting, > (so, of necessisty, many long discussions are transferred to the ML, > many people are left standing at the mike, etc.) > I think we all understand that, and I do not see anything > particularly unsual in it at Seoul. Well, my memory of Seoul is that we rarely got beyond the first three in line and that there was no space for debate or discussion. This certinaly gels with the comments I received afterwards. I know from experience that for someone to be moved to go to the mic takes a fair amount of concern, and that it is hugely frustrating for the queue to be cut off. > But, if that is an issue, then freeing up 30-odd minutes of the > agenda would seem _even more_ important than I initially thought. It > would ensure that whatever is discussed, is, as far as possible, > done so fully. Indeed. If we could free up agenda time, that would make sense. The debate (below) is about whether we can free up the time. > ii) Towards that end, I provided _six_ specific suggestions (with > reasoning and justification, based on the criteria specified in > your email), on how the agenda can be made less crowded. > > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00761.html And I shall respond to each of the six below. > And, I did not see the WG advance any objections or give any > reasons why my suggestions are not sensible and reasonable. Silence is taken as consent in this matter? I hope you will reconsider this. The WG participants are surely all too busy with many other things to provide instant responses (or indeed any response) to a debate on the agenda. But I would be happy to be proved wrong. > I see that you have simply <snipped> them in your reply, I'm > afraid that is not good enough. Oh. Well, sorry. The snipping was because I was responding to a sub-set of your points. I simply did not have time to respond to all of the points that you raised at the time and thought that you would prefer to receive some response quickly, rather than none. I am now pursuing every point in your orriginal mail and hope this will satisfy you. > If the Chairs, as representatives of the WG body politic, draft the agenda, > and a member seriously provides inputs on it, the Chairs are obligated to > respond, as long as the inputs are not "frivolous", which I > certainly do not think anyone can point to as being the case here. Yes, indeed. And hopefully the chairs are also allowed to go to bed sometimes? And do other work? And review all of the drafts submitted in advance of the meeting? And review the relevant and related drafts from other WGs and BOFs? The aim must surely be to be a little reasonable here. Allow us all a little space to breathe and write considered and lengthy responses as time allows. > iii) The "sense of the room" is neither for my benefit nor > that of the Chairs. > It is for the benefit of the WG as a whole, to help advance its work. Wrong. If the chairs take the sense of the room it is for their benefit. It helps them guide the working group that carries out all of its meaningful business on the mailing list, but allows a quick and unscientific gauge for where the WG is with an issue. > In that context, if the WG is polled in a rushed way, I re-iterate > that I don't think that it benefits the WG to do so, and that time can > be saved. So, let me give you a concrete example. Is a draft ready for last call? When we want to know that we send mail to the list (not for a vote, but to get a consensus) and if consensus is judged (by the chairs) a last call is held. Authors continually (and I mean continually) ask the chairs for last call. Sometimes it is obvious that the draft is not ready, sometimes the chairs review the draft and find many issues, sometimes it looks like the draft is ready. But typically we don't simply send mail saying "is this draft ready for last call": what we do is get a feeling for whether the WG is in a position to make the judgement. For example, how many people have read the draft? who feels that this is an important area? who has implemented? do you feel confident that this is stable? We could ask these questions on the mailing list, but it is neither quick nor friendly. Most people on the CCAMP list are very busy and do not get to read and respond to emails in a timely manner. It is clearly far more helpful to use a WG gathering to gather this information and use that as a guide for how to continue. > Furthermore, I did not see any communications stating that a sense > of _all_ of these drafts will be taken, only some of them. > I suggested instead that it would be better for the Chairs to > highlight all these drafts on the list, and take a sense there. As above. But you make a very good point. It might be really helpful if the chairs were to provide a status (say monthly) to the WG on the progress of drafts and milestones. This would certainly focus the chairs' activities, might help to drive the editors, and would mean that a little less time was needed for this type of work at the meetings. I would be interested to hear from people whether this would be - useful - something they would commit to read. > (So, I am not sure what you are driving at by suggesting > dropping "my" draft from the list. In any case, there is none named > after me, and two on which I am only a co-contributor.) The context of the discussion was very clearly one draft for which you are listed as one of three authors. > iv) If there are milestone items that no one in the WG is commenting on, > despite the WG taking them on, then it is perhaps time to seriously re- > examine them, or encourage and urge those interested in those items to > contribute to them. I could not agree more. There are two items that cause me grave concern. These are the GMPLS MIBs and Tunnel Tracing. Both items have milestones which have passed their sell-by dates, yet the WG shows very little interest in advancing the work. The MIB authors (those who still remain working in the area) have made frequent requests for assitance and implementation experience, but none has been forthcoming. Yet we (as chairs) are told that these two items *are* important and fundamental to the success of GMPLS. The chairs have given their time to work on these drafts, but help is needed or the items must be dropped. > However, I don't see how putting them on the agenda > achieves the cause of advancing those milestones, except taking > up time. > People listen to the presentation, and nothing happens thereafter. Then we need another suggestion. Clearly in the desparation to get something to happen, the chairs wish to raise these items (no other action seems to have any effect, perhaps raising them at the meeting will work). Personally, I would welcome time on the agenda (perhaps 15 minutes for each item) to debate whether we should abandon them, or how we can achieve the milestones which we as a working group have committed to yet have failed to meet. However, I suspect that if I allocated time for such a debate, I would receive even more of a lashing. > v) Finally, the request to have the AD guidelines be published > on the ML, was simply to ensure that the WG learnt of them in > good time, to allow people to plan their work accordingly. Well, they are out in the open now. I guess they were mainly intended to focus the way that the chairs work, but I see no reason why the rest of the WG shouldn't be aware of them. = = = Now your original email with responses... > I have examined the agenda in the light of the above questions, and > have looked at the drafts currently on it. > > The following is meant to be a neutral assessment, based on closely > following the development of a good majority of the work on the agenda. > [Disclaimer: It _should not_ be interpreted as reducing the importance > of any of the work. > Rather, it is a serious attempt to take up the Chairs' request to > solve the agenda crunch (that we seem to be getting into more and more > of late), so that the WG as a whole benefits.] No such request was made. Nevertheless, your input is most valuable. > i) First, I do not believe a mention by the Chairs, in less than > 30-odd seconds each, of over 15 drafts buys the WG anything. This is discussed at some length above, but further comments are provided below for completeness. It is worth noting that many of the items in this list of 15 received a request for 5, 10 or 15 minute slots. The list, therefore serves two purposes: - it flags certain drafts about which the chairs have something very brief to say - it mentions certain drafts that would otherwise be entirely left off the agenda. This last point is helpful to and welcomed by some people. > By removing this, the WG saves a full 5 minutes right away. > > -- If the Chairs, in fact, want to draw attention to these documents, why > not post your comments/urgings/admonitions with the pointer to these drafts > directly to the ML? > That is the right place to make the majority of the WG aware of these > important documents anyway. Agreed. And you may have noticed that I have been working through the drafts, reviewing the new ones and sending comments to the list. Editors and authors have also been receiving private emails to help advance their work. But this is not an either/or. Bringing the items to the agenda still focuses the authors and provides a brief *coherent* summary for all WG participants and for those many who come to the meeting to find out what is going on, but who are not subscribed to the mail list. As mentioned above, a WG status email might help to alleviate this problem *in*the*future*. > -- Also, I noticed in some of your emails that you intended to "take a sense > of the room" for some of the drafts on this huge list. > > I think that _should not_ be done. > > It is very difficult, if not impossible, to get a sense of multiple drafts > in under 30 seconds each, and surely no fair sense can be got that way. As mentioned in a previous response and above, this is done by the chairs, for the chairs' benefit. It is not intended to be fair or easy. It is intended to help the chairs gauge the feeling of the WG in a very rough but most importantly speedy way. > It it much better for the sense to be taken on the ML (which is the best > place anyhow) where people have time to think and reflect, and then respond. No-one is suggesting that such a "sense of the room" replaces the mailing list as the correct place to take consensus. It is just a tool - one that the chairs find useful. ** Thus, I reject this 5 minute saving. > ii) Second, given that the ASON Routing Design team has just been > constituted, and has only just begun its work, it is difficult to see why > 10 minutes are being given to discuss this. > > Their composition and charter have already been posted to the list and > examined by all, so none of those bear repeating. > > It should suffice for the Chairs to spend 2 minutes or so (if that) > updating the WG on it. The DT is carrying out a very important piece of work. It is important on four fronts: - it is providing important function - it is working on routing protocols that might be easily destabilised with dire results - it requires input from multiple WGs - it is building bridges with two external bodies with which we have a very bad history. The DT has already started work and produced an outline draft. They need to report on their achievements and outline the biggest issues and challenges. They should be asking for any help that they need. It is possible that they will need more that the ten minutes as I expect some questions from members of the IGP WGs that are members of the CCAMP mailing list. ** Thus I reject this 8 (or possibly 10) minute saving. > So we are now at +18 minutes (possibly 20). 5 + 8 = 13 > iii) The end-to-end recovery document was already mature a while back, > and has been discussed at practically every IETF for the past several > IETF's. > > The issue of misconnections (for the purposes of this draft) has also been > adequately addressed to the satisfaction of the people who debated this > issue (which includes me). AFAIK, that was the only substantive addition > made. > > What other open issues are still left that cannot now be satisfactorily > resolved on the mailing list and that require 5 minutes of the agenda? I am glad to hear that the changes to this draft address your concerns. The slot is to allow the authors to say what they have done in response to the concerns, to check that those who were concerned are now happy, to check that everyone else is happy that the changes are not detrimental, and to see if there are any other issues. You may recall that the whole misconnection issue was only nailed and committed for inclusion in this draft as a result of comments made at a similar meeting. > It would seem that the last call can easily be done on the list (and is > probably best done there), There is no intention to do last call at the meeting. The intention is to discover whether the decks are now clear to ask for last call. Five minutes does not seem extravagant for this item. In fact I might expect Dimitri, experienced as he is to skim through this in only 3 minutes, but if there are issues or questions... ** Thus I reject this saving of five minutes, but might expect to save 2 minutes along the way. > bringing us to +23 minutes (possibly 25). 5 + 8 + 5 = 18 > iv) The segment recovery document was made a WG document after Seoul, > but I don't recall seeing any discussion on it since. There were at least 7 emails about this draft since Seoul. There was a debate about the use of the Association object that had some value. > Clearly, either the WG has not found time to focus its attention on this > work between Seoul and now, or sufficient discussion has not been > initiated on it by the authors. Or the draft is cooked? Or perhaps the authors have some additions that they want to propose? Which is it? How are the chairs to decide? > Either way, without any debate/discussion on the ML, this draft does not > satisfy multiple criteria listed above, and it seems fair that the authors > should attempt to generate discussion on the list, or summarize > things so it can move forward. This is a WG draft. It is our responsibility to drive WG drafts to completion and get them shunted off to the IESG. This makes room for new work in the future. Note that the authors are not responsible for WG drafts: they are guardians of the draft for the WG. The WG is responsible for getting them finished. I agree that this draft is the most marginal for a mention so far, and if a cut had to be made in favour of something else then this might be a candidate. It would be useful, but not essential to cover this draft. ** Thus, hold this five minutes in abeyance pending finding something more important. > We are now at +28 minutes (possibly 30). 5 + 5 + 8 + 5 = 23 > v) I am not sure I saw the graceful shutdown draft discussed (maybe its > a split off of some related work), but if it's new work with no discussion > yet, I would say we do not need 5 minutes for it. See Dimitri's mail for references to the discussion. The point here is that we are looking at a bunch of changes to the Hello mechanism (and other protocol techniques) related to graceful restart. This draft proposes other methods to take a link out of service and in a graceful way, and since the area is closely related (and some might argue should be solved in the same way) there is value in bringing the work together with the previous drafts. However, I agree that this draft is also a candidate to be shunted out by something more important. ** Thus, hold this five minutes in abeyance pending finding something more important. > vi) The comments for the L2 GMPLS draft say "what it's about?". > > It seems that any draft for which this question needs to be answered at a > WG meeting probably first needs to be discussed on the list, and > automatically does not meet multiple criteria from those you listed earlier. > > Maybe I missed it, but can anyone point out where on the ML this draft > was discussed? And, what the outcome of those discussions was? This draft has been around for ever! I want to clear up once and for all whether this is in scope or out of scope. Whether the WG believes it is plugging an important hole or simply following a completeness proof. Will anyone implement it? Would anyone deploy it? We need to close on this now and either get the draft on board, finished, implemented and shipped, or else axe it. I see a brief slot on the agenda as a very good way to force the issue. For me this slot is more important than many others on the agenda. ** Thus, I reject this five minute saving. > So it seems we can save a full 33 minutes (possibly 35, or 38 without > graceful shutdown) from the agenda with substantial consequent benefit > to the WG, by freeing up time for various other important activities > (debates, discussions of other drafts, issues, etc.) Correcting the math, this reads "28 minutes (possibly 30, or 35...)" I accept that of this sum, 10 minutes are available to make space for something more important. I am always glad to hear suggestions as to what that might be, but I do not want to get into a "his draft is less valuable than my draft" debate with anyone. > It would be good to hear if the WG believes that the above suggestions do > not benefit the WG and/or should not be implemented (and why). A well-phrased question, but since you are asking for / proposing change, it is conventional to ask the question the other way round. So... I would be interested to hear if anyone in the WG believes that Vishal's suggestions would benefit the WG. Which of the items listed should we abandon, and in favour of what? > Looking forward to seeing a revised agenda. I will not be providing a revised agenda until it is clear what we are proposing to put in place of things we cut, and until it is clear that that is a beneficial act. The deadline for agenda submission is Monday, but I will be travelling from Sunday so I will submit the agenda on Sunday evening UK time. Please note that the agenda will still be open for revision in the meeting. I would suggest that it is by far the best idea to get all agenda debates in the open *before* the meeting. If we spend any significant time within the meeting bashing the agenda, we will waste the meeting. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 22:55:32 +0000 Reply-To: <v.sharma@ieee.org> From: "Vishal Sharma" <v.sharma@ieee.org> To: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, "Kireeti Kompella" <kireeti@juniper.net> Cc: "Alex Zinin" <azinin@psg.com>, "Bill Fenner" <fenner@research.att.com> Subject: RE: Specific suggestions to improve San Diego agenda [Was RE: San Diego Agenda issues] Date: Fri, 23 Jul 2004 15:54:17 -0700 Message-ID: <MMECLKMDFPCEJFECIBCMGEOGEKAA.v.sharma@ieee.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian, I am very disappointed to see your responses to my two previous emails, and take serious issue with the rather dismissive tone of your responses. It would be nice to put aside rhetoric and clever remarks to focus constructively on the feedback at hand. The reality is that the feedback I provided is a very serious attempt to advance the WG's goals and milestones. Not having an overcrowded agenda is one of the keys to advancing WG work. And, as an active and responsible contributing member of this WG and the IETF, I believe it is incumbent to help structure what appears to be a needlessly overcrowded CCAMP agenda. I would have provided this feedback regardless of whether or not the you asked for it. I don't think the Chairs have to ask for feedback from WG members, for us to provide it. (Note: I have certainly done my share in contributing to progressing several recent WG items, including TE requirements, inter-region TE, P&R, ASON aspects, node ID and hellos, and the like -- one need only go to the ML archives and minutes for that -- so it is not as if my input is without basis or without the interests of the CCAMP WG in mind. Of course, it is neither possible nor practical for everyone to provide inputs on every WG item; nor, in my view, is it beneficial for someone to attempt to do that.) To address your specific points: i) It is never possible to finish all discussions during a WG meeting, (so, of necessisty, many long discussions are transferred to the ML, many people are left standing at the mike, etc.) I think we all understand that, and I do not see anything particularly unsual in it at Seoul. But, if that is an issue, then freeing up 30-odd minutes of the agenda would seem _even more_ important than I initially thought. It would ensure that whatever is discussed, is, as far as possible, done so fully. ii) Towards that end, I provided _six_ specific suggestions (with reasoning and justification, based on the criteria specified in your email), on how the agenda can be made less crowded. http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00761.html And, I did not see the WG advance any objections or give any reasons why my suggestions are not sensible and reasonable. I see that you have simply <snipped> them in your reply, I'm afraid that is not good enough. If the Chairs, as representatives of the WG body politic, draft the agenda, and a member seriously provides inputs on it, the Chairs are obligated to respond, as long as the inputs are not "frivolous", which I certainly do not think anyone can point to as being the case here. iii) The "sense of the room" is neither for my benefit nor that of the Chairs. It is for the benefit of the WG as a whole, to help advance its work. In that context, if the WG is polled in a rushed way, I re-iterate that I don't think that it benefits the WG to do so, and that time can be saved. Furthermore, I did not see any communications stating that a sense of _all_ of these drafts will be taken, only some of them. I suggested instead that it would be better for the Chairs to highlight all these drafts on the list, and take a sense there. (So, I am not sure what you are driving at by suggesting dropping "my" draft from the list. In any case, there is none named after me, and two on which I am only a co-contributor.) iv) If there are milestone items that no one in the WG is commenting on, despite the WG taking them on, then it is perhaps time to seriously re-examine them, or encourage and urge those interested in those items to contribute to them. However, I don't see how putting them on the agenda achieves the cause of advancing those milestones, except taking up time. People listen to the presentation, and nothing happens thereafter. v) Finally, the request to have the AD guidelines be published on the ML, was simply to ensure that the WG learnt of them in good time, to allow people to plan their work accordingly. Thanks, -Vishal > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Friday, July 23, 2004 5:40 AM > To: Vishal Sharma (E-mail 2); ccamp@ops.ietf.org; Kireeti Kompella > Cc: Alex Zinin; Bill Fenner > Subject: Re: Specific suggestions to improve San Diego agenda [Was RE: > San Diego Agenda issues] > > > > Continuing with my previous email.... per your request > > below, here are some specific suggestions on how the > > agenda for San Diego can be improved to remove the > > pressure on it, thus benefiting the WG as a whole. > > Hmmm. Makes note not to use irony or rhetoric in future emails. > > > I have examined the agenda in the light of the above questions, and > > have looked at the drafts currently on it. > > Before going any further, be ware that the default position will > be that we devote the > meeting entirely to satisfying our milestones. No other drafts > would be examined, and no > other work done. > > As Fred Baker recently said: > ...the charter of a working group is a contract-of-sorts to accomplish > something. ... I would like to see working groups held to their > chartered work plans, and rechartered if the work-plan changes. > > I take this very seriously, and would like to dilute it only in > support of existing WG > drafts that also need to be progressed. If you look at the agenda > you will see > that it spends most of the time of milestones that have a > reasonable chance of > advancement, but actually touches on all of the milestones. > > I have said before, and will say again and again until I am > heard, if you want meeting > time to be spent on your drafts you MUST give time and effort to > advance the WG > milestones. When we > have done our work, we have time to play. > > Who in the WG has reviewed the GMPLS MIBs? > Who has provided constructive suggestions for the development of GTTP. > > And failing that, perhaps the WG would like to open a debate > about changing the work-plan. > But I have heard no discussion of that so I assume that the WG is > happy with the current > milestones. > > > i) First, I do not believe a mention by the Chairs, in less than > > 30-odd seconds each, of over 15 drafts buys the WG anything. > > > > By removing this, the WG saves a full 5 minutes right away. > [SNIP] > > -- Also, I noticed in some of your emails that you intended to > "take a sense > > of the room" for some of the drafts on this huge list. > > > > I think that _should not_ be done. > > I do not suggest doing it for your benefit. I suggest doing it > for the benefit of the > chairs. > > I will, however, happily remove your draft from this list if that > is what you are asking > me to do. > > > It would be good to hear if the WG believes that the above > suggestions do > > not benefit the WG and/or should not be implemented (and why). > > > > Looking forward to seeing a revised agenda. > > Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 21:06:40 +0000 Message-ID: <0c5e01c470f8$a5cde130$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org>, <mpls@ietf.org>, "TEWG" <te-wg@ops.ietf.org>, <rtgwg@ietf.org> Cc: "'Jean Philippe Vasseur'" <jvasseur@cisco.com> Subject: Path Computation Element BOF Date: Fri, 23 Jul 2004 21:52:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Just a reminder that a PCE BOF will be held at San Diego in the Wednesday 9am slot. See below for a summary of the objectives. You might also like to look at a problem statement draft... http://www.ietf.org/internet-drafts/draft-ash-pce-problem-statement-00.txt Cheers, Adrian === Path Computation Element BOF (PCE BOF) 60th IETF, San Diego, August 2004 Routing Area Ads: Alex Zinin (zinin@psg.com), Bill Fenner (fenner@research.att.com) BOF Chairs: JP Vasseur (jvasseur@cisco.com), Adrian Farrel (adrian@olddog.co.uk) Description: In certain MPLS TE networks it may be beneficial or desirable to have path computation performed by a distinct node (termed the Path Computation Element PCE) that is not the LSR that needs to know the path. This BOF examines the scope of such function, what extensions to existing protocols might required, what additional protocols may need to be developed, and whether there is cuase and support for this work within the IETF. Proposed WG Charter Organizational Overview The PCE working group coordinates the work within the IETF of defining the operation of path computation elements within the Internet. Path computation elements are responsible for computing paths through IP networks for uses such as traffic engineering so that a prime consumer of such paths might be an MPLS-TE LSR. Areas of responsibility will include the collection of attributes relevant to the computation of paths, the discovery by LSRs of available path computation elements, the communication with LSRs for the request of path computation, the collaboration between path computation elements within the network, and analysis of path computation algorithms with a view to ensuring consistency between computed paths. The working group will work closely with many working groups in the Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups. Working Group Scope The PCE working group scope includes: - Definition of Generalized Traffic Engineered LSP paths computation techniques involving Path Computation Element(s). This includes the intra IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path computation for Point-to-Point, Point-to-Multipoint and Multipoint-to-Multipoint TE LSPs. - Definition of protocol-independent metrics and constraints defining path quality measurement criteria, algorithm complexity and scalability criteria related to path computation techniques. - Definition of requirements for communication between LSRs and PCEs including routing extensions in support of PCE discovery techniques within an IGP area and across multiple IGP areas, ASes and Provider networks, and including the development of new protocols or protocol extensions for requesting path computation and supplying responses. Any protocol extensions will developed in conjunction with the working groups in charge of the specific protocols. - Specification of routing (OSPF, ISIS, BGP) and signalling extensions (RSVP-TE) required by PCE-based path computation techniques. The extensions will developed in conjunction with the working groups in charge of the specific protocols. - Specification of requirements and protocol extensions related to the policy, security and confidentiality aspects of PCE-based path computation techniques involving PCEs of multiple Providers. - Definition of MIBs, management procedures related to the protocol extensions defined by the WG In doing this work, the WG will closely work with at least the following other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with the ITU-T and OIF. Goals and Milestones Dates for milestones to be decided later. - Post strawman WG goals and charter. - Submit WG document defining the framework and applicability of the PCE model. - Select a single candidate protocol from communication between LSRs and PCEs. - Submit document(s) that define various path computation models - Submit an analysis document examining the requirements for coherent computation techniques and the implication of cooperation between PCEs. - Submit a document defining the protocol for communication between LSRs and PCEs. - Submit document(s) defining extensions to routing and signalling protocols necessary to support the use of a PCE model within MPLS networks. - Submit a document defining MIB modules for modeling and management of PCE systems. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 16:53:55 +0000 Message-ID: <0bd101c470d5$9391b000$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Status of Egress Control draft Date: Fri, 23 Jul 2004 17:53:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Those of you wondering what has happened to draft-ietf-gmpls-egress-control-02.txt will want to know: - it passed WG last call - it was updated to address the trivial issues raised - it is now queued for review by our ADs. The ADs have worked their way through quite a pile of our drafts in the last couple of months and this one is now near the top of the list. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 16:51:10 +0000 Message-ID: <0bc901c470d5$30a04010$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: ASON Routing requirements Date: Fri, 23 Jul 2004 17:49:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, The authors have produced a new version of the draft to answer the issues that the AD raised in review after WG last call. The draft has been stuck with me for the last week and so missed the submission deadline. I have now reviewed it and believe it fixes all of the AD's issues. Since the changes are very small, I do not propose another WG last call, but suggest you all look at the draft to check that no new concerns have been introduced. You can see a copy of the draft at http://www.olddog.co.uk/draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 16:27:34 +0000 Message-ID: <0bae01c470d1$dda60fa0$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: ASON signaling requirements draft Date: Fri, 23 Jul 2004 17:26:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, The authors (well, Dimitri, mainly) have produced a new version of the draft to answer the issues that the AD raised in review after WG last call. The draft has been stuck with me for the last week and so missed the submission deadline. I have now reviewed it and believe it fixes all of the AD's issues (although a couple of editorial nits still remain). Since the changes are very small, I do not propose another WG last call, but suggest you all look at the draft to check that no new concerns have been introduced. You can see a copy of the draft at http://www.olddog.co.uk/draft-ietf-ccamp-gmpls-ason-reqts-07.txt Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 16:25:31 +0000 Message-ID: <41013BD9.6080000@psg.com> Date: Fri, 23 Jul 2004 18:24:57 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: John Drake <jdrake@calient.net> CC: dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org Subject: Re: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.tx t Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit john, there is no default or recommended behaviour described in section 4.3 of the bundling i-d, now, if one assumes that, by default, component recording (only) must be provided, there is no possibility to deliver the expected feature as the components selected on a link local basis would be unknown to the ingress, also, there is more complex problem that even if you assume for instance an bundled link and record two subobjects of the form <router_id, interface_id> one for the bundle and one for the component there is an ordering rule that should be define to link the associated label subobject if present; i hope it clarifies that 1) there is something to be addressed, 2) mechanism proposed is one possible way to address it 3) intend was to make the default behaviour of recording at the same level than ERO and trigger additional information using this flag (the equivalent of label recording btw) thanks, - dimitri. John Drake wrote: > Dimitri, > > This flag isn't needed. Once a node selects the component link, it is that > link that is in the RRO. > > Thanks, > > John > > >>-----Original Message----- >>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>Sent: Friday, July 23, 2004 5:47 AM >>To: ccamp@ops.ietf.org >>Subject: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt >> >>All, there is one issue that is flagged in Section 7.1 in this draft >> >><http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te- >>bundled-links-00.txt> >> >>as needing to poll from the working group to see whether to use Session_ >>Attributes or LSP_Attributes to flag component link recording and close >>accordingly >> >>" If a node desires component link recording, the "Component Link >> Recording desired" flag (value TBD) should be set in the >> LSP_ATTRIBUTES object, object that is defined in [RSVP-TE- >> ATTRIBUTE]. Another alternate is to use an available flag in the >> SESSION_ATTRIBUTE object [RFC3209]. The later makes the component >> link recording request similar to the label recording request." >> >>thanks for the feedback, >>- dimitri > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 16:01:49 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC017AE4E4@nimbus.chromisys.com> From: John Drake <jdrake@calient.net> To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org, Zafar Ali <zali@cisco.com>, Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel.be> Subject: RE: draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt Date: Fri, 23 Jul 2004 09:01:36 -0700 MIME-Version: 1.0 Content-Type: text/plain Dimitri, I would agree with you that there are some issues with 3471/3473. However, this I-D just adds more complexity. Thanks, John > -----Original Message----- > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > Sent: Friday, July 23, 2004 1:50 AM > To: John Drake > Cc: Adrian Farrel; ccamp@ops.ietf.org; Zafar Ali; Dimitri Papadimitriou; > aruns@movaz.com; 'Anca Zamfir' > Subject: Re: draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt > > john, see in-line > > John Drake wrote: > > >> 1. Does this draft add anything at all? Isn't everything you need to > know > >> about bundling already covered in 3471/3/7 and the BUNDLE draft? > >> > >> 2. Why is it necessary to define new unnumbered component link > identifiers? > >> > >> > >> If I recall, there was some acceptance that the draft was necessary to > >> define route recording of component link choice on the basis both that > it > >> might be useful and to provide symmetry with label recording [RFC3209]. > At > >> the same time (and for similar reasons) ERO specification/control of > >> component link might be desirable. I believe this takes care of the > first > >> issue. > > > > [John Drake] > > > > If one uses the type 3 (IF_IINDEX) TLV, as stipulated in the bundling > draft, > > then there is no issue to be solved. Per the bundling draft and RFC > 3477, a > > selected component link will be carried in the RRO and can then be > placed in > > the ERO of a subsequent Path message. So this I-D is not needed to > address > > that problem. > > the drafts mentions that "When link bundling is used to aggregate multiple > component links into a TE link bundle, the label is not the only resource > that > needs to be identified and recorded.In other words, the TE link bundle > identifier and the label value specified in the ERO/RRO objects are not > enough > to completely identify the resource." > > at least to make things clear it is meant to avoid situation where in the > RRO > you [TE link and label recording] you're remark is but the use [component > link > and label] it works if you make the assumption that you can retrieve the > association at the ingress (which is not commonly the case by definition > of > bundling) > > >> The second issue is more controversial. The view against the draft says > >> that it is possible to identify a component link using IF_ID TLVs of > type 4 > >> and 5 > > yes it is more controversial > > > [John Drake] > > > >> From the bundling draft: > > > > "If the component link is unnumbered, the IF_ID RSVP_HOP object, or > IF_ID TLV > > carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The value carried in > Type 3 > > TLV contains the identifier of the selected component link assigned to > the > > link by the sender of the Path/REQUEST message." > > signaling processing from RFC 3473 which are the corner stone of the > discussion > > "For bidirectional LSPs, the sender chooses the data interface in each > direction. In all cases but bundling, the upstream interface is implied by > the > downstream interface. For bundling, the path sender explicitly identifies > the > component interface used in each direction." > > as most non-packet LSPs are bi-directional and make commonly use of > bundling we > are in a situation where once bundling is used, the second sentence does > not > apply and all IF_ID's are making use these two type > > now the link bundling draft mentions (and points to 3473) > > " Signaling must identify both the component link to use and the label to > use. > The choice of the component link to use is always made by the sender of > the > Path/REQUEST message (if an LSP is bidirectional [GMPLS-SIG], the sender > chooses > a component link in each direction). For unidirectional LSPs, and the > forward > direction of bidirectional LSPs, the sender of a Resv/MAPPING message > chooses > the label. For the reverse direction of a bidirectional LSP, the sender of > the > Path/REQUEST message selects the upstream label. > > With RSVP the choice of the component link is indicated by the sender of > the > Path message by including the IF_ID RSVP_HOP object in the Path message, > as > described in section 8 of [GMPLS-RSVP]." > > > >> These TLVs contain an IP address and a component link ID. The claim of > >> (some of) the authors is that this is fine if the bundle is identified > by > >> an IP address (i.e. is numbered) - in this case the component link ID > is a > >> reference within the bundle. It is also OK if the bundle is unnumbered > and > >> the component link ID is unique across the node - in this case the IP > >> address identifies the node and the component link can be found and the > >> bundle deduced by a reverse lookup (we assume that a component link is > a > >> member of just one bundle). Note that it is not necessary for the > component > >> link ID to come from the same space as the unnumbered interface IDs (as > the > >> draft seems to say) because a different TLV type number is used. The > >> problem arises if the component link IDs are unique only within the > context > >> of a bundle and not across the whole box. In this case, it is necessary > to > >> identify the bundle and the component link ID. This can be done for > >> numbered bundles using the existing TLVs, but no mechanism exists to > >> identify the component link of an unnumbered bundle in this case. The > draft > >> defines new TLVs to make this possible. The detractors say that this is > not > >> necessary because we can force the component links to have unique > >> identities across the whole LSR. The supporters say yes, but why would > you > >> want to make this requirement when, clearly, bundle membership defines > a > >> hierarchy of identification. > > this one is even more controversial it comes from the issue based on the > definition here below > > > [John Drake] > > > >> From the bundling draft: > > > > "A component link may be either numbered or unnumbered. A bundled link > may > > itself be numbered or unnumbered independent of whether the component > links > > of that bundled link are numbered or not." > > from RFC 3471 "The IP address field may carry either an IP address of a > link or > an IP address associated with the router, where associated address is the > value > carried in a router address TLV of routing." > > > and: > > > > "Furthermore, link local identifiers for all unnumbered links of a given > LSR > > (whether component links, Forwarding Adjacencies or bundled links) MUST > be > > unique in the context of that LSR." > > > > So, what the authors of this I-D are attempting to do is redefine the > meaning > > of 'component link'. > > point here above two usage of the "IP address" and you will see that the > authors > have spent time to sort out a complex intrication between several drafts Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 15:53:21 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC017AE4DE@nimbus.chromisys.com> From: John Drake <jdrake@calient.net> To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org Subject: RE: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.tx t Date: Fri, 23 Jul 2004 08:52:09 -0700 MIME-Version: 1.0 Content-Type: text/plain Dimitri, This flag isn't needed. Once a node selects the component link, it is that link that is in the RRO. Thanks, John > -----Original Message----- > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > Sent: Friday, July 23, 2004 5:47 AM > To: ccamp@ops.ietf.org > Subject: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt > > All, there is one issue that is flagged in Section 7.1 in this draft > > <http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te- > bundled-links-00.txt> > > as needing to poll from the working group to see whether to use Session_ > Attributes or LSP_Attributes to flag component link recording and close > accordingly > > " If a node desires component link recording, the "Component Link > Recording desired" flag (value TBD) should be set in the > LSP_ATTRIBUTES object, object that is defined in [RSVP-TE- > ATTRIBUTE]. Another alternate is to use an available flag in the > SESSION_ATTRIBUTE object [RFC3209]. The later makes the component > link recording request similar to the label recording request." > > thanks for the feedback, > - dimitri Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 13:04:39 +0000 Message-ID: <41010CB1.4000900@psg.com> Date: Fri, 23 Jul 2004 15:03:45 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> CC: ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-gmpls-alarm-spec-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian, Adrian Farrel wrote: > Yet another draft that will not get a slot on the San Diego agenda. > > The authors (of whom I am one, so Kireeti is point man on any discussions) believe that > this draft is now fully cooked. It is implemented and deployed. > > I propose to take a feeling of the room in San Diego to see who has read the draft and who > opposes it going to WG last call. in the latter case would it also be possible to have some hints about the reasons so that these issues (if any) can be addressed in the next release ? thanks for the co-operation, - dimitri. > Please read and review the draft ahead of the meeting. Comments to the list. > > Thanks, > Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 12:52:59 +0000 Message-ID: <41010978.4010001@lab.ntt.co.jp> Date: Fri, 23 Jul 2004 21:50:00 +0900 From: Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp> Organization: NTT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> CC: "Vishal Sharma (E-mail 2)" <v.sharma@ieee.org>, y-suemura@bp.jp.nec.com, ccamp@ops.ietf.org Subject: Re: draft-shiomoto-ccamp-misconnection-analysis-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian Thank you for comments. See inline. Adrian Farrel wrote: >Hi Kohei et al, > >Thanks for working on this draft it is useful to have a single place to collect all of the >concerns about misconnections. As such, it is my view that this document is unlikely to >progress to RFC, but will remain as a useful "living list" of concerns to be addressed in >other drafts. It is possible, however, that we might come out of the process with some >form of BCP advising how best to avoid misconnections in deployed implementations. > > OK. Sounds good. >The authors of the e2e recovery draft tell me that they have incorporated your concerns >into the most recent version, and it would be useful if you could review it before San >Diego and let us know whether you are satisfied. You might also like to examine the >segment protection draft to decide whether you consider this is open to misconnections. >For both drafts, it would be most useful if you could send comments to the list before San >Diego. > > OK. I will review the recent version of both drafts and send comments if any. As a matter of fact, I had a chance to review the recent version e2e recovery draft a few days ago. I recognized that the issues are carefully addressed in Section 8.3 and Section 10. What we would like to discuss in the missconnection draft is to find the common solution applicable to different misconnection scenario if any. If the solution presented in the e2e recovery draft is applicable to other scenario, it is fine. >Another area where you were concerned about misconnection was in pre-emption. As you know, >pre-emption is currently being handled by the MPLS WG, and when (if?) it is resolved there >it will be our task to attempt to apply the MPLS-TE pre-emption solutions to GMPLS in such >as a way as to be functional and to avoid misconnections. > >Specific comments on your draft are found below. > >Thanks, >Adrian > >==== > >It seems to me that your cases in 4.1 and 4.2 are actually the same case. That is, it is >not relevant that 4.1 is providing protection. What is relevant is that pre-emption of >part of a path occurs. In fact, the figures that you use to illustrate the problem are the >same, and the same pre-emptions occur. I would suggest that you combine the text under a >single discussion of pre-emption, and use a single paragraph to discuss how pre-emption >may happen in a variety of network services. > > Cases in 4.1 and 4.2 look similar to each other. The slight difference is the existence of refresh messages for the pre-empting LSP. In shared-mesh restoration case (Section 4.1), the pre-empting LSP is provisioned but not yet cross-connected before the preemption takes place. We need to be careful about distinction between refhreshing and activating Path messages. On the other hand, in the case of Section 4.2, the pre-empting LSP is not provisioned before the preemption takes place. So we don't have to care about the refreshing messages in developing the mechanism to avoid misconnection. However I agree that sections 4.1 and 4.2 can be merged since they have common parts (preemption). >It is possible that the distinction you are trying to draw is that during restoration in a >PXC network, the lasers are already on for both pre-empting and pre-empted LSPs, while in >setup pre-emption it is only the pre-empted LSP that has an active laser. Perhaps you >could draw out this point more prominently. > > As you pointed out, it is more likely to have misconnection in OOO type PXC case, depending on the switch mechanism used in the node (See also the last paragraph of Section 5). The solution might be different for OOO case and OEO case. >Which does bring us to the question of whether the issues you raise are most significant >in PXC networks (where a signal cannot be turned off at a transit node) or whether they >are also relevant in OEO networks. > > In my opinion, the issues are relevant to both OOO and OEO networks. >I think it would be helpful, as well, if you could write some text about the issues for >bi-directional LSPs. This seems to be a special problem not least because certain >assumptions are made about laser activation and switch programming for the reverse data >path during LSP setup. > Thank you for your suggestion. I agree that it is helpful to write down the issues for bi-directional LSPs. >Finally, it would be useful if your draft could point explicitly at other drafts that you >believe have misconnection issues so that your draft can act as a check-list. As we >resolve (or refute) the issues in other drafts, you can update yours to track the status. >That way we will know what work remains to be done. > > OK, I would be happy to revise the draft if there are misconnection issues in other scenario. Thanks -- Kohei Shiomoto NTT Network Service Systems Laboratories Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 12:48:16 +0000 Message-ID: <410108D2.9050403@psg.com> Date: Fri, 23 Jul 2004 14:47:14 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, there is one issue that is flagged in Section 7.1 in this draft <http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt> as needing to poll from the working group to see whether to use Session_ Attributes or LSP_Attributes to flag component link recording and close accordingly " If a node desires component link recording, the "Component Link Recording desired" flag (value TBD) should be set in the LSP_ATTRIBUTES object, object that is defined in [RSVP-TE- ATTRIBUTE]. Another alternate is to use an available flag in the SESSION_ATTRIBUTE object [RFC3209]. The later makes the component link recording request similar to the label recording request." thanks for the feedback, - dimitri Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 12:42:28 +0000 Message-ID: <0b4b01c470b2$5bd48340$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Vishal Sharma \(E-mail 2\)" <v.sharma@ieee.org>, <ccamp@ops.ietf.org>, "Kireeti Kompella" <kireeti@juniper.net> Cc: "Alex Zinin" <azinin@psg.com>, "Bill Fenner" <fenner@research.att.com> Subject: Re: Specific suggestions to improve San Diego agenda [Was RE: San Diego Agenda issues] Date: Fri, 23 Jul 2004 13:39:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Continuing with my previous email.... per your request > below, here are some specific suggestions on how the > agenda for San Diego can be improved to remove the > pressure on it, thus benefiting the WG as a whole. Hmmm. Makes note not to use irony or rhetoric in future emails. > I have examined the agenda in the light of the above questions, and > have looked at the drafts currently on it. Before going any further, be ware that the default position will be that we devote the meeting entirely to satisfying our milestones. No other drafts would be examined, and no other work done. As Fred Baker recently said: ...the charter of a working group is a contract-of-sorts to accomplish something. ... I would like to see working groups held to their chartered work plans, and rechartered if the work-plan changes. I take this very seriously, and would like to dilute it only in support of existing WG drafts that also need to be progressed. If you look at the agenda you will see that it spends most of the time of milestones that have a reasonable chance of advancement, but actually touches on all of the milestones. I have said before, and will say again and again until I am heard, if you want meeting time to be spent on your drafts you MUST give time and effort to advance the WG milestones. When we have done our work, we have time to play. Who in the WG has reviewed the GMPLS MIBs? Who has provided constructive suggestions for the development of GTTP. And failing that, perhaps the WG would like to open a debate about changing the work-plan. But I have heard no discussion of that so I assume that the WG is happy with the current milestones. > i) First, I do not believe a mention by the Chairs, in less than > 30-odd seconds each, of over 15 drafts buys the WG anything. > > By removing this, the WG saves a full 5 minutes right away. [SNIP] > -- Also, I noticed in some of your emails that you intended to "take a sense > of the room" for some of the drafts on this huge list. > > I think that _should not_ be done. I do not suggest doing it for your benefit. I suggest doing it for the benefit of the chairs. I will, however, happily remove your draft from this list if that is what you are asking me to do. > It would be good to hear if the WG believes that the above suggestions do > not benefit the WG and/or should not be implemented (and why). > > Looking forward to seeing a revised agenda. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 12:28:16 +0000 Message-ID: <410103EB.4040207@psg.com> Date: Fri, 23 Jul 2004 14:26:19 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: draft-douville-ccamp-gmpls-waveband-extensions-05.txt Content-Type: multipart/mixed; boundary="------------060502030007010201020009" This is a multi-part message in MIME format. --------------060502030007010201020009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit all, as mentioned in the additional ccamp webpage, this draft plugs a hole however interest shown on this list is certainly low but so at the end of the day one may ask if this is the case 1) how implementations that have been reported in <http://www.ietf.org/IESG/Implementations/MPLS-SIGNALING-Implementation.txt> 9 supports waveband labels so do we have to make the assumption that all of them support only inverse multiplexing mechanism and/or wavelength concatenation ? 2) then what about Fiber SC ? this leaves the impression that the FSC value has been sometimes used when switching the whole content of the container (ie the fiber) while following a strict interpretation it is meant to only address spatial switching per GMPLS ARCH: "5. Fiber-Switch Capable (FSC) interfaces: Interfaces that switch data based on a position of the data in the (real world) physical spaces. An example of such an interface is that of a PXC or OXC that can operate at the level of a single or multiple fibers." thanks, - dimitri. -------- Original Message -------- Subject: I-D ACTION:draft-douville-ccamp-gmpls-waveband-extensions-05.txt Date: Thu, 22 Jul 2004 15:33:35 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to Generalized Multi-Protocol Label Switching in support of Waveband Switching Author(s) : R. Douville, et al. Filename : draft-douville-ccamp-gmpls-waveband-extensions-05.txt Pages : 11 Date : 2004-7-22 Generalized Multi-Protocol Label Switching (GMPLS) extends the MPLS control plane to encompass layer 2, time-division, wavelength and spatial switching. Along with the current development on IP over optical switching, considerable advances in optical transport systems based on the multiple optical switching granularities have been developed. Currently, GMPLS considers two layers of optical granularity using wavelengths and fibers. By introducing an extended definition of waveband switching, this document specifies the corresponding GMPLS extensions, to further integrate optical multi-granularity and benefit from the features of the corresponding switching layers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-douville-ccamp-gmpls-waveband-extensions-05.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-douville-ccamp-gmpls-waveband-extensions-05.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. --------------060502030007010201020009 Content-Type: Message/External-body; name="draft-douville-ccamp-gmpls-waveband-extensions-05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-douville-ccamp-gmpls-waveband-extensions-05.txt" Content-Type: text/plain Content-ID: <2004-7-22145216.I-D@ietf.org> --------------060502030007010201020009 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/DPAPADIM/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/DPAPADIM/LOCALS%7E1/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------060502030007010201020009-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 12:12:20 +0000 Message-ID: <0b3d01c470ad$f4d995d0$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <v.sharma@ieee.org>, <ccamp@ops.ietf.org>, "Kireeti Kompella" <kireeti@juniper.net> Cc: "Alex Zinin" <azinin@psg.com>, "Bill Fenner" <fenner@research.att.com> Subject: Re: San Diego Agenda issues Date: Fri, 23 Jul 2004 13:08:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Vishal, > Thanks for initiating this discussion. Well, I regret it! > I think this is an important topic that the WG as a whole > should probably devote some CPU cycles to, and it would > be good to get more views. If we devoted the same number of cycles to reviewing and progressing the WG work, we would not need to discuss the agenda. > To get things started, I am giving some comments and > suggestions below, and in the next email. We are all indebted, I'm sure. > > After Seoul we were told in the strongest terms by WG > > participants and by the ADs that we MUST facilitate > > discussion at the face-to-face meeting. Thirty five- > > minute slots may fill the time, but will achieve nothing. > > I looked at the Seoul meeting minutes, and do not see any > lack of discussion on the drafts _that did make it_ to the > agenda and that were discussed there. > (People may have had opinions about whether everything > on the agenda should have been there in the first place, but > whatever was there seemed to be adequately discussed.) > > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html > > Quite to the contrary, the meeting minutes seem to suggest > that even 5-minute slots, if utilized correctly, provide plenty > of time for discussion of substantive issues. So: - did you track how many slots went over time? - did you spot that the meeting overran? - did you notice that two items were dropped from the end? - did you notice how often the queue at the mic was cut off after just a couple of people? - can you count the number of times the minutes ask that "discussions be carried on on the list" > So, can the participants and AD's who thought there was a > problem _with the extent of discussion_ at the Seoul WG meeting > share their thoughts with the WG? They are, of course, welcome to. It is enough, however, that they have told the chairs. > > Of course, the chairs are only your humble servants, and if it is > > the will of the WG to > > change the agenda that is fine with us so long as: > > - it fits within the priorities and milestones in the charter > > - it conforms to the requirements passed to us by the ADs > > - we do not end up with tiny slots and no discussion on any draft > > I have some specific suggestions on how to improve the > current agenda; please see following email. > > Also, I think several people on the ML have given their inputs > in the recent past, but I don't recall seeing any response to those > notes. Remind me. > > It may be of interest that to you to know that the ADs issued > > some guiding principles: > > - don't discuss any 00 draft that was only published a short time > > before the meeting > > - don't discuss any draft that has not had discussion on the list > > - only discuss drafts where there are open issues > > - build the foundations first > > - prioritise charter work above other work > > - prioritise meeting the milestones above other charter work > > Thanks for providing these. It would be good for the AD's to also > provide these guiding principles on the ML, so the WG is aware of > them, as an when they are laid out. The WG is now aware of them and they are laid out. Why would you want the AD to waste his time cutting and pasting? Or are you saying something else? Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 11:18:43 +0000 Message-ID: <0ac401c470a6$8df6cba0$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Vishal Sharma \(E-mail 2\)" <v.sharma@ieee.org>, "Kohei Shiomoto" <Shiomoto.Kohei@lab.ntt.co.jp>, <y-suemura@bp.jp.nec.com> Cc: <ccamp@ops.ietf.org> Subject: draft-shiomoto-ccamp-misconnection-analysis-00.txt Date: Fri, 23 Jul 2004 12:13:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Kohei et al, Thanks for working on this draft it is useful to have a single place to collect all of the concerns about misconnections. As such, it is my view that this document is unlikely to progress to RFC, but will remain as a useful "living list" of concerns to be addressed in other drafts. It is possible, however, that we might come out of the process with some form of BCP advising how best to avoid misconnections in deployed implementations. The authors of the e2e recovery draft tell me that they have incorporated your concerns into the most recent version, and it would be useful if you could review it before San Diego and let us know whether you are satisfied. You might also like to examine the segment protection draft to decide whether you consider this is open to misconnections. For both drafts, it would be most useful if you could send comments to the list before San Diego. Another area where you were concerned about misconnection was in pre-emption. As you know, pre-emption is currently being handled by the MPLS WG, and when (if?) it is resolved there it will be our task to attempt to apply the MPLS-TE pre-emption solutions to GMPLS in such as a way as to be functional and to avoid misconnections. Specific comments on your draft are found below. Thanks, Adrian ==== It seems to me that your cases in 4.1 and 4.2 are actually the same case. That is, it is not relevant that 4.1 is providing protection. What is relevant is that pre-emption of part of a path occurs. In fact, the figures that you use to illustrate the problem are the same, and the same pre-emptions occur. I would suggest that you combine the text under a single discussion of pre-emption, and use a single paragraph to discuss how pre-emption may happen in a variety of network services. It is possible that the distinction you are trying to draw is that during restoration in a PXC network, the lasers are already on for both pre-empting and pre-empted LSPs, while in setup pre-emption it is only the pre-empted LSP that has an active laser. Perhaps you could draw out this point more prominently. Which does bring us to the question of whether the issues you raise are most significant in PXC networks (where a signal cannot be turned off at a transit node) or whether they are also relevant in OEO networks. I think it would be helpful, as well, if you could write some text about the issues for bi-directional LSPs. This seems to be a special problem not least because certain assumptions are made about laser activation and switch programming for the reverse data path during LSP setup. Finally, it would be useful if your draft could point explicitly at other drafts that you believe have misconnection issues so that your draft can act as a check-list. As we resolve (or refute) the issues in other drafts, you can update yours to track the status. That way we will know what work remains to be done. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 10:26:07 +0000 Message-ID: <4100E755.2020403@psg.com> Date: Fri, 23 Jul 2004 12:24:21 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp> CC: Adrian Farrel <adrian@olddog.co.uk>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, jeanlouis.leroux@francetelecom.com, Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel.be>, oki.eiji@lab.ntt.co.jp, ccamp@ops.ietf.org Subject: Re: draft-oki-ccamp-gmpls-ip-interworking-03.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi, >> Thanks for the new version of this draft. >> >> As soon as you get the chance (immediately after San Diego), can you please >> resubmit it sorting out the formatting problems and removing all of the >> gunk from the end. You don't need to wait for any other changes before you >> do that. > > OK. I apologize for having the draft with the gunk after the end of document. > We will resubmit it after removing the gunk and fixing the format problems. > >> Can you please let us know what you think the status of this draft is and >> what the proposed category is (informational or standards track)? > > The draft is getting mature at the current version. But some issues are still > open, e.g., bi-directional LSP, service interwork function (See Section 4 > and 5). In my opinion, the proposed category falls into the category of > standards track since several protocol exertions are needed (virtual FA and > numbered FA). it depends how the WG positions the effort if focus is on definition of an i/w between MPLS/GMPLS then by IETF rules the former may applies (this should be probably clarified), if it devices extensions that are of more generic usage then discussion is open >> It seems to me to be an important topic and one that needs to be addressed, >> but skimming the draft again it feels like there are a lot of words for >> what should be some fairly simple concepts. What do the rest of the WG >> think? > > MPLS to GMPLS migration/interwork need to be addressed in order to introduce > GMPLS into the already deployed MPLS-based infrastructure, which is not > GMPLS capable. I would be happy if the community give us feedback and > comments (including suggestions to skim the draft). in addition one may ask which are the issues that needs to be addressed in priority by the working group and what is the baseline to achieve migration this feedback could also be reported as what is the "trigger" for this migration to happen ? thanks, - dimitri. >> Cheers, Adrian >> >> > Thank you for your interest. Kind regards, > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 09:11:38 +0000 Message-ID: <4100D606.3000709@psg.com> Date: Fri, 23 Jul 2004 11:10:30 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Vishal Sharma <v.sharma@ieee.org> CC: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org, Kireeti Kompella <kireeti@juniper.net>, Alex Zinin <azinin@psg.com>, Bill Fenner <fenner@research.att.com> Subject: Re: Specific suggestions to improve San Diego agenda [Was RE: San Diego Agenda issues] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit vishal, some hints inline, these may help Vishal Sharma wrote: > Adrian and Kireeti, > > Continuing with my previous email.... per your request below, here are some > specific suggestions on how the agenda for San Diego can be improved to > remove the pressure on it, thus benefitting the WG as a whole. > > -Vishal > > >> -----Original Message----- From: owner-ccamp@ops.ietf.org >> [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Adrian Farrel Sent: Thursday, >> July 22, 2004 4:01 AM To: ccamp@ops.ietf.org Subject: San Diego Agenda >> issues >> >> >> All, >> >> At the risk of seeming petulant... >> >> You CANNOT [RFC2119] have both all drafts discussed and a reasonable length >> discussion on any draft. >> >> After Seoul we were told in the strongest terms by WG participants and by >> the ADs that we MUST facilitate discussion at the face-to-face meeting. >> Thirty five-minute slots may fill the time, but will achieve nothing. >> >> We have made a draft agenda which is now full. We completely understand >> that the work that you are doing in your drafts is more important than >> anything anyone in the world is doing at the moment, but we do not >> understand how you propose to cover your drafts on the agenda as it now >> stands. >> >> Of course, the chairs are only your humble servants, and if it is the will >> of the WG to change the agenda that is fine with us so long as: - it fits >> within the priorities and milestones in the charter - it conforms to the >> requirements passed to us by the ADs - we do not end up with tiny slots and >> no discussion on any draft >> >> So, ask yourselves: - why does my draft need discussion in SD? - why can't >> the discussion be on the list? - what will I recommend to be axed from the >> agenda? >> >> It may be of interest that to you to know that the ADs issued some guiding >> principles: - don't discuss any 00 draft that was only published a short >> time before the meeting - don't discuss any draft that has not had >> discussion on the list - only discuss drafts where there are open issues - >> build the foundations first - prioritise charter work above other work - >> prioritise meeting the milestones above other charter work > > I have examined the agenda in the light of the above questions, and have > looked at the drafts currently on it. > > The following is meant to be a neutral assessment, based on closely following > the development of a good majority of the work on the agenda. [Disclaimer: It > _should not_ be interpreted as reducing the importance of any of the work. > Rather, it is a serious attempt to take up the Chairs' request to solve the > agenda crunch (that we seem to be getting into more and more of late), so > that the WG as a whole benefits.] > > i) First, I do not believe a mention by the Chairs, in less than 30-odd > seconds each, of over 15 drafts buys the WG anything. > > By removing this, the WG saves a full 5 minutes right away. > > -- If the Chairs, in fact, want to draw attention to these documents, why not > post your comments/urgings/admonitions with the pointer to these drafts > directly to the ML? That is the right place to make the majority of the WG > aware of these important documents anyway. > > -- Also, I noticed in some of your emails that you intended to "take a sense > of the room" for some of the drafts on this huge list. -> i think that the intention was to launch the disucssion on the list (see several mails) and wrap-up them during these 5 minutes in order to see how to progress > I think that _should not_ be done. -> but what you think is not imho the primary intention also keep in mind that some of these drafts (such as <http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-te-router-info-00.txt> have just been made available and discussion just started) > It is very difficult, if not impossible, to get a sense of multiple drafts in > under 30 seconds each, and surely no fair sense can be got that way. > > It it much better for the sense to be taken on the ML (which is the best > place anyhow) where people have time to think and reflect, and then respond. > > ii) Second, given that the ASON Routing Design team has just been > constituted, and has only just begun its work, it is difficult to see why 10 > minutes are being given to discuss this. > > Their composition and charter have already been posted to the list and > examined by all, so none of those bear repeating. > > It should suffice for the Chairs to spend 2 minutes or so (if that) updating > the WG on it. -> there is a first cut of the draft (intent is not to go through all the ml dt chartering discussions) > So we are now at +18 minutes (possibly 20). > > iii) The end-to-end recovery document was already mature a while back, and > has been discussed at practically every IETF for the past several IETF's. > > The issue of misconnections (for the purposes of this draft) has also been > adequately addressed to the satisfaction of the people who debated this issue > (which includes me). AFAIK, that was the only substantive addition made. > > What other open issues are still left that cannot now be satisfactorily > resolved on the mailing list and that require 5 minutes of the agenda? -> this time has been provided to wrap-up the work (when adrian says 5 minutes it is 2 slides) do this in a clever way would allow to not come back to it during next meeting(s) > It would seem that the last call can easily be done on the list (and is > probably best done there), bringing us to +23 minutes (possibly 25). > > iv) The segment recovery document was made a WG document after Seoul, but I > don't recall seeing any discussion on it since. > > Clearly, either the WG has not found time to focus its attention on this work > between Seoul and now, or sufficient discussion has not been initiated on it > by the authors. > > Either way, without any debate/discussion on the ML, this draft does not > satisfy multiple criteria listed above, and it seems fair that the authors > should attempt to generate discussion on the list, or summarize things so it > can move forward. -> question is always the same there was lot of support to have this topic becoming a WG effort so issue > We are now at +28 minutes (possibly 30). > > v) I am not sure I saw the graceful shutdown draft discussed (maybe its a > split off of some related work), but if it's new work with no discussion yet, > I would say we do not need 5 minutes for it. -> <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00225.html> and follow up > vi) The comments for the L2 GMPLS draft say "what it's about?". > > It seems that any draft for which this question needs to be answered at a WG > meeting probably first needs to be discussed on the list, and automatically > does not meet multiple criteria from those you listed earlier. > > Maybe I missed it, but can anyone point out where on the ML this draft was > discussed? And, what the outcome of those discussions was? -> there is an open discussion point since minneapolis here, with the support this document received we're waiting for a go ahead > So it seems we can save a full 33 minutes (possibly 35, or 38 without > graceful shutdown) from the agenda with substantial consequent benefit to the > WG, by freeing up time for various other important activities (debates, > discussions of other drafts, issues, etc.) > > It would be good to hear if the WG believes that the above suggestions do not > benefit the WG and/or should not be implemented (and why). -> this decision is imho at the discretion of the WG chairs imho, this said i strongly believe that managing situation in a fairly way is time and effort consuming ... no surprise here > Looking forward to seeing a revised agenda. > > Thanks, -Vishal > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 08:51:46 +0000 Message-ID: <4100D136.8000106@psg.com> Date: Fri, 23 Jul 2004 10:49:58 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: John Drake <jdrake@calient.net> CC: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org, Zafar Ali <zali@cisco.com>, Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel.be>, aruns@movaz.com, 'Anca Zamfir' <ancaz@cisco.com> Subject: Re: draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit john, see in-line John Drake wrote: >> 1. Does this draft add anything at all? Isn't everything you need to know >> about bundling already covered in 3471/3/7 and the BUNDLE draft? >> >> 2. Why is it necessary to define new unnumbered component link identifiers? >> >> >> If I recall, there was some acceptance that the draft was necessary to >> define route recording of component link choice on the basis both that it >> might be useful and to provide symmetry with label recording [RFC3209]. At >> the same time (and for similar reasons) ERO specification/control of >> component link might be desirable. I believe this takes care of the first >> issue. > > [John Drake] > > If one uses the type 3 (IF_IINDEX) TLV, as stipulated in the bundling draft, > then there is no issue to be solved. Per the bundling draft and RFC 3477, a > selected component link will be carried in the RRO and can then be placed in > the ERO of a subsequent Path message. So this I-D is not needed to address > that problem. the drafts mentions that "When link bundling is used to aggregate multiple component links into a TE link bundle, the label is not the only resource that needs to be identified and recorded.In other words, the TE link bundle identifier and the label value specified in the ERO/RRO objects are not enough to completely identify the resource." at least to make things clear it is meant to avoid situation where in the RRO you [TE link and label recording] you're remark is but the use [component link and label] it works if you make the assumption that you can retrieve the association at the ingress (which is not commonly the case by definition of bundling) >> The second issue is more controversial. The view against the draft says >> that it is possible to identify a component link using IF_ID TLVs of type 4 >> and 5 yes it is more controversial > [John Drake] > >> From the bundling draft: > > "If the component link is unnumbered, the IF_ID RSVP_HOP object, or IF_ID TLV > carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The value carried in Type 3 > TLV contains the identifier of the selected component link assigned to the > link by the sender of the Path/REQUEST message." signaling processing from RFC 3473 which are the corner stone of the discussion "For bidirectional LSPs, the sender chooses the data interface in each direction. In all cases but bundling, the upstream interface is implied by the downstream interface. For bundling, the path sender explicitly identifies the component interface used in each direction." as most non-packet LSPs are bi-directional and make commonly use of bundling we are in a situation where once bundling is used, the second sentence does not apply and all IF_ID's are making use these two type now the link bundling draft mentions (and points to 3473) " Signaling must identify both the component link to use and the label to use. The choice of the component link to use is always made by the sender of the Path/REQUEST message (if an LSP is bidirectional [GMPLS-SIG], the sender chooses a component link in each direction). For unidirectional LSPs, and the forward direction of bidirectional LSPs, the sender of a Resv/MAPPING message chooses the label. For the reverse direction of a bidirectional LSP, the sender of the Path/REQUEST message selects the upstream label. With RSVP the choice of the component link is indicated by the sender of the Path message by including the IF_ID RSVP_HOP object in the Path message, as described in section 8 of [GMPLS-RSVP]." >> These TLVs contain an IP address and a component link ID. The claim of >> (some of) the authors is that this is fine if the bundle is identified by >> an IP address (i.e. is numbered) - in this case the component link ID is a >> reference within the bundle. It is also OK if the bundle is unnumbered and >> the component link ID is unique across the node - in this case the IP >> address identifies the node and the component link can be found and the >> bundle deduced by a reverse lookup (we assume that a component link is a >> member of just one bundle). Note that it is not necessary for the component >> link ID to come from the same space as the unnumbered interface IDs (as the >> draft seems to say) because a different TLV type number is used. The >> problem arises if the component link IDs are unique only within the context >> of a bundle and not across the whole box. In this case, it is necessary to >> identify the bundle and the component link ID. This can be done for >> numbered bundles using the existing TLVs, but no mechanism exists to >> identify the component link of an unnumbered bundle in this case. The draft >> defines new TLVs to make this possible. The detractors say that this is not >> necessary because we can force the component links to have unique >> identities across the whole LSR. The supporters say yes, but why would you >> want to make this requirement when, clearly, bundle membership defines a >> hierarchy of identification. this one is even more controversial it comes from the issue based on the definition here below > [John Drake] > >> From the bundling draft: > > "A component link may be either numbered or unnumbered. A bundled link may > itself be numbered or unnumbered independent of whether the component links > of that bundled link are numbered or not." from RFC 3471 "The IP address field may carry either an IP address of a link or an IP address associated with the router, where associated address is the value carried in a router address TLV of routing." > and: > > "Furthermore, link local identifiers for all unnumbered links of a given LSR > (whether component links, Forwarding Adjacencies or bundled links) MUST be > unique in the context of that LSR." > > So, what the authors of this I-D are attempting to do is redefine the meaning > of 'component link'. point here above two usage of the "IP address" and you will see that the authors have spent time to sort out a complex intrication between several drafts Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 08:29:38 +0000 Message-ID: <4100CC3A.30409@psg.com> Date: Fri, 23 Jul 2004 10:28:42 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: adrian@olddog.co.uk, Kireeti Kompella <kireeti@juniper.net> Subject: ASON routing solution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi all, the current status of the ASON Routing Solution Design Team wrt to the chartered milestones is as follows: 1) Jun '04: send Liaison to ITU-T SG15 and OIF stating creation of DT and charter -> done 2) Jul '04: first draft of "Evaluation of existing IETF routing protocols against ASON routing requirements including evaluation scenarios" -> the first cut (clearly a work in progress) on "Evaluation of existing Routing Protocols against ASON routing requirements" has been made available at <http://psg.com/~dpapadimitriou/draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt> it missed the submission deadline but hope it will trigger interesting discussions (also during the next ccamp wg meeting) thanks, - dimitri. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 08:23:02 +0000 Reply-To: <v.sharma@ieee.org> From: "Vishal Sharma" <v.sharma@ieee.org> To: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, "Kireeti Kompella" <kireeti@juniper.net> Cc: "Alex Zinin" <azinin@psg.com>, "Bill Fenner" <fenner@research.att.com> Subject: Specific suggestions to improve San Diego agenda [Was RE: San Diego Agenda issues] Date: Fri, 23 Jul 2004 01:20:28 -0700 Message-ID: <MMECLKMDFPCEJFECIBCMKENNEKAA.v.sharma@ieee.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian and Kireeti, Continuing with my previous email.... per your request below, here are some specific suggestions on how the agenda for San Diego can be improved to remove the pressure on it, thus benefitting the WG as a whole. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Thursday, July 22, 2004 4:01 AM > To: ccamp@ops.ietf.org > Subject: San Diego Agenda issues > > > All, > > At the risk of seeming petulant... > > You CANNOT [RFC2119] have both all drafts discussed and a > reasonable length discussion on > any draft. > > After Seoul we were told in the strongest terms by WG > participants and by the ADs that we > MUST facilitate discussion at the face-to-face meeting. Thirty > five-minute slots may fill > the time, but will achieve nothing. > > We have made a draft agenda which is now full. We completely > understand that the work that > you are doing in your drafts is more important than anything > anyone in the world is doing > at the moment, but we do not understand how you propose to cover > your drafts on the agenda > as it now stands. > > Of course, the chairs are only your humble servants, and if it is > the will of the WG to > change the agenda that is fine with us so long as: > - it fits within the priorities and milestones in the charter > - it conforms to the requirements passed to us by the ADs > - we do not end up with tiny slots and no discussion on any draft > > So, ask yourselves: > - why does my draft need discussion in SD? > - why can't the discussion be on the list? > - what will I recommend to be axed from the agenda? > > It may be of interest that to you to know that the ADs issued > some guiding principles: > - don't discuss any 00 draft that was only published a short time > before the meeting > - don't discuss any draft that has not had discussion on the list > - only discuss drafts where there are open issues > - build the foundations first > - prioritise charter work above other work > - prioritise meeting the milestones above other charter work I have examined the agenda in the light of the above questions, and have looked at the drafts currently on it. The following is meant to be a neutral assessment, based on closely following the development of a good majority of the work on the agenda. [Disclaimer: It _should not_ be interpreted as reducing the importance of any of the work. Rather, it is a serious attempt to take up the Chairs' request to solve the agenda crunch (that we seem to be getting into more and more of late), so that the WG as a whole benefits.] i) First, I do not believe a mention by the Chairs, in less than 30-odd seconds each, of over 15 drafts buys the WG anything. By removing this, the WG saves a full 5 minutes right away. -- If the Chairs, in fact, want to draw attention to these documents, why not post your comments/urgings/admonitions with the pointer to these drafts directly to the ML? That is the right place to make the majority of the WG aware of these important documents anyway. -- Also, I noticed in some of your emails that you intended to "take a sense of the room" for some of the drafts on this huge list. I think that _should not_ be done. It is very difficult, if not impossible, to get a sense of multiple drafts in under 30 seconds each, and surely no fair sense can be got that way. It it much better for the sense to be taken on the ML (which is the best place anyhow) where people have time to think and reflect, and then respond. ii) Second, given that the ASON Routing Design team has just been constituted, and has only just begun its work, it is difficult to see why 10 minutes are being given to discuss this. Their composition and charter have already been posted to the list and examined by all, so none of those bear repeating. It should suffice for the Chairs to spend 2 minutes or so (if that) updating the WG on it. So we are now at +18 minutes (possibly 20). iii) The end-to-end recovery document was already mature a while back, and has been discussed at practically every IETF for the past several IETF's. The issue of misconnections (for the purposes of this draft) has also been adequately addressed to the satisfaction of the people who debated this issue (which includes me). AFAIK, that was the only substantive addition made. What other open issues are still left that cannot now be satisfactorily resolved on the mailing list and that require 5 minutes of the agenda? It would seem that the last call can easily be done on the list (and is probably best done there), bringing us to +23 minutes (possibly 25). iv) The segment recovery document was made a WG document after Seoul, but I don't recall seeing any discussion on it since. Clearly, either the WG has not found time to focus its attention on this work between Seoul and now, or sufficient discussion has not been initiated on it by the authors. Either way, without any debate/discussion on the ML, this draft does not satisfy multiple criteria listed above, and it seems fair that the authors should attempt to generate discussion on the list, or summarize things so it can move forward. We are now at +28 minutes (possibly 30). v) I am not sure I saw the graceful shutdown draft discussed (maybe its a split off of some related work), but if it's new work with no discussion yet, I would say we do not need 5 minutes for it. vi) The comments for the L2 GMPLS draft say "what it's about?". It seems that any draft for which this question needs to be answered at a WG meeting probably first needs to be discussed on the list, and automatically does not meet multiple criteria from those you listed earlier. Maybe I missed it, but can anyone point out where on the ML this draft was discussed? And, what the outcome of those discussions was? So it seems we can save a full 33 minutes (possibly 35, or 38 without graceful shutdown) from the agenda with substantial consequent benefit to the WG, by freeing up time for various other important activities (debates, discussions of other drafts, issues, etc.) It would be good to hear if the WG believes that the above suggestions do not benefit the WG and/or should not be implemented (and why). Looking forward to seeing a revised agenda. Thanks, -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 08:22:53 +0000 Reply-To: <v.sharma@ieee.org> From: "Vishal Sharma" <v.sharma@ieee.org> To: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, "Kireeti Kompella" <kireeti@juniper.net> Cc: "Alex Zinin" <azinin@psg.com>, "Bill Fenner" <fenner@research.att.com> Subject: RE: San Diego Agenda issues Date: Fri, 23 Jul 2004 01:20:26 -0700 Message-ID: <MMECLKMDFPCEJFECIBCMIENNEKAA.v.sharma@ieee.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian and Kireeti, Thanks for initiating this discussion. I think this is an important topic that the WG as a whole should probably devote some CPU cycles to, and it would be good to get more views. To get things started, I am giving some comments and suggestions below, and in the next email. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Thursday, July 22, 2004 4:01 AM > To: ccamp@ops.ietf.org > Subject: San Diego Agenda issues > > > All, > > At the risk of seeming petulant... > > You CANNOT [RFC2119] have both all drafts discussed and a > reasonable length discussion on > any draft. > > After Seoul we were told in the strongest terms by WG > participants and by the ADs that we > MUST facilitate discussion at the face-to-face meeting. Thirty > five-minute slots may fill > the time, but will achieve nothing. I looked at the Seoul meeting minutes, and do not see any lack of discussion on the drafts _that did make it_ to the agenda and that were discussed there. (People may have had opinions about whether everything on the agenda should have been there in the first place, but whatever was there seemed to be adequately discussed.) http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html Quite to the contrary, the meeting minutes seem to suggest that even 5-minute slots, if utilized correctly, provide plenty of time for discussion of substantive issues. So, can the participants and AD's who thought there was a problem _with the extent of discussion_ at the Seoul WG meeting share their thoughts with the WG? (Although, I would agree that _all_ slots being 5-minutes is probably not a good idea.) > We have made a draft agenda which is now full. We completely > understand that the work that > you are doing in your drafts is more important than anything > anyone in the world is doing > at the moment, but we do not understand how you propose to cover > your drafts on the agenda > as it now stands. > Of course, the chairs are only your humble servants, and if it is > the will of the WG to > change the agenda that is fine with us so long as: > - it fits within the priorities and milestones in the charter > - it conforms to the requirements passed to us by the ADs > - we do not end up with tiny slots and no discussion on any draft I have some specific suggestions on how to improve the current agenda; please see following email. Also, I think several people on the ML have given their inputs in the recent past, but I don't recall seeing any response to those notes. > So, ask yourselves: > - why does my draft need discussion in SD? > - why can't the discussion be on the list? > - what will I recommend to be axed from the agenda? See comment just above, and my next email. > It may be of interest that to you to know that the ADs issued > some guiding principles: > - don't discuss any 00 draft that was only published a short time > before the meeting > - don't discuss any draft that has not had discussion on the list > - only discuss drafts where there are open issues > - build the foundations first > - prioritise charter work above other work > - prioritise meeting the milestones above other charter work Thanks for providing these. It would be good for the AD's to also provide these guiding principles on the ML, so the WG is aware of them, as an when they are laid out. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 03:26:41 +0000 Reply-To: <v.sharma@ieee.org> From: "Vishal Sharma" <v.sharma@ieee.org> To: "Kensuke Shindome" <k.shindome@ntt.com>, "Adrian Farrel" <adrian@olddog.co.uk>, "CCAMP" <ccamp@ops.ietf.org> Cc: <thamada@fla.fujitsu.com>, "Richard Rabbat" <rabbat@fla.fujitsu.com>, "'Kireeti Kompella'" <kireeti@juniper.net> Subject: RE: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: Draft agenda for San Diego] Date: Thu, 22 Jul 2004 20:25:00 -0700 Message-ID: <MMECLKMDFPCEJFECIBCMKENLEKAA.v.sharma@ieee.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Kensuke, Adrian, and CCAMPers, Comments in-line. (Sorry, forgot the relevant message in the previous email.) > -----Original Message----- > From: Kensuke Shindome [mailto:k.shindome@ntt.com] > Sent: Thursday, July 22, 2004 6:58 PM > To: Adrian Farrel > Cc: Kensuke Shindome; vsharma87@yahoo.com; thamada@fla.fujitsu.com; > Richard Rabbat; 'Kireeti Kompella' > Subject: Re: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: Draft > agenda for San Diego] > > > Hi Adrian, > > I understand that there are so many drafts and not enough time > for discussion. > Our charter items should be progressed. > I hope this survey trigger focusing on what carrier use GMPLS for. > > The specific points I wanted to raise (at the next meeting?) are > * The survey may contain questions about carrier usage. > - model (peer, overlay, integrated) > - layers (packet, frame/cell/, TDM, OTN, wavelength, fiber) > - control plane activity > o path provisioning > o recovery > o fault management > * The survey need to avoid mapping responders and answers > opening the name and details. > # I'm not the responder. > > (hhhm, difficult...) > > > IMHO, there are difficulties to handle routers and optical > transport equipments using GMPLS. > I'm earnestly looking for realistic merits compared with IP/MPLS > and transport network. > I think Kensuke makes a very valid point. Namely, that the carrier survey, in addition to focusing on specific carrier inputs regarding GMPLS and shared mesh, has also become a catalyst for a more general discussion of how carriers are using/planning to use GMPLS technology in various types of networks and in various configurations. This is a question that did come up as we endeavored to contact the carriers to systematically gather their inputs on shared mesh aspects, which are reflected in this draft. We will, however, be posting an update with the additional inputs that we have received so far for expanding it (both on and off the list), and will provide a pointer soon. Thus, the survey actually relates directly to all of the CCAMP charter work, and should be discussed in San Diego. The purpose of a face-to-face discussion will be to: discuss the specific points that Kensuke and others have raised, to evaluate what further aspects should be covered in the survey, and discuss how to interpret the current results. (A mailing list discussion is, of course, important, and we will continue with that, but there are specific inputs that can be obtained in a WG meeting discussion that are simply not possible on a ML; if that was not so, we wouldn't need any IETF meetings!) Given that a vast majority of the CCAMP WG work centers on GMPLS technology, a discussion of the survey in San Diego seems very appropriate. -Vishal > -----Original Message----- > From: Kensuke Shindome [mailto:k.shindome@ntt.com] > Sent: Thursday, July 22, 2004 6:58 PM > To: Adrian Farrel > Cc: Kensuke Shindome; vsharma87@yahoo.com; thamada@fla.fujitsu.com; > Richard Rabbat; 'Kireeti Kompella' > Subject: Re: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: Draft > agenda for San Diego] > > > Hi Adrian, > > I understand that there are so many drafts and not enough time > for discussion. > Our charter items should be progressed. > I hope this survey trigger focusing on what carrier use GMPLS for. > > The specific points I wanted to raise (at the next meeting?) are > * The survey may contain questions about carrier usage. > - model (peer, overlay, integrated) > - layers (packet, frame/cell/, TDM, OTN, wavelength, fiber) > - control plane activity > o path provisioning > o recovery > o fault management > * The survey need to avoid mapping responders and answers > opening the name and details. > # I'm not the responder. > > (hhhm, difficult...) > > > IMHO, there are difficulties to handle routers and optical > transport equipments using GMPLS. > I'm earnestly looking for realistic merits compared with IP/MPLS > and transport network. > > Thanks, > > > At Thu, 22 Jul 2004 15:27:41 +0100, > "Adrian Farrel" <adrian@olddog.co.uk> wrote: > > > > Hi Kensuke, > > > > I agree that this is an important discussion to have across the > community. > > I think, however, that this is a discussion that needs to be > carried out over a longer > > period and on the mailing list. > > > > What specific points would you want to raise at the meeting > that have not already been > > raised on the list and that need to be aired in a face-to-face meting? > > > > Thanks, > > Adrian > > ----- Original Message ----- > > From: "Kensuke Shindome" <k.shindome@ntt.com> > > To: "Richard Rabbat" <rabbat@fla.fujitsu.com>; <ccamp@ops.ietf.org> > > Cc: "'Adrian Farrel'" <adrian@olddog.co.uk>; <vsharma87@yahoo.com>; > > <thamada@fla.fujitsu.com> > > Sent: Thursday, July 22, 2004 9:45 AM > > Subject: Re: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: > Draft agenda for San > > Diego] > > > > > > > Hi, all > > > > > > I think it will be a good opportunity to discuss this survey > draft in SD > > > because the discussion leads up to general and individual > requirements. > > > I'm interested in not only GMPLS technical aspects but SP's > deployment examples > > > and motivation. > > > > > > Thanks, > > > > > > > > > At Wed, 21 Jul 2004 18:10:49 -0700, > > > "Richard Rabbat" <rabbat@fla.fujitsu.com> wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > > Sent: Wednesday, July 21, 2004 12:39 PM > > > > > To: Richard Rabbat > > > > > Cc: ccamp@ops.ietf.org > > > > > Subject: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: > > > > > Draft agenda for San Diego] > > > > > > > > > > > > > > > Hi Richard, > > > > > > > > > > > Sorry, I forgot to cc: the mailing list given the interest. > > > > > > > > > > >>Hi Adrian, > > > > > >> > > > > > >>We would like to get some 2 to 3 minutes to discuss our > > > > > survey results > > > > > >>under the P&R section and how they can be used to advance P&R. > > > > > >>http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carri > > > > er-survey- > > > > >>00.txt > > > > >>We're getting some good feedback by email about it and > would like to > > > > discuss > > > > >>the next steps and increase the participation of the > carriers in the > > > > debate. > > > > > > > > > You're not going to get any realistic discussion in 2 to > 3 minutes. > > > > > > > > [Richard] The purpose is to get feedback on the content, > format, etc of the > > > > survey and how to interpret the results. This is carrier > feedback that > > > > should be of high interest to everybody. Let's spend 5-6 > minutes then to > > > > have a good discussion in parallel with the ML work. > > > > > > > > > A better way to handle this, I think, is that the draft is > > > > > mentioned from the chair (as shown in the draft agenda) and > > > > > that discussions are taken to the list. Hopefully by doing > > > > > this we can build on your work to produce a survey that helps > > > > > us understand the deployment desires and motivations of > > > > > GMPLS-using providers. > > > > > > > > > Cheers, > > > > > Adrian > > > > > > > > > PS Feedback and thoughts on the draft to follow. > > > > > > > -- > > > Kensuke Shindome > > > Inovative IP Architecture Centre, NTT Communications > > > k.shindome@ntt.com > > > > > > > > > > > > -- > Kensuke Shindome > Inovative IP Architecture Centre, NTT Communications > k.shindome@ntt.com +81 03 6800 3278(phone) > -----Original Message----- > From: Kensuke Shindome [mailto:k.shindome@ntt.com] > Sent: Thursday, July 22, 2004 6:58 PM > To: Adrian Farrel > Cc: Kensuke Shindome; vsharma87@yahoo.com; thamada@fla.fujitsu.com; > Richard Rabbat; 'Kireeti Kompella' > Subject: Re: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: Draft > agenda for San Diego] > > > Hi Adrian, > > I understand that there are so many drafts and not enough time > for discussion. > Our charter items should be progressed. > I hope this survey trigger focusing on what carrier use GMPLS for. > > The specific points I wanted to raise (at the next meeting?) are > * The survey may contain questions about carrier usage. > - model (peer, overlay, integrated) > - layers (packet, frame/cell/, TDM, OTN, wavelength, fiber) > - control plane activity > o path provisioning > o recovery > o fault management > * The survey need to avoid mapping responders and answers > opening the name and details. > # I'm not the responder. > > (hhhm, difficult...) > > > IMHO, there are difficulties to handle routers and optical > transport equipments using GMPLS. > I'm earnestly looking for realistic merits compared with IP/MPLS > and transport network. > > Thanks, > > > At Thu, 22 Jul 2004 15:27:41 +0100, > "Adrian Farrel" <adrian@olddog.co.uk> wrote: > > > > Hi Kensuke, > > > > I agree that this is an important discussion to have across the > community. > > I think, however, that this is a discussion that needs to be > carried out over a longer > > period and on the mailing list. > > > > What specific points would you want to raise at the meeting > that have not already been > > raised on the list and that need to be aired in a face-to-face meting? > > > > Thanks, > > Adrian > > ----- Original Message ----- > > From: "Kensuke Shindome" <k.shindome@ntt.com> > > To: "Richard Rabbat" <rabbat@fla.fujitsu.com>; <ccamp@ops.ietf.org> > > Cc: "'Adrian Farrel'" <adrian@olddog.co.uk>; <vsharma87@yahoo.com>; > > <thamada@fla.fujitsu.com> > > Sent: Thursday, July 22, 2004 9:45 AM > > Subject: Re: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: > Draft agenda for San > > Diego] > > > > > > > Hi, all > > > > > > I think it will be a good opportunity to discuss this survey > draft in SD > > > because the discussion leads up to general and individual > requirements. > > > I'm interested in not only GMPLS technical aspects but SP's > deployment examples > > > and motivation. > > > > > > Thanks, > > > > > > > > > At Wed, 21 Jul 2004 18:10:49 -0700, > > > "Richard Rabbat" <rabbat@fla.fujitsu.com> wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > > Sent: Wednesday, July 21, 2004 12:39 PM > > > > > To: Richard Rabbat > > > > > Cc: ccamp@ops.ietf.org > > > > > Subject: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: > > > > > Draft agenda for San Diego] > > > > > > > > > > > > > > > Hi Richard, > > > > > > > > > > > Sorry, I forgot to cc: the mailing list given the interest. > > > > > > > > > > >>Hi Adrian, > > > > > >> > > > > > >>We would like to get some 2 to 3 minutes to discuss our > > > > > survey results > > > > > >>under the P&R section and how they can be used to advance P&R. > > > > > >>http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carri > > > > er-survey- > > > > >>00.txt > > > > >>We're getting some good feedback by email about it and > would like to > > > > discuss > > > > >>the next steps and increase the participation of the > carriers in the > > > > debate. > > > > > > > > > You're not going to get any realistic discussion in 2 to > 3 minutes. > > > > > > > > [Richard] The purpose is to get feedback on the content, > format, etc of the > > > > survey and how to interpret the results. This is carrier > feedback that > > > > should be of high interest to everybody. Let's spend 5-6 > minutes then to > > > > have a good discussion in parallel with the ML work. > > > > > > > > > A better way to handle this, I think, is that the draft is > > > > > mentioned from the chair (as shown in the draft agenda) and > > > > > that discussions are taken to the list. Hopefully by doing > > > > > this we can build on your work to produce a survey that helps > > > > > us understand the deployment desires and motivations of > > > > > GMPLS-using providers. > > > > > > > > > Cheers, > > > > > Adrian > > > > > > > > > PS Feedback and thoughts on the draft to follow. > > > > > > > -- > > > Kensuke Shindome > > > Inovative IP Architecture Centre, NTT Communications > > > k.shindome@ntt.com > > > > > > > > > > > > -- > Kensuke Shindome > Inovative IP Architecture Centre, NTT Communications > k.shindome@ntt.com +81 03 6800 3278(phone) Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 03:15:10 +0000 Reply-To: <v.sharma@ieee.org> From: "Vishal Sharma" <v.sharma@ieee.org> To: "Kensuke Shindome" <k.shindome@ntt.com>, "Adrian Farrel" <adrian@olddog.co.uk>, "CCAMP" <ccamp@ops.ietf.org> Cc: <thamada@fla.fujitsu.com>, "Richard Rabbat" <rabbat@fla.fujitsu.com>, "'Kireeti Kompella'" <kireeti@juniper.net> Subject: RE: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: Draft agenda for San Diego] Date: Thu, 22 Jul 2004 20:12:46 -0700 Message-ID: <MMECLKMDFPCEJFECIBCMKENKEKAA.v.sharma@ieee.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Kensuke, Adrian, and CCAMPers, I think Kensuke makes a very valid point. Namely, that the carrier survey, in addition to focusing on specific carrier inputs regarding GMPLS and shared mesh, has also become a catalyst for a more general discussion of how carriers are using/planning to use GMPLS technology in various types of networks and in various configurations. This is a question that did come up as we endeavored to contact the carriers to systematically gather their inputs on shared mesh aspects, which are reflected in this draft. We will, however, be posting an update with the additional inputs that we have received so far for expanding it (both on and off the list), and will provide a pointer soon. Thus, the survey actually relates directly to all of the CCAMP charter work, and should be discussed in San Diego. The purpose of a face-to-face discussion will be to: discuss the specific points that Kensuke and others have raised, to evaluate what further aspects should be covered in the survey, and discuss how to interpret the current results. (A mailing list discussion is, of course, important, and we will continue with that, but there are specific inputs that can be obtained in a WG meeting discussion that are simply not possible on a ML; if that was not so, we wouldn't need any IETF meetings!) Given that a vast majority of the CCAMP WG work centers on GMPLS technology, a discussion of the survey in San Diego seems very appropriate. -Vishal > -----Original Message----- > From: Kensuke Shindome [mailto:k.shindome@ntt.com] > Sent: Thursday, July 22, 2004 6:58 PM > To: Adrian Farrel > Cc: Kensuke Shindome; vsharma87@yahoo.com; thamada@fla.fujitsu.com; > Richard Rabbat; 'Kireeti Kompella' > Subject: Re: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: Draft > agenda for San Diego] > > > Hi Adrian, > > I understand that there are so many drafts and not enough time > for discussion. > Our charter items should be progressed. > I hope this survey trigger focusing on what carrier use GMPLS for. > > The specific points I wanted to raise (at the next meeting?) are > * The survey may contain questions about carrier usage. > - model (peer, overlay, integrated) > - layers (packet, frame/cell/, TDM, OTN, wavelength, fiber) > - control plane activity > o path provisioning > o recovery > o fault management > * The survey need to avoid mapping responders and answers > opening the name and details. > # I'm not the responder. > > (hhhm, difficult...) > > > IMHO, there are difficulties to handle routers and optical > transport equipments using GMPLS. > I'm earnestly looking for realistic merits compared with IP/MPLS > and transport network. > > Thanks, > > > At Thu, 22 Jul 2004 15:27:41 +0100, > "Adrian Farrel" <adrian@olddog.co.uk> wrote: > > > > Hi Kensuke, > > > > I agree that this is an important discussion to have across the > community. > > I think, however, that this is a discussion that needs to be > carried out over a longer > > period and on the mailing list. > > > > What specific points would you want to raise at the meeting > that have not already been > > raised on the list and that need to be aired in a face-to-face meting? > > > > Thanks, > > Adrian > > ----- Original Message ----- > > From: "Kensuke Shindome" <k.shindome@ntt.com> > > To: "Richard Rabbat" <rabbat@fla.fujitsu.com>; <ccamp@ops.ietf.org> > > Cc: "'Adrian Farrel'" <adrian@olddog.co.uk>; <vsharma87@yahoo.com>; > > <thamada@fla.fujitsu.com> > > Sent: Thursday, July 22, 2004 9:45 AM > > Subject: Re: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: > Draft agenda for San > > Diego] > > > > > > > Hi, all > > > > > > I think it will be a good opportunity to discuss this survey > draft in SD > > > because the discussion leads up to general and individual > requirements. > > > I'm interested in not only GMPLS technical aspects but SP's > deployment examples > > > and motivation. > > > > > > Thanks, > > > > > > > > > At Wed, 21 Jul 2004 18:10:49 -0700, > > > "Richard Rabbat" <rabbat@fla.fujitsu.com> wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > > Sent: Wednesday, July 21, 2004 12:39 PM > > > > > To: Richard Rabbat > > > > > Cc: ccamp@ops.ietf.org > > > > > Subject: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: > > > > > Draft agenda for San Diego] > > > > > > > > > > > > > > > Hi Richard, > > > > > > > > > > > Sorry, I forgot to cc: the mailing list given the interest. > > > > > > > > > > >>Hi Adrian, > > > > > >> > > > > > >>We would like to get some 2 to 3 minutes to discuss our > > > > > survey results > > > > > >>under the P&R section and how they can be used to advance P&R. > > > > > >>http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carri > > > > er-survey- > > > > >>00.txt > > > > >>We're getting some good feedback by email about it and > would like to > > > > discuss > > > > >>the next steps and increase the participation of the > carriers in the > > > > debate. > > > > > > > > > You're not going to get any realistic discussion in 2 to > 3 minutes. > > > > > > > > [Richard] The purpose is to get feedback on the content, > format, etc of the > > > > survey and how to interpret the results. This is carrier > feedback that > > > > should be of high interest to everybody. Let's spend 5-6 > minutes then to > > > > have a good discussion in parallel with the ML work. > > > > > > > > > A better way to handle this, I think, is that the draft is > > > > > mentioned from the chair (as shown in the draft agenda) and > > > > > that discussions are taken to the list. Hopefully by doing > > > > > this we can build on your work to produce a survey that helps > > > > > us understand the deployment desires and motivations of > > > > > GMPLS-using providers. > > > > > > > > > Cheers, > > > > > Adrian > > > > > > > > > PS Feedback and thoughts on the draft to follow. > > > > > > > -- > > > Kensuke Shindome > > > Inovative IP Architecture Centre, NTT Communications > > > k.shindome@ntt.com > > > > > > > > > > > > -- > Kensuke Shindome > Inovative IP Architecture Centre, NTT Communications > k.shindome@ntt.com +81 03 6800 3278(phone) Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jul 2004 01:28:56 +0000 Message-ID: <41006911.3020701@lab.ntt.co.jp> Date: Fri, 23 Jul 2004 10:25:37 +0900 From: Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp> Organization: NTT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> CC: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, jeanlouis.leroux@francetelecom.com, Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel.be>, oki.eiji@lab.ntt.co.jp, ccamp@ops.ietf.org Subject: Re: draft-oki-ccamp-gmpls-ip-interworking-03.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian Thank you for your comment. Please see inline. Adrian Farrel wrote: >Hi, > >Thanks for the new version of this draft. > >As soon as you get the chance (immediately after San Diego), can you please resubmit it >sorting out the formatting problems and removing all of the gunk from the end. You don't >need to wait for any other changes before you do that. > > OK. I apologize for having the draft with the gunk after the end of document. We will resubmit it after removing the gunk and fixing the format problems. >Can you please let us know what you think the status of this draft is and what the >proposed category is (informational or standards track)? > The draft is getting mature at the current version. But some issues are still open, e.g., bi-directional LSP, service interwork function (See Section 4 and 5). In my opinion, the proposed category falls into the category of standards track since several protocol exertions are needed (virtual FA and numbered FA). >It seems to me to be an important topic and one that needs to be addressed, but skimming >the draft again it feels like there are a lot of words for what should be some fairly >simple concepts. What do the rest of the WG think? > > MPLS to GMPLS migration/interwork need to be addressed in order to introduce GMPLS into the already deployed MPLS-based infrastructure, which is not GMPLS capable. I would be happy if the community give us feedback and comments (including suggestions to skim the draft). >Cheers, >Adrian > > Thank you for your interest. Kind regards, -- Kohei Shiomoto NTT Network Service Systems Laboratories Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 22:29:34 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC017AE49C@nimbus.chromisys.com> From: John Drake <jdrake@calient.net> To: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org Cc: Zafar Ali <zali@cisco.com>, Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel.be>, aruns@movaz.com, 'Anca Zamfir' <ancaz@cisco.com> Subject: RE: draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt Date: Thu, 22 Jul 2004 15:28:47 -0700 MIME-Version: 1.0 Content-Type: text/plain Snipped > > 1. Does this draft add anything at all? > Isn't everything you need to know about bundling already covered in > 3471/3/7 and the BUNDLE draft? > > 2. Why is it necessary to define new unnumbered component link > identifiers? > > If I recall, there was some acceptance that the draft was necessary to > define route > recording of component link choice on the basis both that it might be > useful and to > provide symmetry with label recording [RFC3209]. At the same time (and for > similar > reasons) ERO specification/control of component link might be desirable. I > believe this > takes care of the first issue. [John Drake] If one uses the type 3 (IF_IINDEX) TLV, as stipulated in the bundling draft, then there is no issue to be solved. Per the bundling draft and RFC 3477, a selected component link will be carried in the RRO and can then be placed in the ERO of a subsequent Path message. So this I-D is not needed to address that problem. > > The second issue is more controversial. The view against the draft says > that it is > possible to identify a component link using IF_ID TLVs of type 4 and 5 [John Drake] >From the bundling draft: "If the component link is unnumbered, the IF_ID RSVP_HOP object, or IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The value carried in Type 3 TLV contains the identifier of the selected component link assigned to the link by the sender of the Path/REQUEST message." . > These TLVs contain > an IP address and a component link ID. > The claim of (some of) the authors is that this is fine if the bundle is > identified by an > IP address (i.e. is numbered) - in this case the component link ID is a > reference within > the bundle. > It is also OK if the bundle is unnumbered and the component link ID is > unique across the > node - in this case the IP address identifies the node and the component > link can be found > and the bundle deduced by a reverse lookup (we assume that a component > link is a member of > just one bundle). > Note that it is not necessary for the component link ID to come from the > same space as the > unnumbered interface IDs (as the draft seems to say) because a different > TLV type number > is used. > The problem arises if the component link IDs are unique only within the > context of a > bundle and not across the whole box. In this case, it is necessary to > identify the bundle > and the component link ID. This can be done for numbered bundles using the > existing TLVs, > but no mechanism exists to identify the component link of an unnumbered > bundle in this > case. The draft defines new TLVs to make this possible. > The detractors say that this is not necessary because we can force the > component links to > have unique identities across the whole LSR. The supporters say yes, but > why would you > want to make this requirement when, clearly, bundle membership defines a > hierarchy of > identification. [John Drake] >From the bundling draft: "A component link may be either numbered or unnumbered. A bundled link may itself be numbered or unnumbered independent of whether the component links of that bundled link are numbered or not." and: "Furthermore, link local identifiers for all unnumbered links of a given LSR (whether component links, Forwarding Adjacencies or bundled links) MUST be unique in the context of that LSR." So, what the authors of this I-D are attempting to do is redefine the meaning of 'component link'. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 22:26:02 +0000 Message-ID: <0ab001c4703a$b4fd26c0$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, <jeanlouis.leroux@francetelecom.com>, "Dimitri Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, <oki.eiji@lab.ntt.co.jp>, "Kohei Shiomoto" <Shiomoto.Kohei@lab.ntt.co.jp> Cc: <ccamp@ops.ietf.org> Subject: draft-oki-ccamp-gmpls-ip-interworking-03.txt Date: Thu, 22 Jul 2004 23:14:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Thanks for the new version of this draft. As soon as you get the chance (immediately after San Diego), can you please resubmit it sorting out the formatting problems and removing all of the gunk from the end. You don't need to wait for any other changes before you do that. Can you please let us know what you think the status of this draft is and what the proposed category is (informational or standards track)? It seems to me to be an important topic and one that needs to be addressed, but skimming the draft again it feels like there are a lot of words for what should be some fairly simple concepts. What do the rest of the WG think? Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 21:57:03 +0000 Message-ID: <0aa001c47036$8cf6dcb0$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Cc: "Zafar Ali" <zali@cisco.com>, "Dimitri Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, <aruns@movaz.com>, "'Anca Zamfir'" <ancaz@cisco.com> Subject: draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt Date: Thu, 22 Jul 2004 22:06:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Yet another draft without an agenda slot, and once again I'm a co-author. So, again, Kireeti is arbiter. If you recall, this draft is the result of merging a couple of drafts in related areas in order to produce a single view of the control and reporting of component links. A little while back there was some discussion on the list about this draft raising a couple of concerns (as far as I recall). I have summarised these below as far as I remember them, but would appreciate input from the people who raised the issues (and anyone else). [On re-reading the draft I see a number of editorial issues that I will sort out with my co-authors.] Thanks, Adrian 1. Does this draft add anything at all? Isn't everything you need to know about bundling already covered in 3471/3/7 and the BUNDLE draft? 2. Why is it necessary to define new unnumbered component link identifiers? If I recall, there was some acceptance that the draft was necessary to define route recording of component link choice on the basis both that it might be useful and to provide symmetry with label recording [RFC3209]. At the same time (and for similar reasons) ERO specification/control of component link might be desirable. I believe this takes care of the first issue. The second issue is more controversial. The view against the draft says that it is possible to identify a component link using IF_ID TLVs of type 4 and 5. These TLVs contain an IP address and a component link ID. The claim of (some of) the authors is that this is fine if the bundle is identified by an IP address (i.e. is numbered) - in this case the component link ID is a reference within the bundle. It is also OK if the bundle is unnumbered and the component link ID is unique across the node - in this case the IP address identifies the node and the component link can be found and the bundle deduced by a reverse lookup (we assume that a component link is a member of just one bundle). Note that it is not necessary for the component link ID to come from the same space as the unnumbered interface IDs (as the draft seems to say) because a different TLV type number is used. The problem arises if the component link IDs are unique only within the context of a bundle and not across the whole box. In this case, it is necessary to identify the bundle and the component link ID. This can be done for numbered bundles using the existing TLVs, but no mechanism exists to identify the component link of an unnumbered bundle in this case. The draft defines new TLVs to make this possible. The detractors say that this is not necessary because we can force the component links to have unique identities across the whole LSR. The supporters say yes, but why would you want to make this requirement when, clearly, bundle membership defines a hierarchy of identification. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 19:41:28 +0000 Message-ID: <0a6c01c47023$ca0de110$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Fw: General Training in San Diego Date: Thu, 22 Jul 2004 20:39:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please feel encouraged to attend the training/information sessions run on Sunday in San Diego. Adrian ----- Original Message ----- From: "Margaret Wasserman" <margaret@thingmagic.com> To: <wgchairs@ietf.org>; <bofchairs@ietf.org>; <ietf@ietf.org> Sent: Thursday, July 22, 2004 4:05 PM Subject: General Training in San Diego > > Hi All, > > We have our usual complement of training sessions scheduled for > Sunday afternoon at the San Diego IETF meeting (see below for > details). These sessions include training for IETF Newcomer's, > Introductory Training for New or Aspiring WG Chairs, Training for > IETF Document Editors and a technical Security Tutorial. > > All of these sessions are open to any IETF participant. So, if you > will be in San Diego on Sunday afternoon, I hope you will attend! > > Thanks, > Margaret > > --- > > Sunday, August 1, 2004 > =================== > > 1300-1400 Newcomer's Training -- Grande Ballroom A (Margaret Wasserman) > > An introduction to the IETF for new or recent IETF > attendees. Covers the IETF document processes, the > structure of the IETF, and tips for new attendees to > be successful in the IETF environment. > > 1300-1500 Editor's Training -- Marina 5 (Avri Doria) > > Training for current or aspiring IETF document > editors. Covers the roles and responsibilities > of a document editor, and includes advice on > producing a high-quality IETF specification. > > 1500-1700 Intro WG Chairs Training -- Location TBD (Spencer Dawkins) > > Introductory training for new or aspiring WG > chairs. Covers the role and responsibilities of > a WG chair, and includes advice on how to run a > WG that is fair, open and productive. This class > is open to all IETF attendees. > > 1500-1700 Security Tutorial -- Grande Ballroom A (Radia Perlman) > > All IETF attendees need to be aware of the security > implications of our design choices. This session > offers a basic primer in protocol security, as well > as advice on how to write the Security Considerations > sections required for all IETF documents. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 19:37:41 +0000 Message-ID: <0a5f01c47023$38982d80$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Cc: "Ron Bonica" <Ronald.P.Bonica@mci.com>, "Eric Rosen" <erosen@cisco.com>, "Dave Meyer" <dmm@1-4-5.net>, "'Kireeti Kompella'" <kireeti@juniper.net>, "Rohit Dube" <rohit@utstar.com> Subject: Tunnel Protocol (GTTP) draft-ietf-ccamp-tunproto-00.txt Date: Thu, 22 Jul 2004 20:34:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I'm pretty concerned that there have been zero comments about this draft since it was published as a WG document immediately after Seoul. It is a significant item on our charter. Despite the list of prestigious names who have contributed to the draft there doesn't seem to be any forward movement. Could the authors tell me, please, what the plans are for this work. Could the working group please give me an opinion about whether there is any interest in this function and if so, in what timescale. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 19:37:32 +0000 Message-ID: <0a5d01c47023$35808d40$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Cc: "'Jean Philippe Vasseur'" <jvasseur@cisco.com>, "yuichi Ikejiri" <y.ikejiri@ntt.com>, <raymond_zhang@infonet.com> Subject: draft-vasseur-ccamp-loose-path-reopt-02.txt Date: Thu, 22 Jul 2004 20:21:14 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A3E_01C47029.6FFC6B00" This is a multi-part message in MIME format. ------=_NextPart_000_0A3E_01C47029.6FFC6B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This draft is another that does not make it onto the agenda for San = Diego, but I will be taking the mood of the room for whether this is = useful CCAMP work. Please read-up in advance and send comments to the = list. My comments are below. Please try to avoid strange characters in ASCII = files :-) Thanks, Adrian =3D=3D Abstract. The abstract is far too long. Can you also remove or expand any acronyms which are not widely known. = (TE, LSP, LSR, MPLS, ERO) 2. Establishment of a loosely routed TE LSP Definition of a loose hop. I think we discussed this before in another context. What you say about loose hops and the L-bit is fine, but you also need = to cover "non-specific abstract nodes" such as AS numbers or IP = prefixes, since they (although may carry the L-bit clear to indicate = that they comprise a strict hop) still imply a degree of routing freedom = that may be susceptible to reoptimization. "The path computation may either be performed by=20 means of CSPF or any Path Computation Element (PCE) and can be=20 partial (up to the next loose hop) or complete (up to the TE LSP=20 destination)." Two issues with this text. a. CSPF is a technique, PCE is a location. I don't think it is meaningful to compare them with an either-or statement. b. Your text here is explicitly allowing a transit node to resolve the ERO beyond the next next hop. This is contrary to RFC3209. It may be desirable, but it needs wider discussion if this is to be supported. <- The path an inter-area TE LSP T1 from R1 (head-End LSR) to R11=20 >- The path requested by an operator for an inter-area TE LSP T1=20 > from R1 (head-End LSR) to R11=20 4.1 Path re-evaluation request=20 Where do we stand on this draft using up one of the rare = SESSION_ATTRIBUTE flags instead of using the LSP_ATTRIBUTES object? In = particular, is this a quality of the session or the LSP? 5.1 Head-end reoptimization control=20 Previously there was some discussion of signaling by the head-end = whether reoptimization may be performed by transit nodes "autonomously" = or whether only the head-end may initiate reoptimization. This section = seems to state that you don't support this signaling and REQUIRE that = only the head-end may initiate reoptimization. I think it would be wise to cover both cases in this draft. New error values Suggest you remove the numeric values of the new error codes from all = over the text and have them in just one place for IANA assignment. Node that they are called "Error Values" not "error sub-codes" Unsatisfied reference You have a reference to [PATH-COMP], but no citation. This is an important consideration where there are constraints to the = original computation that need to be applied at later computation = points. You might also mention route exclusions in this context. 5.3.2 Mid-point explicit notification mode In the case of imminent local maintenance you are using an unreliable = message (PathErr) to notify the head-end that it really should redirect = the LSP. Is it assumed that the node that is about to go into = maintenance mode SHOULD retransmit the PathErr periodically until the = LSP is moved? What if no better path exists? Note that there is an operational contradiction seen in the network = between the statement that a head-end receiving an error value 7 or 8 is = REQUIRED to reoptimize, and a head-end that doesn't support the error = value being supposed to ignore the PathErr. How is the node that is = about to go into maintenance mode supposed to distinguish these cases? 8. Acknowledgments It is good to see that Raymond as an author is giving himself full = acknowledgment for his work ;-) Refs. [INTER-AREA-AS] is now dead. Long live its replacement. ------=_NextPart_000_0A3E_01C47029.6FFC6B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY> <DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>This draft is another that does not = make it onto=20 the agenda for San Diego, but I will be taking the mood of the room for = whether=20 this is useful CCAMP work. Please read-up in advance and send comments = to the=20 list.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>My comments are below. Please try to = avoid=20 strange characters in ASCII files :-)</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>=3D=3D</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Abstract.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>The abstract is far too = long.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Can you also remove or expand any = acronyms which=20 are not widely known. (TE, LSP, LSR, MPLS, ERO)</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>2. Establishment of a loosely routed = TE=20 LSP</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Definition of a loose = hop.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>I think we discussed this before in = another=20 context.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>What you say about loose hops and the = L-bit is=20 fine, but you also need to cover "non-specific abstract nodes" such as = AS=20 numbers or IP prefixes, since they (although may carry the L-bit clear = to=20 indicate that they comprise a strict hop) still imply a degree of = routing=20 freedom that may be susceptible to reoptimization.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2> "The path computation may = either be=20 performed by <BR> means of CSPF or any Path Computation = Element=20 (PCE) and can be <BR> partial (up to the next loose hop) or = complete=20 (up to the TE LSP <BR> destination)."<BR></FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Two issues with this = text.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>a. CSPF is a technique, PCE is a = location. I=20 don't think it is</FONT></DIV> <DIV><FONT face=3DCourier size=3D2> meaningful to compare = them with an=20 either-or statement.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>b. Your text here is explicitly = allowing a=20 transit node to</FONT></DIV> <DIV><FONT face=3DCourier size=3D2> resolve the ERO beyond = the next next=20 hop. This is contrary</FONT></DIV> <DIV><FONT face=3DCourier size=3D2> to RFC3209. It may be = desirable, but=20 it needs wider</FONT></DIV> <DIV><FONT face=3DCourier size=3D2> discussion if this = is to be=20 supported.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2><- The path an inter-area TE LSP = T1 from R1=20 (head-End LSR) to R11 <BR>>- The path requested by an operator for an = inter-area TE LSP T1 </FONT></DIV> <DIV><FONT face=3DCourier size=3D2>> from R1 (head-End LSR) to = R11=20 <BR></FONT></DIV> <DIV><FONT face=3DCourier size=3D2>4.1 Path re-evaluation request = </FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Where do we stand on this draft using = up one of=20 the rare SESSION_ATTRIBUTE flags instead of using the LSP_ATTRIBUTES = object? In=20 particular, is this a quality of the session or the LSP?</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>5.1 Head-end reoptimization control=20 <BR></FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Previously there was some discussion = of signaling=20 by the head-end whether reoptimization may be performed by transit nodes = "autonomously" or whether only the head-end may initiate reoptimization. = This=20 section seems to state that you don't support this signaling and REQUIRE = that=20 only the head-end may initiate reoptimization.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>I think it would be wise to cover = both cases in=20 this draft.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>New error values</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Suggest you remove the numeric values = of the new=20 error codes from all over the text and have them in just one place for = IANA=20 assignment.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Node that they are called "Error = Values" not=20 "error sub-codes"</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Unsatisfied reference</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>You have a reference to [PATH-COMP], = but no=20 citation.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>This is an important consideration = where there=20 are constraints to the original computation that need to be applied at = later=20 computation points.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>You might also mention route = exclusions in this=20 context.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>5.3.2 Mid-point explicit notification = mode</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>In the case of imminent local = maintenance you are=20 using an unreliable message (PathErr) to notify the head-end that it = really=20 should redirect the LSP. Is it assumed that the node that is about to go = into=20 maintenance mode SHOULD retransmit the PathErr periodically until the = LSP is=20 moved? What if no better path exists?</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Note that there is an operational = contradiction=20 seen in the network between the statement that a head-end receiving an = error=20 value 7 or 8 is REQUIRED to reoptimize, and a head-end that = doesn't=20 support the error value being supposed to ignore the PathErr. How is the = node=20 that is about to go into maintenance mode supposed to distinguish these=20 cases?</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>8. Acknowledgments</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>It is good to see that Raymond as an = author is=20 giving himself full acknowledgment for his work ;-)</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Refs.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>[INTER-AREA-AS] is now dead. Long = live its=20 replacement.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2> </DIV></FONT></BODY></HTML> ------=_NextPart_000_0A3E_01C47029.6FFC6B00-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 19:37:27 +0000 Message-ID: <0a5e01c47023$3761f770$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: draft-ietf-ccamp-gmpls-alarm-spec-00.txt Date: Thu, 22 Jul 2004 20:28:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Yet another draft that will not get a slot on the San Diego agenda. The authors (of whom I am one, so Kireeti is point man on any discussions) believe that this draft is now fully cooked. It is implemented and deployed. I propose to take a feeling of the room in San Diego to see who has read the draft and who opposes it going to WG last call. Please read and review the draft ahead of the meeting. Comments to the list. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 19:32:01 +0000 Message-Id: <200407221930.PAA18949@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt Date: Thu, 22 Jul 2004 15:30:32 -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 (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON) Author(s) : J. Drake, et al. Filename : draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt Pages : 41 Date : 2004-7-22 This document specifies how Generalized MPLS (GMPLS) RSVP-TE signaling may be used and extended to satisfy the requirements of the Automatically Switched Optical Network (ASON) architecture specified by the ITU-T. The requirements are in a companion document 'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON).' In particular, this document details the mechanisms for setting up Soft Permanent Connections (SPC), the necessary extensions in delivering full and logical call/connection separation support, the extended restart capabilities during control plane failures, extended label usage and crankback signalling capability. The mechanisms proposed in this document are applicable to any environment (including multi-area) and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-rsvp-te-ason-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-rsvp-te-ason-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: <2004-7-22145134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145134.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 18:44:54 +0000 To: "Adrian Farrel" <adrian@olddog.co.uk> Cc: <ccamp@ops.ietf.org>, "'Jean Philippe Vasseur'" <jvasseur@cisco.com>, <jeanlouis.leroux@francetelecom.com> From: Dimitri.Papadimitriou@alcatel.be Subject: Re: draft-vasseur-ccamp-te-router-info-00 MIME-Version: 1.0 Date: Thu, 22 Jul 2004 20:43:01 +0200 Message-ID: <OF8812A41D.310BFAA8-ONC1256ED9.0066D03E-C1256ED9.0066D0BC@netfr.alcatel.fr> Content-type: text/plain; charset=us-ascii hi adrian, all, here below a bunch of comments on this documents: => 3. Introduction > - Data plane capabilities related to the node itself and not to its links, > such as the capability to be a branch node or a bud LSR of a P2MP LSP > tunnel (see [P2MP-REQ]). These node capabilities should be advertised by > the IGP for path selection. It would also be highly useful to advertise > control plane node Capabilities; for instance, the capability to support > GMPLS signaling for a packet LSR, or the capability to support P2MP > signaling. This would ease backward compatibility. For instance this would > allow selecting a path that would avoid nodes that do not support a given > signaling feature, or automatically triggering a mechanism that would > handle these nodes on the path. [DP] suggest to translate the protocol specific also within the above text with something like - Nodal capabilities 1) control plane 2) data plane => 4.1. Description > > LSRs in a network may have distinct control plane and data plane Traffic > Engineering capabilities. The TE Node capability Descriptor TLV describes > data and control plane capabilities of an LSR. Such > information can be used for instance for path computation algorithm so as > to avoid nodes that do not support a given TE feature either in the control > or data plane or to trigger procedure to handle these nodes. In some case, > this may also be useful for backward compatibility. [DP] suggest to detail the backward compatibility aspects ? i guess it is to provide support of legacy LSRs ? => 4.2. Required Information > > The TE Node Capability Descriptor TLV contains two variable length sets of > bit flags: the Control Plane Capability flags and the Data Plane Capability > flags. Each flag corresponds to a given capability. > > Two flags are currently defined in the Data Plane Capability Flags: > > B bit: when set, this flag indicates that the LSR can act as a branch node > on a P2MP LSP (see [P2MP-REQ]) and [RSVP-P2MP]). > > E bit: when set, this flag indicates that the LSR can act as a bud LSR on a > P2MP LSP, i.e. and LSR that is both transit and egress. [DP] if your point is that a branch LSR could not necessarily be an egress then for a branch being also an egress both E and B bits should be set ? the question is related to the atomicity of the bits, i understand the B bit (it means i can be a branch node in addition to a pre-defined set of tapabilities assumed by default, in my view this should be spelled out or pointed from the P2MP docs), in brief: B bit = branch node but doesn't say capability in terms of ending streams E bit = transit + egress so probably B bit should also say branch + egress and then E bit would only appear as particular case of the B bit - do you see any restriction here ? > Three flags are currently defined in the Control Plane Capability Flags: > > M bit: when set, this flag indicates that the LSR supports MPLS-TE > signalling ([RSVP-TE]). > > G bit: when set this flag indicates that the LSR supports GMPLS signalling > ([RSVP-G]). > > P bit: when set, this flag indicates that the LSR supports P2MP MPLS- TE > signalling ([RSVP-P2MP]). [DP] is the P bit expected to be used only when the M bit is set ? also in that case P bit should refer also to GMPLS => "P bit: when set, this flag indicates that the LSR supports P2MP G/MPLS-TE signalling ([RSVP-P2MP])" > Note that new flags may be added if required. [DP] would be probably useful to indicate the criteria to be part of this TLV => 4.3. Procedure > > The TE Node Capability Descriptor TLV is carried in Link State > Advertisements. A router MUST originate a new Link State Advertisement > whenever the content of this information changes, or whenever required by > regular routing procedure (e.g. refresh). [DP] would you indicate that scaling should be preserved by this advertisement since 1) it is not expected that it's variation be much smaller than refresh time ans 2) usage of this information does not trigger generation (delayed via pacing or not) of a new advertisement) > TE Node Capability Descriptor TLVs are optional. When a Link State > Advertisement does not contain any TE Node capability Descriptor TLV, this > means that the TE Capabilities of that LSR are unknown. [DP] what would extinction reflect in this context ? it would be interesting to detail the expected behaviour of extinction (i.e. LSR lost its capability) => 5.1. Description > > The PCE Discovery Information allows for the auto-discovery of one or more > Path Computation Element(s). In various MPLS and GMPLS > situations, such as inter-domain TE or backup path computation, an LSR may > require to send a request to a Path Computation Element (PCE) to compute > one or more TE LSPs paths obeying a set of specified constraints. Note that > a PCE can be an LSR or an offline tool without any forwarding capability. [DP] instead of mentioning "LSR or an offline tool" it would be better to refer to co-located or a non-co-located tool because the accessibility is independent on the location - the point is to avoid mentioning the TE tool access mode and make it independent from its localisation and distribution => 5.2. Required Information > [...] > > L bit: Local scope. When set, this flag indicates that the PCE can compute > paths for the area/level the PCE Discovery Information TLV is flooded into > (the PCE can compute TE LSP paths for intra-area TE LSPs). > > I bit: Inter-area scope. When set, the PCE can perform TE LSP path > computation for inter-area TE LSPs but within the same AS. > > A bit: Inter-AS scope. When set, the PCE can perform path computation for > inter-AS TE LSPs. > > Note that those flags are not exclusive (a PCE may set one or more flags). [DP] so imagine an inter-AS LSP for which an expansion (intra-area) has to be performed normal the L bit should be used however, it doesn't seem to be possible since restricted to intra-area LSPs so the above classification is imho performed in terms of "LSP scope" while it should also be provided in terms of computational scope no matter the type of LSP - so i would suggest to rework the text here above and decouple computation capability (scope) from the LSP scope in its description the issue is that we have "expansions" and "destination" (session end-point) - expansion of the ERO can be in the present context: intra-area or multi-area which is coupled to the PCE capability - destination can be in the same area (intra-area LSP), in a different area i.e. same AS (multi-area LSP) and in a different AS (multi-AS LSP) i think this point of discussion should be processed around these lines (note that there are cases in the matrix that can be built from the above that are unapplicable or simply irrelevant) > P bit: Request Priority. The notion of request priority allows a PCC to > specify the degree of urgency of a particular request. When set, this > flag indicates that the PCE takes into account the 'request priority' in > its scheduling of the various requests. [DP] would you clarify here - because if all routers receive this information all of them can potentially make use of this information so it is not helping in solving the request scheduling in sequencing of the request one may face with a PCE > M bit: Multiple Path Computation. When set, this flag indicates that the > PCE is capable of computing more than one path obeying a set of specified > constraints (in a single pass), provided that they exist. [DP] so it is a multi-path, multi-constraint computation ? > D bit: Diversity. When set, this flag indicates that the PCE is capable of > computing diversely routed paths (link, node, SRLG). The PCC may request > the PCE to compute N diversely routed paths obeying a set of specified > constraints. Such N paths may not exist of course depending on the current > state of the network. [DP] is that not a particular case of the previous bit ? > If the PCE is capable of computing inter-AS TE LSP path, the PCE Discovery > Information TLV MAY also contain the list of AS numbers identifying the AS > for which the PCE can compute inter-AS TE LSP paths (TE-LSPs having their > destination address in this AS). This set is optional and should be > included only when the A bit is set. [DP] did you evaluate the potential length of such advertisement ? and the "loop" created with BGP information ? since the text says "MAY also contain the list of AS numbers identifying the AS for which the PCE can compute inter-AS TE LSP paths" so each time new AS's will be known this list will potentially be updated, drawing some lines along this point will help here; another aspect is to distinguish between multi-AS single carrier and multi-AS multi-carrier, and restrict the latter to stringent policy rules in terms of AS path considered for LSP => 5.3. Procedure > > The PCE Discovery Information TLV is carried in Link State Advertisements. > A router MUST originate a new Link State Advertisement whenever the content > of this information changes, or whenever required by regular routing > procedure (e.g. refresh) > > The PCE Discovery Information TLV is optional. > > If the PCE can compute an intra-area TE LSP path, the L bit MUST be set. If > it can compute an intra-area TE LSP path only for the LSRs in the area it > resides in, then the PCE Discovery Information must be contained within an > area. Otherwise, if the PCE can compute intra-area TE LSP paths for the > whole AS, then the PCE Discovery Information TLV must be flooded across the > whole AS. [DP] how do you ensure that LSR's not being part of this area can reach the PCE (i.e. is there not a reachability constraint to be added here ? in particular in case of non-co-located PCE identified by an IP address) - i guess this point should be somehow clarified > If the PCE can compute an inter-area TE LSP path, the I bit MUST be set. If > it can compute an inter-area TE LSP path only for the LSRs in the area(s) > it resides in (for instance the PCE is an ABR computing an inter-area TE > LSP path for its area), then the PCE Discovery Information must be > contained within this or these area(s). Else, if it can compute an > inter-area TE LSP path for the whole AS, then the PCE Discovery Information > must be flooded across the whole AS. > > If the PCE can compute an inter-AS TE LSP path, the A bit MUST be set, and > the PCE Discovery Information must be flooded across the whole AS. [DP] probably it would be then be preferable to refer an "external AS" path since the PCE is able to perform three expansions: intra-area, inter-area (single AS) and inter-AS (where AS in the latter refers to "external AS" from the one of the path computation requestor)- see also above comment concerning expansion vs session [...] => 6.2. Required Information > > The TE Mesh Group Information TLV allows an LSR to advertise the set of TE > mesh-groups it belongs to. For each mesh group announced by the LSR, the TE > Mesh Group Information TLV carries the following set of information: -A > Mesh-Group number identifying the TE mesh-group, -A Tail-end address > (address used as a tail end address by other LSRs belonging to the same > mesh-group), [DP] is this not part of the advertising router information, or you are looking for an additional auxiliary information here to be used a Tunnel end point address ? my concern is that there should be a statement then saying the Mesh group ID must 1) be taken from a flat 32 bit id space 2) non routable information 3) unicity on a per AS basis and 4) there is no containment relationship wrt to the tail-end address space > -A Tail-end name: string used to ease the TE-LSP naming (e.g. > 'head-name->tail-name'). [DP] is this to be used as part of the Session name field of the SESSION ATTRIBUTE object or the Extended Tunnel ID ? => 6.3. Procedure [DP] here i am concerned with an operational aspect what happens when this information is not refreshed do the LSP have to be torn down, stay unaffected ? since as stated above "The TE Mesh-Group Information allows an LSR to advertise its desire to join/leave one or more TE mesh-groups." [DP] also a rule could be defined something like "A given TE Mesh Group ID information is to be considered by a node X for setting up n LSPs from this node X to a set of destination LSRs n if this TE mesh group ID value has been advertised by that node X and received from a set of n nodes (n =< N) being part of that set" in order to clarify these procedures Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 17:47:38 +0000 Message-ID: <0a1f01c47013$842a9810$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Cc: "'Jean Philippe Vasseur'" <jvasseur@cisco.com>, <jeanlouis.leroux@francetelecom.com> Subject: draft-vasseur-ccamp-te-router-info-00 Date: Thu, 22 Jul 2004 18:42:19 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A18_01C4701B.9E2C7C80" This is a multi-part message in MIME format. ------=_NextPart_000_0A18_01C4701B.9E2C7C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jean-P and Jean-L, Thanks for this draft and for splitting the work out into this and the = two IGP-specific drafts as requested by the ADs. As you'll have seen, there is no slot for this on the San Diego agenda. = Sorry, not enough time. But we will mention the draft from the chair, = and I plan to take a sense of the room as to whether this is now ready = to be adopted by the WG as a necessary building block for more advanced = TE. Folks reading this email might want to look at the draft to prime their = pumps (and there is nothing that should prevent anyone commenting about = the draft on the mailing list). I have a few minor comments, but the general thrust is that this draft = may still include too much information specific to different situations. = For example, if we decided to sit on PCE for while because we are not = sure how to proceed, would that mean that we really wanted to block the = development of TE node capabilities? The normal approach for this sort = of work would be to define the generic objects/TLVs and processing = rules, but leave the definition of sub-object/TLVs to individual drafts = for each new function. Cheers, Adrian Document alignment Could you get the next version to start in column 0 and end in column 72 = so that I can print it, please. Section 2. Terminology < PCE: Path Computation Element whose function is to compute the =20 < path of a TE LSP it is not the head-end for. The PCE may be =20 < an LSR or an offline tool not forwarding packet. =20 > PCE: Path Computation Element whose function is to compute the =20 > path of a TE LSP for which it is not the head-end. The PCE=20 > may be an offline tool and may be located on an LSR or some > other node not forwarding packets for the LSP. < PCC: Path Computation Client (any head-end LSR) requesting a TE =20 < LSP path computation to the Path Computation Element. =20 > PCC: Path Computation Client (any LSR) requesting a path > computation from the Path Computation Element in support of > a TE LSP. < Intra-area TE LSP: TE LSP whose path does not transit across =20 < areas. =20 > Intra-area TE LSP: TE LSP whose path does not transit across =20 > IGP areas. =20 Section 3. Introduction < The current MPLS-TE/GMPLS routing focuses on TE link information. In = < return TE router information are limited to the TE router id. =20 > The current MPLS-TE/GMPLS routing focuses on TE link information. TE = > router information is limited to the TE router id. < - A Path Computation Elements (PCE) can compute paths for TE-LSPs =20 < it is not the head-end for.=20 > - A Path Computation Elements (PCE) can compute paths for TE-LSPs =20 > for which it is not the head-end. It would be highly useful that a node=20 advertise its PCE capabilities so as for the LSRs in the network=20 to automatically discover PCEs in addition to their capabilities,=20 and thus would reduce the LSR configuration overhead. This would=20 also allow for the dynamic discovery of a new PCE or that a PCE=20 is not longer alive.=20 ## We need to be clear that this is not a case of using the IGP ## to distribute topology or forwarding/data plane capabilities. ## This is an example of "overloading" the IGP with application ## capabilities of the router. In fact, there is an assumption ## here that PCE function is offered by routers that are=20 ## actively participating in the IGP - I see no reason to make=20 ## this assumption, but perhaps this is up for discussion in the ## PCE BOF (to which everyone is invited). ## ## My concern is that we are opening up the IGPs to be general ## information distribution protocols. This is clearly the thin ## end of a very large wedge, and we need to be extremely careful ## how we manage the growth of information that is added to IGP ## advertisements. - Data plane capabilities related to the node itself ## I think you should split this bullet into two. One to cover=20 ## data plane capabilities, and one to cover control plane ## capabilities. (you have done this in section 4) ## ## You could add to the data plane capabilities GMPLS cross-type ## switching capabilities.=20 - A TE mesh group is a group of LSRs that are connected by a full =20 ## Again, my concern is that you are suggesting to overload the IGP ## with information that is not routing information, but group=20 ## membership application and discovery. We have to be very careful ## how we manage such extensions to link state routing protocols. ##=20 ## I have a question about general deployment: do you see groups as ## being built typically of edge nodes (i.e. PEs) or will they have ## arbitrary membership? Section 4.2. Required Information =20 M bit: when set, this flag indicates that the LSR supports MPLS-TE=20 signalling ([RSVP-TE]).=20 =20 G bit: when set this flag indicates that the LSR supports GMPLS=20 signalling ([RSVP-G]).=20 ## Two issues.=20 ## ## Firstly, while this information may be useful on a per-router=20 ## basis, isn't it also important to know on a per-interface ## basis? That is, where there is in-band signaling, the MPLS TE=20 ## protocol can usually be turned on or off per interface. In all ## cases, the availability of (G)MPLS TE forwarding may also be ## configured per interface. Doesn't this information need to be ## added to the link capabilities? ## ## Second. How are you defining a precise distinction between MPLS ## TE and GMPLS TE? Is it simply by the use of the Generalized ## Label, or is there some more complex issue with regard to=20 ## the protocol extensions that are supported? Section 4.3 Procedure TE Node Capability Descriptor TLVs are optional. When a Link State=20 Advertisement does not contain any TE Node capability Descriptor TLV, = this means that the TE Capabilities of that LSR are unknown.=20 ## How is this future-proofed. If a new bit flag is defined in the ## future for some new attribute ("can the router walk and chew gum ## at the same time") existing routers will include the TLV, but will ## not report on the ambulatory masticatory capabilities of the router. ## How will these new bits be interpreted?=20 ## I think this can be handled through a careful statement of meaning ## since it seems likely that old routers will not support new=20 ## function. Section 5.1 Description ## Suggest that you say that the selection between available PCEs is ## out of scope. Section 5.2 Required Information ## I'm afraid that this section is premature. I know that more bits=20 ## and associated information can be defined, but precisely what is=20 ## needed in support of PCE is very unclear at this stage and is=20 ## probably a matter for the PCE BOF. ## ## One example, is that the smallest unit that a PCE can advertise=20 ## here is full area capabilities. It seems to me that a computational ## domain may often be smaller than an IGP area. D bit:=20 ## How do you handle the intersection of computational scope and ## diversity capabilities? It is possible that a PCE will be able=20 ## to provide inter-area paths, but not guarantee their diversity. ## But it will be able to guarantee diversity for intra-area paths. Section 6.2 Required information - A Tail-end name: string used to ease the TE-LSP naming (e.g.=20 head-name->tail-name').=20 ## I'm not sure exactly what you mean. ## Does this name specify the name of the LSR that is adding ## itself to the mesh group? That is, the name of the LSR to ## which each other LSR in the group MUST establish a TE LSP? ## Why is this a different name for each group to which the=20 ## LSR belongs? Surely that will/could lead to the distribution ## of a lot of duplicate text strings. Isn't it enough to have ## a single LSR/router name as a node property? ## How do group members know how much bandwidth to request for=20 ## the TE LSPs between themselves and other group members? 7. Security Considerations=20 ## Although you don't raise new security issues because you ## don't define any new protocol elements, I do think you=20 ## need to give some more guidance to the IGP WGs. ## What would be the consequence if any of this information ## was intercepted? modified? spoofed? Informative References=20 [RSVP-P2MP] ## Draft name changed under your feet. =20 ------=_NextPart_000_0A18_01C4701B.9E2C7C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DCourier size=3D2>Hi Jean-P and Jean-L,</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Thanks for this draft and for = splitting the work=20 out into this and the two IGP-specific drafts as requested by the=20 ADs.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>As you'll have seen, there is no slot = for this on=20 the San Diego agenda. Sorry, not enough time. But we will mention the = draft from=20 the chair, and I plan to take a sense of the room as to whether this is = now=20 ready to be adopted by the WG as a necessary building block for more = advanced=20 TE.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Folks reading this email might want = to look at=20 the draft to prime their pumps (and there is nothing that should prevent = anyone=20 commenting about the draft on the mailing list).</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>I have a few minor comments, but the = general=20 thrust is that this draft may still include too much information = specific to=20 different situations. For example, if we decided to sit on PCE for while = because=20 we are not sure how to proceed, would that mean that we really wanted to = block=20 the development of TE node capabilities? The normal approach for this = sort of=20 work would be to define the generic objects/TLVs and processing rules, = but leave=20 the definition of sub-object/TLVs to individual drafts for each new=20 function.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Cheers,</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Document alignment</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Could you get the next version to = start in column=20 0 and end in column 72 so that I can print it, please.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Section 2. Terminology</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>< PCE: Path = Computation Element=20 whose function is to compute the =20 <BR>< path of a TE LSP it = is not=20 the head-end for. The PCE may be =20 <BR>< an LSR or an offline = tool not=20 forwarding packet. </FONT></DIV> <DIV><FONT face=3DCourier size=3D2>> PCE: Path = Computation Element=20 whose function is to compute=20 the <BR>> &n= bsp;=20 path of a TE LSP for which it is not the head-end. The PCE </FONT></DIV> <DIV><FONT face=3DCourier = size=3D2>> =20 may be an offline tool and may be located on an LSR or=20 some</FONT></DIV> <DIV><FONT face=3DCourier = size=3D2>> =20 other node not forwarding packets for the LSP.</FONT></DIV> <DIV><BR><FONT face=3DCourier size=3D2>< PCC: Path = Computation Client=20 (any head-end LSR) requesting a TE =20 <BR>< LSP path computation = to the=20 Path Computation Element. <BR></FONT><FONT face=3DCourier=20 size=3D2>> PCC: Path Computation Client (any LSR) = requesting a=20 path</FONT></DIV> <DIV><FONT face=3DCourier=20 size=3D2>> computation = from the=20 Path Computation Element in support of</FONT></DIV> <DIV><FONT face=3DCourier = size=3D2>> a=20 TE LSP.<BR></FONT></DIV> <DIV><FONT face=3DCourier size=3D2>< Intra-area TE LSP: = TE LSP whose=20 path does not transit across <BR>< = areas. =20 <BR>> Intra-area TE LSP: TE LSP whose path does not = transit=20 across <BR>> IGP areas. = <BR></FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Section 3. Introduction</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>< The current = MPLS-TE/GMPLS=20 routing focuses on TE link information. In <BR>< = return TE=20 router information are limited to the TE router=20 id. <BR>> The current MPLS-TE/GMPLS routing = focuses on=20 TE link information. TE <BR>> router = information is=20 limited to the TE router id.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>< - A Path Computation = Elements=20 (PCE) can compute paths for TE-LSPs <BR>< it = is not=20 the head-end for. </FONT></DIV> <DIV><FONT face=3DCourier size=3D2>> - A Path Computation = Elements=20 (PCE) can compute paths for TE-LSPs <BR>> for = which it=20 is not the head-end.</DIV> <DIV> </DIV> <DIV>It would be highly useful that a node <BR>advertise its PCE=20 capabilities so as for the LSRs in the network <BR>to automatically = discover PCEs in addition to their capabilities, <BR>and thus would = reduce=20 the LSR configuration overhead. This would <BR>also allow for the = dynamic=20 discovery of a new PCE or that a PCE <BR>is not longer alive. = </DIV> <DIV> </DIV> <DIV>## We need to be clear that this is not a case of using the = IGP</DIV> <DIV>## to distribute topology or forwarding/data plane = capabilities.</DIV> <DIV>## This is an example of "overloading" the IGP with = application</DIV> <DIV>## capabilities of the router. In fact, there is an = assumption</DIV> <DIV>## here that PCE function is offered by routers that are = </DIV> <DIV>## actively participating in the IGP - I see no reason to make = </DIV> <DIV>## this assumption, but perhaps this is up for discussion in = the</DIV> <DIV>## PCE BOF (to which everyone is invited).<BR>##</DIV> <DIV>## My concern is that we are opening up the IGPs to be = general</DIV> <DIV>## information distribution protocols. This is clearly the = thin</DIV> <DIV>## end of a very large wedge, and we need to be extremely = careful</DIV> <DIV>## how we manage the growth of information that is added to = IGP</DIV> <DIV>## advertisements.</DIV></FONT> <DIV><FONT face=3DCourier size=3D2> </DIV> <DIV>- Data plane capabilities related to the node itself</DIV> <DIV> </DIV> <DIV>## I think you should split this bullet into two. One to cover = </DIV> <DIV>## data plane capabilities, and one to cover control plane</DIV> <DIV>## capabilities. (you have done this in section 4)</DIV> <DIV>##</DIV> <DIV>## You could add to the data plane capabilities GMPLS = cross-type</DIV> <DIV>## switching capabilities. </DIV> <DIV> </DIV> <DIV>- A TE mesh group is a group of LSRs that are connected by a = full =20 </DIV> <DIV> </DIV> <DIV>## Again, my concern is that you are suggesting to overload the = IGP</DIV> <DIV>## with information that is not routing information, but group = </DIV> <DIV>## membership application and discovery. We have to be very = careful</DIV> <DIV>## how we manage such extensions to link state routing = protocols.</DIV> <DIV>## </DIV> <DIV>## I have a question about general deployment: do you see groups = as</DIV> <DIV>## being built typically of edge nodes (i.e. PEs) or will they = have</DIV> <DIV>## arbitrary membership?</DIV> <DIV> </DIV> <DIV>Section 4.2. Required=20 Information &n= bsp;<BR> =20 M bit: when set, this flag indicates that the LSR supports=20 MPLS-TE <BR> signalling=20 ([RSVP-TE]). <BR> &nb= sp; <BR> G=20 bit: when set this flag indicates that the LSR supports=20 GMPLS <BR> signalling ([RSVP-G]). <BR></DIV> <DIV>## Two issues. </DIV> <DIV>##</DIV> <DIV>## Firstly, while this information may be useful on a per-router = </DIV> <DIV>## basis, isn't it also important to know on a per-interface</DIV> <DIV>## basis? That is, where there is in-band signaling, the MPLS TE = </DIV> <DIV>## protocol can usually be turned on or off per interface. In = all</DIV> <DIV>## cases, the availability of (G)MPLS TE forwarding may also = be</DIV> <DIV>## configured per interface. Doesn't this information need to = be</DIV> <DIV>## added to the link capabilities?</DIV> <DIV>##</DIV> <DIV>## Second. How are you defining a precise distinction between = MPLS</DIV> <DIV>## TE and GMPLS TE? Is it simply by the use of the = Generalized</DIV> <DIV>## Label, or is there some more complex issue with regard to </DIV> <DIV>## the protocol extensions that are supported?</DIV> <DIV> </DIV> <DIV>Section 4.3 Procedure</DIV> <DIV> </DIV> <DIV> TE Node Capability Descriptor TLVs are optional. When = a Link=20 State <BR> Advertisement does not contain any TE Node=20 capability Descriptor TLV, <BR> this means that the TE=20 Capabilities of that LSR are unknown. </DIV> <DIV> </DIV> <DIV>## How is this future-proofed. If a new bit flag is defined in = the</DIV> <DIV>## future for some new attribute ("can the router walk and chew = gum</DIV> <DIV>## at the same time") existing routers will include the TLV, but = will</DIV> <DIV>## not report on the ambulatory masticatory capabilities of the=20 router.</DIV> <DIV>## How will these new bits be interpreted? </DIV> <DIV>## I think this can be handled through a careful statement of = meaning</DIV> <DIV>## since it seems likely that old routers will not support new = </DIV> <DIV>## function.</DIV> <DIV> </DIV> <DIV>Section 5.1 Description</DIV> <DIV> </DIV> <DIV>## Suggest that you say that the selection between available PCEs = is</DIV> <DIV>## out of scope.</DIV> <DIV> </DIV> <DIV>Section 5.2 Required Information</DIV> <DIV> </DIV> <DIV>## I'm afraid that this section is premature. I know that more bits = </DIV> <DIV>## and associated information can be defined, but precisely what is = </DIV> <DIV>## needed in support of PCE is very unclear at this stage and is = </DIV> <DIV>## probably a matter for the PCE BOF.</DIV> <DIV>##</DIV> <DIV>## One example, is that the smallest unit that a PCE can advertise = </DIV> <DIV>## here is full area capabilities. It seems to me that a=20 computational</DIV> <DIV>## domain may often be smaller than an IGP area.</DIV> <DIV> </DIV> <DIV> D bit: </DIV> <DIV> </DIV> <DIV>## How do you handle the intersection of computational scope = and</DIV> <DIV>## diversity capabilities? It is possible that a PCE will be able = </DIV> <DIV>## to provide inter-area paths, but not guarantee their = diversity.</DIV> <DIV>## But it will be able to guarantee diversity for intra-area = paths.</DIV> <DIV> </DIV> <DIV><BR>Section 6.2 Required information</DIV> <DIV> </DIV> <DIV>- A Tail-end name: string used to ease the TE-LSP naming=20 (e.g. <BR> head-name->tail-name'). </DIV> <DIV> </DIV> <DIV>## I'm not sure exactly what you mean.</DIV> <DIV>## Does this name specify the name of the LSR that is adding</DIV> <DIV>## itself to the mesh group? That is, the name of the LSR to</DIV> <DIV>## which each other LSR in the group MUST establish a TE LSP?</DIV> <DIV>## Why is this a different name for each group to which the </DIV> <DIV>## LSR belongs? Surely that will/could lead to the = distribution</DIV> <DIV>## of a lot of duplicate text strings. Isn't it enough to = have</DIV> <DIV>## a single LSR/router name as a node property?</DIV> <DIV> </DIV> <DIV>## How do group members know how much bandwidth to request for = </DIV> <DIV>## the TE LSPs between themselves and other group = members?<BR></DIV> <DIV>7. Security Considerations </DIV> <DIV> </DIV> <DIV>## Although you don't raise new security issues because you</DIV> <DIV>## don't define any new protocol elements, I do think you </DIV> <DIV>## need to give some more guidance to the IGP WGs.</DIV> <DIV>## What would be the consequence if any of this information</DIV> <DIV>## was intercepted? modified? spoofed?</DIV> <DIV> </DIV> <DIV>Informative References </DIV> <DIV>[RSVP-P2MP]</DIV> <DIV> </DIV> <DIV>## Draft name changed under your feet.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV><BR> </DIV></FONT> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV></BODY></HTML> ------=_NextPart_000_0A18_01C4701B.9E2C7C80-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 11:03:27 +0000 Message-ID: <08f701c46fdb$5282c7c0$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: San Diego Agenda issues Date: Thu, 22 Jul 2004 12:00:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, At the risk of seeming petulant... You CANNOT [RFC2119] have both all drafts discussed and a reasonable length discussion on any draft. After Seoul we were told in the strongest terms by WG participants and by the ADs that we MUST facilitate discussion at the face-to-face meeting. Thirty five-minute slots may fill the time, but will achieve nothing. We have made a draft agenda which is now full. We completely understand that the work that you are doing in your drafts is more important than anything anyone in the world is doing at the moment, but we do not understand how you propose to cover your drafts on the agenda as it now stands. Of course, the chairs are only your humble servants, and if it is the will of the WG to change the agenda that is fine with us so long as: - it fits within the priorities and milestones in the charter - it conforms to the requirements passed to us by the ADs - we do not end up with tiny slots and no discussion on any draft So, ask yourselves: - why does my draft need discussion in SD? - why can't the discussion be on the list? - what will I recommend to be axed from the agenda? It may be of interest that to you to know that the ADs issued some guiding principles: - don't discuss any 00 draft that was only published a short time before the meeting - don't discuss any draft that has not had discussion on the list - only discuss drafts where there are open issues - build the foundations first - prioritise charter work above other work - prioritise meeting the milestones above other charter work Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 10:13:36 +0000 Message-ID: <40FF92D3.5070905@coritel.it> Date: Thu, 22 Jul 2004 12:11:31 +0200 From: ricciato <ricciato@coritel.it> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> CC: ccamp@ops.ietf.org Subject: Re: Draft agenda for San Diego Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Adrian, I think that it would be convenient for the WG to include a slot for discussion (not presentation) of the draft on diverse path requirements routing (namely: draft-dachille-diverse-inter-region-path-setup-00.txt ). In the current version of the agenda for San Diego I do not see any reference to that, despite in the Seoul meeting it was acknowledged to be a very important work. That time it was state that it should be discussed in the list and revised. I´m attaching an extract from the Seoul minutes at the end of this mail, for reference. Well, both an _intensive_ discussion and a careful revision have been carried on for over 2 months now. The discussion was fruitful indeed, and in the revision we have addressed _all_ the comments issued so far. The feedback were generally very positive. Therefore, considered the very high level of interest that has been demonstrated for this topic, I do not see any reson for not having the chance to discuss the changes introduced in the revised version in San Diego in order to advance it in the WG. I remark that the draft directly addresses a significant number of charter items: -- Functional specification of extensions for routing (OSPF, ISIS) and signalling (RSVP-TE) required for path establishment. -- 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 -- Specify signalling mechanisms for path protection, diverse routing and fast path restoration. Best regards Fabio Ricciato Adrian Farrel wrote: >Hi, > >Here is an early draft agenda for CCAMP in San Diego. > >As usual there is a high volume of drafts that people want to 'present'. Of necessity, >therefore, some of you must be disappointed. The usual comments apply: > >- The main place for presentation of your draft is the mailing list >- Discussion of your draft needs to be on the mailing list > (discussions at the meetings don't carry much weight) > >In order to make sure that drafts that do not get explicit slots on the agenda are not >forgotten, the chairs will attempt to mention some of the key ones, give status, and >encourage debate on the mailing list. > >(The larger amounts of time dedicated to inter-domain is in anticipation of a healthy >degree of debate.) > >Thanks, >Adrian > >=== > >CCAMP 60 - San Diego - Draft Agenda >[running total 150 / 150] > >Group Admin (Chairs) > Admin and agenda bash (5 mins) > Status of WG and drafts (5 mins) > http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-te-router-info-00.txt > http://www.ietf.org/internet-drafts/draft-vasseur-isis-te-caps-00.txt > http://www.ietf.org/internet-drafts/draft-vasseur-ospf-te-caps-00.txt > http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-loose-path-reopt-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tunproto-00.txt > >http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt > http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-03.txt > >http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-misconnection-analysis-00.txt > http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-00.txt > > Milestones and objectives (5 mins) > >ASON Requirements and Solutions > ASON Signaling and Routing Requirements and other cooked drafts (Adrian) (2 mins) > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-06.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt > http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-02.txt > > ASON Signaling Solutions (Dimitri Papadimitriou) (5 mins) > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt > > ASON Routing Solutions Design Team status (Dimitri Papadimitriou) (10 mins) > - charter & team > - plans > - drafts > > A Transport Network View of LMP (Don Fedyk) (5 minutes) > http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-transport-lmp-02.txt > - why this draft? > - adopt as WG draft? > > SG15 liaison (Wesam Alanqar 5 mins) > >Protection and Restoration > Drafts in AD review (Adrian) (2 mins) > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt > > End-to-end recovery (Dimitri Papadimitriou) (5 mins) > >http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt > - ready for last call? > > Segment Recovery (Lou Berger) (5 mins) > http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt > - ready for last call? > >Hello Protocol and Graceful Restart > Graceful restart (Lou Berger) (10 minutes) > http://www.ietf.org/internet-drafts/draft-aruns-ccamp-rsvp-restart-ext-01.txt > - good ideas? > - adopt as WG draft? > Node-id-based Hello (Zafar Ali) (5 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt > - implementation status > - ready for last call > Graceful restart (Zafar Ali / Anca Zamfir) (5 minutes) > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-00.txt > - good ideas? > - adopt as WG draft? > >Inter-Area/AS > Strategy (Kireeti) (10 minutes) > - definitions and overview > - simple requirements first > - protection and other diverse path requirements later > - PCE BOF > > Inter-domain Framework (Adrian) (15 minutes) > http://www.ietf.org/internet-drafts/draft-farrel-ccamp-inter-domain-framework-01.txt > - generality of "domain" > - separation of routing, path computation and signaling > - no attention to diverse paths at this stage > - WG adopt? > > Inter-domain RSVP-TE (Arthi Ayyangar) (15 minutes) > http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt > - Purpose of draft? > - Main issues > - WG adopt? > > Inter-domain TE LSP path computation methods (JP Vasseur) (15 minutes) > http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-inter-domain-path-comp-00.txt > - Purpose of draft? > - Main issues > - Overlap with PCE BOF? > - WG adopt? > > GMPLS Inter-AS requirements (Tomohiro Otani) (10 minutes) > http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-00.txt > - Why a separate draft? > - What are the main features? > >Summary of other work > Layer 2 GMPLS (Dimitri Papadimitriou) (5 mins) > http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt > - what's it about? > - adopt as WG draft? > > Layer 1 VPNs (Tomonori Takeda) (5 mins) > - status and plans > - still progressing "under the care of CCAMP" > - mailing list > http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-01.txt > http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-00.txt > http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt > > Here is the extract from the minutes: >******************** >Vishal Sharma talked about work on Inter-area path >protection >draft-dachille-inter-area-path-protection-00.txt > > He provided a brief overview of how it works, and showed > how it relates to other work in progress. He also listed > the next steps. > > He emphasized that this is really a generic mechanism for > diverse path computation, and protection is one > application of it, so the authors would respin with a new > name and emphasis to reflect this." > > Zafar Ali asked how this would work if there is a failure > at the time during which the backup path is being setup. > > Vishal replied that the solutions to this were, so far, > not discussed in the draft, but that there are several > options. > > He then outlined some of the options. E.g. either > default in such a case to a sequential computation, and > use XRO to exclude the link/node where backup path setup > failed, and retry the backup (and optimize both primary > and secondary later using the techniques in the draft). > Or, set up the primary and the backup again, using the > techniques described in the draft. > > Vishal said they would be happy to add some discussion > in the document, and welcomed feedback on the list. > > Zafar asked how this work relates to PCS/PCE work. > > Vishal replied that it could actually be made use of by > the PCS/PCE approach, and could be viewed as > complementary. > > Kireeti asked that further discussion be taken to the > list. > > Vishal said he welcomed further feedback on the document. > > Dimitri asked why, knowing that the proposed approach > works as expected in the intra-domain case when the > number of ABRs (where computation can be executed at each > stage) does not increase, this approach is so focused on > optimization (since it can't be achieved if this > condition is not met). > > Vishal clarified that the focus of the work is to > propose a generic mechanism to facilitate diverse path > setup by communicating alternate path info, with > optimization a desired goal (for reasons explained in > the document). > > Vishal added that given the network model (where border > nodes are not assumed to have visibility in areas other > than their own), the scheme was not trying to be > globally optimal. > > Vishal explained that in such cases some selection needs > to be performed at each stage. > > Kireeti asked that further discussion on this should be > taken to the list. > > Also, he said that Dimitri had a good point - we need to > define criteria on which any optimization is based. > > Kireeti concluded by saying that path protection and > inter-area are both in the charter, but that this document > could only be considered for a WG document after there was > discussion about the document on the list. > >******************* > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 08:47:42 +0000 Content-return: prohibited Date: Thu, 22 Jul 2004 17:45:32 +0900 From: "Kensuke Shindome" <k.shindome@ntt.com> Subject: Re: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: Draft agenda for San Diego] To: "Richard Rabbat" <rabbat@fla.fujitsu.com>, ccamp@ops.ietf.org Cc: "'Adrian Farrel'" <adrian@olddog.co.uk>, vsharma87@yahoo.com, thamada@fla.fujitsu.com Message-id: <uk6wwo2fn.wl%k.shindome@ntt.com> Organization: Innovative IP Architecture Center, NTT Communications MIME-version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-type: text/plain; charset=US-ASCII User-Agent: Wanderlust/2.11.29 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.1 (i386-mingw-nt5.0.2195) MULE/5.0 (SAKAKI) Meadow/2.00pre2 (KIKYOU) Hi, all I think it will be a good opportunity to discuss this survey draft in SD because the discussion leads up to general and individual requirements. I'm interested in not only GMPLS technical aspects but SP's deployment examples and motivation. Thanks, At Wed, 21 Jul 2004 18:10:49 -0700, "Richard Rabbat" <rabbat@fla.fujitsu.com> wrote: > > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Wednesday, July 21, 2004 12:39 PM > > To: Richard Rabbat > > Cc: ccamp@ops.ietf.org > > Subject: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: > > Draft agenda for San Diego] > > > > > > Hi Richard, > > > > > Sorry, I forgot to cc: the mailing list given the interest. > > > > >>Hi Adrian, > > >> > > >>We would like to get some 2 to 3 minutes to discuss our > > survey results > > >>under the P&R section and how they can be used to advance P&R. > > >>http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carri > er-survey- > >>00.txt > >>We're getting some good feedback by email about it and would like to > discuss > >>the next steps and increase the participation of the carriers in the > debate. > > > You're not going to get any realistic discussion in 2 to 3 minutes. > > [Richard] The purpose is to get feedback on the content, format, etc of the > survey and how to interpret the results. This is carrier feedback that > should be of high interest to everybody. Let's spend 5-6 minutes then to > have a good discussion in parallel with the ML work. > > > A better way to handle this, I think, is that the draft is > > mentioned from the chair (as shown in the draft agenda) and > > that discussions are taken to the list. Hopefully by doing > > this we can build on your work to produce a survey that helps > > us understand the deployment desires and motivations of > > GMPLS-using providers. > > > Cheers, > > Adrian > > > PS Feedback and thoughts on the draft to follow. > -- Kensuke Shindome Inovative IP Architecture Centre, NTT Communications k.shindome@ntt.com (03)6800-3242(direct), (03)6800-3278 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 01:24:00 +0000 From: "Richard Rabbat" <rabbat@fla.fujitsu.com> To: "'Tom Petch'" <nwnetworks@dial.pipex.com>, <ccamp@ops.ietf.org> Subject: RE: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies Date: Wed, 21 Jul 2004 18:23:32 -0700 Message-ID: <000a01c46f8a$80df3be0$503da485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Monday, July 19, 2004 2:09 PM > To: Richard Rabbat; ccamp@ops.ietf.org > Subject: Re: Carrier Survey Results on GMPLS-based=20 > Shared-Mesh Transport Restoration Strategies >=20 >=20 > I like it, find it useful=20 Hi Tom, Thanks. We've received several responses about it. Do you have more = feedback about the content as well in addition to methodology? > but have a nagging doubt about how=20 > much I can trust the information therein. >=20 > As is often stated, in the IETF we participate as=20 > individuals, not representing our organisations; but for this=20 > I-D to carry weight, it matters that the views in it are made=20 > by people with the authority to represent their organisations. >=20 > In implementation reports, as in the advancement of a=20 > standard, I may see the name and details of whoever made the=20 > report on behalf of the organisation, which always reassures=20 > me as to the standing of the report. >=20 > Could we have something similar here? [Richard] Completely agree with you. We were very particular in = investing a lot of time to reach the people who were authorized to represent their organizations and had a specific involvement in planning, engineering = and ops, and overall architecture. As I said in my previous email to Adrian, we're trying to get clearance = to list/name their job responsibilities. This is of course the relevant = part w/r to the survey. We're also going to publish an update of the draft with the individual anonymized results to give a better sense of the quality of the = feedback. > Tom Petch >=20 >=20 Tom, do you also have specific contacts that you can introduce us to in order to get more data points for the survey?=20 Best, Richard. > -----Original Message----- > From: Richard Rabbat <rabbat@fla.fujitsu.com> > To: ccamp@ops.ietf.org <ccamp@ops.ietf.org> > Date: 14 July 2004 19:54 > Subject: Carrier Survey Results on GMPLS-based Shared-Mesh=20 > Transport Restoration Strategies >=20 >=20 > Dear all, >=20 > Please take a look at our new draft: > Carrier Survey Results on GMPLS-based Shared-Mesh Transport=20 > Restoration Strategies available at: >=20 > <http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrie r-survey-00.t x t> http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-00.= tx t This draft presents the results of a survey about carrier interest in = shared mesh restoration, their requirements and their concerns. We have tried = to be as encompassing as possible going to carriers in Europe, Asia and North America. We are hoping to include input from more carriers and would = like to ask the community in general and the carriers in particular to let us = know what new information they would like to see surveyed in the next update. Basically, we have the following questions: - Are you interested in GMPLS-based solutions to the requirements? - Can you suggest additional contacts to enable us to reach more = carriers and get their feedback? - Have we overlooked any aspect of restoration for shared mesh? - What additional questions would you like to see? Some of the surveyed carriers have already provided inputs on this and = we'd like to ask others to give us their comments as well. Thanks, Richard. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 01:11:22 +0000 From: "Richard Rabbat" <rabbat@fla.fujitsu.com> To: "'Adrian Farrel'" <adrian@olddog.co.uk> Cc: <ccamp@ops.ietf.org>, <vsharma87@yahoo.com>, <thamada@fla.fujitsu.com> Subject: RE: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: Draft agenda for San Diego] Date: Wed, 21 Jul 2004 18:10:49 -0700 Message-ID: <000901c46f88$b9f58fd0$503da485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, July 21, 2004 12:39 PM > To: Richard Rabbat > Cc: ccamp@ops.ietf.org > Subject: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: > Draft agenda for San Diego] > > > Hi Richard, > > > Sorry, I forgot to cc: the mailing list given the interest. > > >>Hi Adrian, > >> > >>We would like to get some 2 to 3 minutes to discuss our > survey results > >>under the P&R section and how they can be used to advance P&R. > >>http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carri er-survey- >>00.txt >>We're getting some good feedback by email about it and would like to discuss >>the next steps and increase the participation of the carriers in the debate. > You're not going to get any realistic discussion in 2 to 3 minutes. [Richard] The purpose is to get feedback on the content, format, etc of the survey and how to interpret the results. This is carrier feedback that should be of high interest to everybody. Let's spend 5-6 minutes then to have a good discussion in parallel with the ML work. > A better way to handle this, I think, is that the draft is > mentioned from the chair (as shown in the draft agenda) and > that discussions are taken to the list. Hopefully by doing > this we can build on your work to produce a survey that helps > us understand the deployment desires and motivations of > GMPLS-using providers. > Cheers, > Adrian > PS Feedback and thoughts on the draft to follow. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jul 2004 00:52:36 +0000 From: "Richard Rabbat" <rabbat@fla.fujitsu.com> To: "'Adrian Farrel'" <adrian@olddog.co.uk> Cc: <ccamp@ops.ietf.org>, "'Vishal Sharma \(E-mail 2\)'" <v.sharma@ieee.org>, <thamada@fla.fujitsu.com> Subject: RE: draft-rabbat-ccamp-carrier-survey-00.txt Date: Wed, 21 Jul 2004 17:51:34 -0700 Message-ID: <000001c46f86$09c67b80$503da485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Answers to the big issues here... > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, July 21, 2004 1:21 PM > To: Richard Rabbat; Vishal Sharma (E-mail 2); thamada@fla.fujitsu.com > Cc: ccamp@ops.ietf.org > Subject: draft-rabbat-ccamp-carrier-survey-00.txt >=20 >=20 > Hi, >=20 > Thanks for starting the ball rolling on this. >=20 > It is tempting to start analysing the results, but probably too early. >=20 > One SP responded that they are already using shared-mesh. It=20 > would be hugely interesting to know the experiences of this=20 > operator. Would they be prepared to stand up? If not, would=20 > they be prepared to filter their comments anonymously through=20 > the chair? >=20 [Richard] I have sent email to my contact at the specific carrier and = will update you and the ML about their preference. > I have some big and little issues with the draft. >=20 > Big issues. >=20 > A. >=20 > I'm inclined to agree with Tom Petch. Surveys are, of course,=20 > very delicate things especially when they apply to future=20 > plans of competitive bodies, but it really would be useful to=20 > have some indication of the responses for each SP. >=20 > I suggest you look at the old GMPLS implementation survey=20 > format. The draft consisted of a summarization (like what you=20 > have published) but also included all of the questionnaire=20 > responses to that we could see how the responses to each=20 > question were correlated. It is not necessary to force the=20 > identification of each responder, but you should allow them=20 > to be identified if they choose. >=20 [Richard] Tom's and your comment are to the point. We've actually = thought about this and looked at the old survey. We are still waiting to get permission from some carriers that have not given us the OK yet to = publish the results in an anonymized fashion just as you suggest. We'll update = the draft as soon as we get the response. > In any case, it would be useful to understand where the=20 > individuals responding fit within their company=20 > organisations. Without casting any aspersions, there is a=20 > large difference between someone in the research department=20 > and someone in the operations department. >=20 [Richard] None of the respondents are from the research departments. = They are from planning, engineering and operations, exactly what you're = looking for. > B. >=20 > I would like to see (as I'm sure you intend) a more open=20 > invitation to participate in the survey. Probably refine the=20 > survey, post it somewhere, notify the mailing list and=20 > through other channels. >=20 [Richard] Definitely agree. This is exactly one of the purposes of the = draft as stated in my emails and in the draft.=20 It has taken us a long time to identify the right people at different carriers and would love to get more feedback. We've already had emails from people offering us help in getting more carriers to respond to it.=20 We submitted this one to get the kind of feedback we're now getting so = that we can approach a larger number of carriers with the updated survey. > C. >=20 > Although the abstract/introduction mentions optical networks,=20 > the survey does not appear to draw any differentiation=20 > between the various switching capabilities. I think it is=20 > fundamental to an understanding of what carriers are trying=20 > to achieve to know what type of network they are trying to=20 > build (PSC, TDM, WDM etc.). >=20 [Richard] Good point. We'll ask carriers to give us what they're using = from the list of: 1=3DPSC, 51=3DL2SC, 100=3DTDM, 150=3DLSC, 200=3DFSC > D. Questions 2 and 3 on the survey seem pretty important, but=20 > don't appear in section 5. >=20 [Richard] We'll add these in the next iteration.=20 > E. >=20 > Section 5.1 claims that the responses relate to GMPLS, but=20 > the question is about "an IP-based control plane such as GMPLS." >=20 [Richard] Yes, the goal was to be more general in order to get feedback = from carriers that are looking at IP protocols for their control plane. We'll change the title for consistency. > G. >=20 > Section 5.2 claims that the responses relate to using GMPLS=20 > to provide shared-mesh restoration, but the survey question=20 > does not mention GMPLS. >=20 [Richard] All questions were structured in the context of an IP-based control plane such as GMPLS. I'll clarify this.=20 > H. >=20 > Section 5.3 is a good example of why we need to provide the=20 > responses correlated by responder. For some responders the=20 > answers here may have prevented them from making plans to=20 > deploy, for others they plan to deploy despite their=20 > concerns. For others, they have no plans to deploy for other=20 > reasons, but have still voiced concerns. >=20 [Richard] See answer to A. This should be clarified with the anonymous responses listed in random order in our update. > I. >=20 > Section 5.4. It is not clear whether the final comment in=20 > this section is your interpretation, apple-pie, or a specific=20 > response to the survey. >=20 [Richard] No apple pie and no interpretation. The last comments are = literal copies of responses from the 2 carriers that listed "(f) other". I will update to show: Carrier 1: For some applications, 50ms is required. For others a = business case can be made for longer duration restorals.=20 Carrier 2: Closer the duct the faster in general, closer the = applications the slower in general. > J. >=20 > Section 5.5 claims that the responses pertain to traffic=20 > carried on the responder's network, but the question makes no=20 > reference to this and is general in nature. >=20 [Richard] All the carriers that we contacted are so large as to carry = all these services. We'll clarify this to make sure that new respondents = discuss only their carried traffic. > K. >=20 > Why does question 9 lead the witness? In order to establish=20 > the true requirements we should not discuss specific solution=20 > models, but try to understand what the operational concerns are. >=20 [Richard] There is no intention to lead the answer. We'll change this in = the survey to say: "Do you have any concerns in each of the following = areas?" I hope this clarifies all issues you listed. If you have more comments, please let me know. Of course, carrier contacts you may have would be great. Best, Richard Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 23:42:32 +0000 Message-ID: <089401c46f7c$40ae2940$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Cc: "Arthi Ayyangar" <arthi@juniper.net> Subject: Re: questions on draft-vasseur-ccamp-inter-area-as-te-00.txt Date: Thu, 22 Jul 2004 00:40:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Forwarded to CCAMP [Arthi, you sent it to me and Kireeti as list owners, not to the mail exploder] ----- Original Message ----- From: "Arthi Ayyangar" <arthi@juniper.net> To: "Kullberg Alan-G19424" <alan.kullberg@motorola.com> Cc: <owner-ccamp@ops.ietf.org>; <jpv@cisco.com> Sent: Thursday, July 22, 2004 12:24 AM Subject: Re: questions on draft-vasseur-ccamp-inter-area-as-te-00.txt > Hi Alan, > > > I have a couple of questions on draft-vasseur-ccamp-inter-area-as-te-00.txt. > > > 1. How are the following 2 flags related: > > 0x02: LSP stitching required > > 0x04: LSP stitching desired > > >From my reading of the draft, they may be used for the same purpose, > > >and therefor 1 of them should be removed? > ---------> Yes, this was a mistake in the draft and has been rectified in > the new doc. draft-vasseur-ccamp-inter-area-as-te-00.txt is the older > version of the draft. The signaling aspects are now covered in > draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt. > Looks like the draft was not announced here in ccamp. > > > > 2. Regarding LSP Stitching: How does the egress of the stitch segment > > associate the inter-AS LSP and the LSP segment? To clarify, from the > > example on page 19: > > "Eventually as the Resv message for the inter-AS TE LSP > > traverses back from ASBR9 to ASBR7 and reaches ASBR7, ASBR7 will > > remember to swap the LSP segment label with the label received for the > > inter-AS LSP from ASBR9. Also, ASBR7 will itself allocate a NULL label > > in the Resv message for the inter-AS TE LSP and sends the Resv message > > to ASBR4." What objects in the Path or Resv messages does ASBR7 use > > to associate the inter-AS LSP with the LSP segment? > ---------> The IF_ID Hop object would be used to identify the LSP > segment. The signaling procedures are similar to those described in > section 8.1.1 of the LSP Hierarchy draft for identification of the FA-LSP. > > thanks, > -arthi > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 21:34:49 +0000 Message-ID: <082301c46f6a$3b2ae560$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Richard Rabbat" <rabbat@fla.fujitsu.com>, "'Vishal Sharma \(E-mail 2\)'" <v.sharma@ieee.org>, <thamada@fla.fujitsu.com> Cc: <ccamp@ops.ietf.org> Subject: Re: draft-rabbat-ccamp-carrier-survey-00.txt Date: Wed, 21 Jul 2004 22:31:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, > > a. > > > > It might be nice if the draft file name gave a little more > > clue about the content of the survey. You might consider > > draft-rabbat-ccamp-gmpls-mesh-carrier-survey-00.txt > > [Richard] I agree. As you can see from the quoted email from IETF, the > longer filename that I asked for was rejected so I had to shorten it. Whatever. > > b. Please try to avoid spurious characters in the text. > > [Richard] I can't get bad characters to print here; are there specific > characters that are printing bad? I tested from windows and Unix boxes... Second line of abstract. End of second word. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 20:55:30 +0000 From: "Richard Rabbat" <rabbat@fla.fujitsu.com> To: "'Adrian Farrel'" <adrian@olddog.co.uk>, "'Vishal Sharma \(E-mail 2\)'" <v.sharma@ieee.org>, <thamada@fla.fujitsu.com> Cc: <ccamp@ops.ietf.org> Subject: RE: draft-rabbat-ccamp-carrier-survey-00.txt Date: Wed, 21 Jul 2004 13:55:04 -0700 Message-ID: <004601c46f65$01d1e750$453ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Adrian, Thanks for the extensive review and feedback. I'll answer the little issues here first. Answers to big issues in an email to follow. > Little issues. > > a. > > It might be nice if the draft file name gave a little more > clue about the content of the survey. You might consider > draft-rabbat-ccamp-gmpls-mesh-carrier-survey-00.txt [Richard] I agree. As you can see from the quoted email from IETF, the longer filename that I asked for was rejected so I had to shorten it. > -----Original Message----- > From: Dinara Suleymanova [mailto:dinaras@foretec.com] > Sent: Thursday, July 08, 2004 6:46 AM > To: Richard Rabbat > Subject: Re: New Internet draft submission > > Too long file name. Please shorten and resubmit. > > At 09:05 PM 7/7/2004, you wrote: > >Dear IETF draft submission manager, > >Attached is a copy of a new draft submitted for consideration by the > >IETF CCAMP WG. > > > >Title: Carrier Survey Results on GMPLS-based Shared-Mesh Transport > >Restoration Strategies > >draft-rabbat-ccamp-carrier-survey-sharedmesh-restoration-00.txt > b. Please try to avoid spurious characters in the text. [Richard] I can't get bad characters to print here; are there specific characters that are printing bad? I tested from windows and Unix boxes... > > c. > > Abstract says that a number of GMPLS routing and signaling > standards have been completed. I think the RFCs are only at > Proposed Standard at the moment. > [Richard] Yes, will update. > d. Don't think you need section 2 > [Richard] Will remove. > e. > > Glad that you have a one paragraph definition of "shared mesh > restoration" in the survey. Probably good to copy it into the > main draft. [Richard] Sounds good, will do. > Cheers, > Adrian > See you in SD, Richard. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 20:53:05 +0000 Message-ID: <5D454811D0A1D711A12A00065BF36FAD04FB6BEE@il06exm11> From: Kullberg Alan-G19424 <alan.kullberg@motorola.com> To: "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org> Cc: "'jpv@cisco.com'" <jpv@cisco.com>, "'arthi@juniper.net'" <arthi@juniper.net> Subject: questions on draft-vasseur-ccamp-inter-area-as-te-00.txt Date: Wed, 21 Jul 2004 15:51:48 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46F64.718D10A5" 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_01C46F64.718D10A5 Content-Type: text/plain Hi JP & Arthi, I have a couple of questions on draft-vasseur-ccamp-inter-area-as-te-00.txt. 1. How are the following 2 flags related: 0x02: LSP stitching required 0x04: LSP stitching desired >From my reading of the draft, they may be used for the same purpose, and therefor 1 of them should be removed? 2. Regarding LSP Stitching: How does the egress of the stitch segment associate the inter-AS LSP and the LSP segment? To clarify, from the example on page 19: "Eventually as the Resv message for the inter-AS TE LSP traverses back from ASBR9 to ASBR7 and reaches ASBR7, ASBR7 will remember to swap the LSP segment label with the label received for the inter-AS LSP from ASBR9. Also, ASBR7 will itself allocate a NULL label in the Resv message for the inter-AS TE LSP and sends the Resv message to ASBR4." What objects in the Path or Resv messages does ASBR7 use to associate the inter-AS LSP with the LSP segment? Thanks, Alan ------_=_NextPart_001_01C46F64.718D10A5 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFz cz05MTEzNDIxMTgtMjEwNzIwMDQ+SGkgSlAgJmFtcDsgDQpBcnRoaSw8L1NQQU4+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz05MTEzNDIxMTgt MjEwNzIwMDQ+SSBoYXZlIGEgY291cGxlIG9mIA0KcXVlc3Rpb25zIG9uIGRyYWZ0LXZhc3NldXIt Y2NhbXAtaW50ZXItYXJlYS1hcy10ZS0wMC50eHQuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz05MTEzNDIxMTgtMjEwNzIwMDQ+ PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ PFNQQU4gY2xhc3M9OTExMzQyMTE4LTIxMDcyMDA0PjEuIEhvdyBhcmUgdGhlIA0KZm9sbG93aW5n IDIgZmxhZ3MgcmVsYXRlZDo8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48U1BBTiBjbGFzcz05MTEzNDIxMTgtMjEwNzIwMDQ+Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KMHgwMjogTFNQIHN0aXRjaGluZyByZXF1aXJlZDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTkxMTM0MjExOC0yMTA3MjAw ND48L1NQQU4+PC9GT05UPjxGT05UIA0KZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9OTEx MzQyMTE4LTIxMDcyMDA0PiZuYnNwOyZuYnNwOyZuYnNwOyAweDA0OiBMU1AgDQpzdGl0Y2hpbmcg ZGVzaXJlZDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjxTUEFOIGNsYXNzPTkxMTM0MjExOC0yMTA3MjAwND5Gcm9tIG15IHJlYWRpbmcgb2YgDQp0aGUg ZHJhZnQsIHRoZXkgbWF5IGJlIHVzZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UsIGFuZCB0aGVyZWZv ciAxIG9mIHRoZW0gc2hvdWxkIA0KYmUgcmVtb3ZlZD88L1NQQU4+PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTkxMTM0MjExOC0yMTA3MjAw ND48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj48U1BBTiANCmNsYXNzPTkxMTM0MjExOC0yMTA3MjAwND48L1NQQU4+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz05MTEzNDIxMTgt MjEwNzIwMDQ+Mi4gUmVnYXJkaW5nIExTUCANClN0aXRjaGluZzo8L1NQQU4+PC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz05MTEzNDIxMTgtMjEw NzIwMDQ+SG93IGRvZXMgdGhlIGVncmVzcyANCm9mIHRoZSBzdGl0Y2ggc2VnbWVudCBhc3NvY2lh dGUgdGhlIGludGVyLUFTIExTUCBhbmQgdGhlIExTUCANCnNlZ21lbnQ/PC9TUEFOPjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9OTExMzQyMTE4 LTIxMDcyMDA0PlRvIGNsYXJpZnksIGZyb20gdGhlIA0KZXhhbXBsZSBvbiBwYWdlIDE5OjwvU1BB Tj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNz PTkxMTM0MjExOC0yMTA3MjAwND4mbmJzcDsmbmJzcDsgDQoiRXZlbnR1YWxseSBhcyB0aGUgUmVz diBtZXNzYWdlIGZvciB0aGUgaW50ZXItQVMgVEUgTFNQIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsg DQp0cmF2ZXJzZXMgYmFjayBmcm9tIEFTQlI5IHRvIEFTQlI3IGFuZCByZWFjaGVzIEFTQlI3LCBB U0JSNyB3aWxsIA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyByZW1lbWJlciB0byBzd2FwIHRoZSBM U1Agc2VnbWVudCBsYWJlbCB3aXRoIHRoZSBsYWJlbCANCnJlY2VpdmVkIGZvciB0aGUgPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyBpbnRlci1BUyBMU1AgZnJvbSBBU0JSOS4gQWxzbywgQVNCUjcgDQp3 aWxsIGl0c2VsZiBhbGxvY2F0ZSBhIE5VTEwgbGFiZWwgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBp biB0aGUgUmVzdiBtZXNzYWdlIGZvciANCnRoZSBpbnRlci1BUyBURSBMU1AgYW5kIHNlbmRzIHRo ZSBSZXN2IG1lc3NhZ2UgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyB0byANCkFTQlI0LiI8L1NQQU4+ PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz05 MTEzNDIxMTgtMjEwNzIwMDQ+V2hhdCBvYmplY3RzIGluIHRoZSANClBhdGggb3IgUmVzdiBtZXNz YWdlcyBkb2VzIEFTQlI3IHVzZSB0byBhc3NvY2lhdGUgdGhlIGludGVyLUFTIExTUCB3aXRoIHRo ZSBMU1AgDQpzZWdtZW50PzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9OTExMzQyMTE4LTIxMDcyMDA0PjwvU1BBTj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9 OTExMzQyMTE4LTIxMDcyMDA0PlRoYW5rcyw8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTkxMTM0MjExOC0yMTA3MjAwND5BbGFu PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4g DQpjbGFzcz05MTEzNDIxMTgtMjEwNzIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JP RFk+PC9IVE1MPg0K ------_=_NextPart_001_01C46F64.718D10A5-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 20:23:48 +0000 Message-ID: <07e401c46f60$75d826a0$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Richard Rabbat" <rabbat@fla.fujitsu.com>, "Vishal Sharma \(E-mail 2\)" <v.sharma@ieee.org>, <thamada@fla.fujitsu.com> Cc: <ccamp@ops.ietf.org> Subject: draft-rabbat-ccamp-carrier-survey-00.txt Date: Wed, 21 Jul 2004 21:21:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Thanks for starting the ball rolling on this. It is tempting to start analysing the results, but probably too early. One SP responded that they are already using shared-mesh. It would be hugely interesting to know the experiences of this operator. Would they be prepared to stand up? If not, would they be prepared to filter their comments anonymously through the chair? I have some big and little issues with the draft. Big issues. A. I'm inclined to agree with Tom Petch. Surveys are, of course, very delicate things especially when they apply to future plans of competitive bodies, but it really would be useful to have some indication of the responses for each SP. I suggest you look at the old GMPLS implementation survey format. The draft consisted of a summarization (like what you have published) but also included all of the questionnaire responses to that we could see how the responses to each question were correlated. It is not necessary to force the identification of each responder, but you should allow them to be identified if they choose. In any case, it would be useful to understand where the individuals responding fit within their company organisations. Without casting any aspersions, there is a large difference between someone in the research department and someone in the operations department. B. I would like to see (as I'm sure you intend) a more open invitation to participate in the survey. Probably refine the survey, post it somewhere, notify the mailing list and through other channels. C. Although the abstract/introduction mentions optical networks, the survey does not appear to draw any differentiation between the various switching capabilities. I think it is fundamental to an understanding of what carriers are trying to achieve to know what type of network they are trying to build (PSC, TDM, WDM etc.). D. Questions 2 and 3 on the survey seem pretty important, but don't appear in section 5. E. Section 5.1 claims that the responses relate to GMPLS, but the question is about "an IP-based control plane such as GMPLS." G. Section 5.2 claims that the responses relate to using GMPLS to provide shared-mesh restoration, but the survey question does not mention GMPLS. H. Section 5.3 is a good example of why we need to provide the responses correlated by responder. For some responders the answers here may have prevented them from making plans to deploy, for others they plan to deploy despite their concerns. For others, they have no plans to deploy for other reasons, but have still voiced concerns. I. Section 5.4. It is not clear whether the final comment in this section is your interpretation, apple-pie, or a specific response to the survey. J. Section 5.5 claims that the responses pertain to traffic carried on the responder's network, but the question makes no reference to this and is general in nature. K. Why does question 9 lead the witness? In order to establish the true requirements we should not discuss specific solution models, but try to understand what the operational concerns are. Little issues. a. It might be nice if the draft file name gave a little more clue about the content of the survey. You might consider draft-rabbat-ccamp-gmpls-mesh-carrier-survey-00.txt b. Please try to avoid spurious characters in the text. c. Abstract says that a number of GMPLS routing and signaling standards have been completed. I think the RFCs are only at Proposed Standard at the moment. d. Don't think you need section 2 e. Glad that you have a one paragraph definition of "shared mesh restoration" in the survey. Probably good to copy it into the main draft. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 19:49:41 +0000 Message-ID: <07c901c46f5b$b43c8a30$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Richard Rabbat" <rabbat@fla.fujitsu.com> Cc: <ccamp@ops.ietf.org> Subject: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: Draft agenda for San Diego] Date: Wed, 21 Jul 2004 20:39:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Richard, > Sorry, I forgot to cc: the mailing list given the interest. >>Hi Adrian, >> >>We would like to get some 2 to 3 minutes to discuss our survey results under >>the P&R section and how they can be used to advance P&R. >>http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-00.txt >>We're getting some good feedback by email about it and would like to discuss >>the next steps and increase the participation of the carriers in the debate. You're not going to get any realistic discussion in 2 to 3 minutes. A better way to handle this, I think, is that the draft is mentioned from the chair (as shown in the draft agenda) and that discussions are taken to the list. Hopefully by doing this we can build on your work to produce a survey that helps us understand the deployment desires and motivations of GMPLS-using providers. Cheers, Adrian PS Feedback and thoughts on the draft to follow. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 17:13:27 +0000 From: "Richard Rabbat" <rabbat@fla.fujitsu.com> To: <ccamp@ops.ietf.org> Subject: FW: Draft agenda for San Diego Date: Wed, 21 Jul 2004 10:12:45 -0700 Message-ID: <002301c46f45$f0e4a780$453ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, I forgot to cc: the mailing list given the interest. Richard. -- Hi Adrian, We would like to get some 2 to 3 minutes to discuss our survey results = under the P&R section and how they can be used to advance P&R.=20 http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-00.= txt We're getting some good feedback by email about it and would like to = discuss the next steps and increase the participation of the carriers in the = debate. Thanks,=20 Richard. > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, July 21, 2004 9:09 AM > To: ccamp@ops.ietf.org > Subject: Draft agenda for San Diego >=20 >=20 > Hi, >=20 > Here is an early draft agenda for CCAMP in San Diego. >=20 > As usual there is a high volume of drafts that people want to > 'present'. Of necessity, therefore, some of you must be=20 > disappointed. The usual comments apply: >=20 > - The main place for presentation of your draft is the mailing list > - Discussion of your draft needs to be on the mailing list > (discussions at the meetings don't carry much weight) >=20 > In order to make sure that drafts that do not get explicit > slots on the agenda are not forgotten, the chairs will=20 > attempt to mention some of the key ones, give status, and=20 > encourage debate on the mailing list. >=20 > (The larger amounts of time dedicated to inter-domain is in > anticipation of a healthy degree of debate.) >=20 > Thanks, > Adrian >=20 > =3D=3D=3D >=20 > CCAMP 60 - San Diego - Draft Agenda > [running total 150 / 150] >=20 > Group Admin (Chairs) > Admin and agenda bash (5 mins) > Status of WG and drafts (5 mins) > =20 > http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-te-rou > ter-info-00.txt > =20 > http://www.ietf.org/internet-drafts/draft-vasseur-isis-te-caps-00.txt > =20 > http://www.ietf.org/internet-drafts/draft-vasseur-ospf-te-caps-00.txt > =20 > http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-loose- > path-reopt-02.txt > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ala > rm-spec-00.txt > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-02.txt > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-e > xclude-route-02.txt > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc- > mib-05.txt > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr > -mib-05.txt > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te- > mib-05.txt > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tunproto-00.txt >=20 > http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls- > rsvp-te-bundled-links-00.txt > =20 > http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-i > nterworking-03.txt >=20 > http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-misco > nnection-analysis-00.txt > =20 > http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier > -survey-00.txt >=20 > Milestones and objectives (5 mins) >=20 > ASON Requirements and Solutions > ASON Signaling and Routing Requirements and other cooked > drafts (Adrian) (2 mins) > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-aso > n-reqts-06.txt > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-aso > n-routing-reqts-04.txt > =20 > http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress- > control-02.txt >=20 > ASON Signaling Solutions (Dimitri Papadimitriou) (5 mins) > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsv > p-te-ason-01.txt >=20 > ASON Routing Solutions Design Team status (Dimitri > Papadimitriou) (10 mins) > - charter & team > - plans > - drafts >=20 > A Transport Network View of LMP (Don Fedyk) (5 minutes) > =20 > http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-tran > sport-lmp-02.txt > - why this draft? > - adopt as WG draft? >=20 > SG15 liaison (Wesam Alanqar 5 mins) >=20 > Protection and Restoration > Drafts in AD review (Adrian) (2 mins) > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rec > overy-analysis-02.txt > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rec > overy-functional-01.txt > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rec > overy-terminology-03.txt >=20 > End-to-end recovery (Dimitri Papadimitriou) (5 mins) >=20 > http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-rec > overy-e2e-signaling-02.txt > - ready for last call? >=20 > Segment Recovery (Lou Berger) (5 mins) > =20 > http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-s > egment-recovery-00.txt > - ready for last call? >=20 > Hello Protocol and Graceful Restart > Graceful restart (Lou Berger) (10 minutes) > =20 > http://www.ietf.org/internet-drafts/draft-aruns-ccamp-rsvp-res > tart-ext-01.txt > - good ideas? > - adopt as WG draft? > Node-id-based Hello (Zafar Ali) (5 minutes) > =20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node > -id-based-hello-00.txt > - implementation status > - ready for last call > Graceful restart (Zafar Ali / Anca Zamfir) (5 minutes) > =20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace > ful-shutdown-00.txt > - good ideas? > - adopt as WG draft? >=20 > Inter-Area/AS > Strategy (Kireeti) (10 minutes) > - definitions and overview > - simple requirements first > - protection and other diverse path requirements later > - PCE BOF >=20 > Inter-domain Framework (Adrian) (15 minutes) > =20 > http://www.ietf.org/internet-drafts/draft-farrel-ccamp-inter-d omain-framework-01.txt - generality of "domain" - separation of routing, path computation and signaling - no attention to diverse paths at this stage - WG adopt? Inter-domain RSVP-TE (Arthi Ayyangar) (15 minutes) =20 http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsv= p-t e-00.txt - Purpose of draft? - Main issues - WG adopt? Inter-domain TE LSP path computation methods (JP Vasseur) (15 minutes) =20 http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-inter-domain-path= -co mp-00.txt - Purpose of draft? - Main issues - Overlap with PCE BOF? - WG adopt? GMPLS Inter-AS requirements (Tomohiro Otani) (10 minutes) =20 http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-00= .tx t - Why a separate draft? - What are the main features? Summary of other work Layer 2 GMPLS (Dimitri Papadimitriou) (5 mins) =20 http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-= lsp -02.txt - what's it about? - adopt as WG draft? Layer 1 VPNs (Tomonori Takeda) (5 mins) - status and plans - still progressing "under the care of CCAMP" - mailing list = http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-01.txt =20 http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-00.t= xt =20 http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-= 05. txt =20 http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt= Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 16:16:33 +0000 Message-ID: <073101c46f3e$0f42d470$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Slides and hints for San Diego Date: Wed, 21 Jul 2004 17:15:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, 1. Slides must be with me by 6pm West Coast Saturday 31st July so they can go on the Web 2. You can change who speaks (I have picked random names from the authors). Please let me know. 3. Please use the hints in the agenda to suggest what you should cover. 4. DO NOT present your draft! 5. If you use all of your allotted time speaking, there will be no time for questions. A very fast speaker may manage one slide in two minutes. 6. If you want to solicit specific opinions or ideas, why not prime the audience with a few emails to the list? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 16:15:36 +0000 Message-ID: <072a01c46f3d$cf0ed340$45849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Draft agenda for San Diego Date: Wed, 21 Jul 2004 17:08:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Here is an early draft agenda for CCAMP in San Diego. As usual there is a high volume of drafts that people want to 'present'. Of necessity, therefore, some of you must be disappointed. The usual comments apply: - The main place for presentation of your draft is the mailing list - Discussion of your draft needs to be on the mailing list (discussions at the meetings don't carry much weight) In order to make sure that drafts that do not get explicit slots on the agenda are not forgotten, the chairs will attempt to mention some of the key ones, give status, and encourage debate on the mailing list. (The larger amounts of time dedicated to inter-domain is in anticipation of a healthy degree of debate.) Thanks, Adrian === CCAMP 60 - San Diego - Draft Agenda [running total 150 / 150] Group Admin (Chairs) Admin and agenda bash (5 mins) Status of WG and drafts (5 mins) http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-te-router-info-00.txt http://www.ietf.org/internet-drafts/draft-vasseur-isis-te-caps-00.txt http://www.ietf.org/internet-drafts/draft-vasseur-ospf-te-caps-00.txt http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-loose-path-reopt-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tunproto-00.txt http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-03.txt http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-misconnection-analysis-00.txt http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-00.txt Milestones and objectives (5 mins) ASON Requirements and Solutions ASON Signaling and Routing Requirements and other cooked drafts (Adrian) (2 mins) http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-02.txt ASON Signaling Solutions (Dimitri Papadimitriou) (5 mins) http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt ASON Routing Solutions Design Team status (Dimitri Papadimitriou) (10 mins) - charter & team - plans - drafts A Transport Network View of LMP (Don Fedyk) (5 minutes) http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-transport-lmp-02.txt - why this draft? - adopt as WG draft? SG15 liaison (Wesam Alanqar 5 mins) Protection and Restoration Drafts in AD review (Adrian) (2 mins) http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-01.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt End-to-end recovery (Dimitri Papadimitriou) (5 mins) http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt - ready for last call? Segment Recovery (Lou Berger) (5 mins) http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt - ready for last call? Hello Protocol and Graceful Restart Graceful restart (Lou Berger) (10 minutes) http://www.ietf.org/internet-drafts/draft-aruns-ccamp-rsvp-restart-ext-01.txt - good ideas? - adopt as WG draft? Node-id-based Hello (Zafar Ali) (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt - implementation status - ready for last call Graceful restart (Zafar Ali / Anca Zamfir) (5 minutes) http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-00.txt - good ideas? - adopt as WG draft? Inter-Area/AS Strategy (Kireeti) (10 minutes) - definitions and overview - simple requirements first - protection and other diverse path requirements later - PCE BOF Inter-domain Framework (Adrian) (15 minutes) http://www.ietf.org/internet-drafts/draft-farrel-ccamp-inter-domain-framework-01.txt - generality of "domain" - separation of routing, path computation and signaling - no attention to diverse paths at this stage - WG adopt? Inter-domain RSVP-TE (Arthi Ayyangar) (15 minutes) http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt - Purpose of draft? - Main issues - WG adopt? Inter-domain TE LSP path computation methods (JP Vasseur) (15 minutes) http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-inter-domain-path-comp-00.txt - Purpose of draft? - Main issues - Overlap with PCE BOF? - WG adopt? GMPLS Inter-AS requirements (Tomohiro Otani) (10 minutes) http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-00.txt - Why a separate draft? - What are the main features? Summary of other work Layer 2 GMPLS (Dimitri Papadimitriou) (5 mins) http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-lsp-02.txt - what's it about? - adopt as WG draft? Layer 1 VPNs (Tomonori Takeda) (5 mins) - status and plans - still progressing "under the care of CCAMP" - mailing list http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-01.txt http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-00.txt http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 15:05:55 +0000 Date: Wed, 21 Jul 2004 11:04:18 -0400 (EDT) From: Arun Satyanarayana <aruns@movaz.com> Reply-To: <aruns@movaz.com> To: <adrian@olddog.co.uk>, <kireeti@juniper.net> Cc: <ccamp@ops.ietf.org>, Lou Berger <lberger@movaz.com>, <Dimitri.Papadimitriou@alcatel.be>, Reshad Rahman <rrahman@cisco.com>, Anca Zamfir <ancaz@cisco.com>, Junaid Israr <jisrar@cisco.com>, Arun Satyanarayan <aruns@movaz.com> Subject: Time slot requet: draft-aruns-ccamp-rsvp-restart-ext-01 Message-ID: <Pine.LNX.4.33.0407211052100.20427-100000@dcserver.movaz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Adrian, Kireeti, The updated I-D is the merge of draft-aruns-ccamp-rsvp-restart-ext-00 and draft-rahman-rsvp-restart-extensions-00. It also includes a new mechanism to handle scalability concerns raised in prior discussions on the list. Can we get a slot as part of the "Hello extensions" item in the agenda, during the San Diego meeting please? Thanks much, Arun (and co-authors) ============================================================ From: internet-drafts@ietf.org <internet-drafts@ietf.org> Date: Tue, 20 Jul 2004 15:53:11 -0400 Subject: I-D ACTION:draft-aruns-ccamp-rsvp-restart-ext-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to GMPLS RSVP Graceful Restart Author(s) : A. Satyanarayana, R. Rahman Filename : draft-aruns-ccamp-rsvp-restart-ext-01.txt Pages : 20 Date : 2004-7-20 This document describes extensions to the RSVP Graceful Restart mechanisms defined in [RFC3473]. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in [RFC3209], and extensions for state recovery on nodal faults defined in [RFC3473]. With the presented extensions the restarting node can recover all previously transmitted Path state including the ERO and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in [RFC2961], to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSP's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aruns-ccamp-rsvp-restart-ext-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-aruns-ccamp-rsvp-restart-ext-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-aruns-ccamp-rsvp-restart-ext-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 10:16:05 +0000 Message-ID: <40FE4212.4070609@lab.ntt.co.jp> Date: Wed, 21 Jul 2004 19:14:42 +0900 From: Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp> Organization: NTT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Misconnection-analysis ID was posted. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, all Please notice that the draft on misconnection analysis, which was initially raised in the P&R context, was posted. In this draft, we present the three cases where misconnections occur: (1) preemption of extra LSP in shared mesh restoration, (2) activation high-priority over low-priority LSPs, and (3) failure of node. Common cause of misconnection is analyzed. Possible solutions are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-misconnection-analysis-00.txt Comments are appreciated. Thanks. -- Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 4549 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jul 2004 07:32:16 +0000 Message-Id: <6.0.0.20.2.20040721162655.0579c928@mail.onw.kddlabs.co.jp> Date: Wed, 21 Jul 2004 16:29:45 +0900 To: ccamp@ops.ietf.org From: Tomohiro Otani <otani@kddilabs.jp> Subject: draft-otani-ccamp-interas-gmpls-te-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Hi everyone, We submitted a draft describing the GMPLS inter AS TE parameters requirement as follows. http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-00.txt We hope to receive lots of comments and feedback via e-mail as well as in San Diego meeting. With best regards, tomo ------------------------------------ Tomohiro Otani KDDI R&D Laboratories, Inc. Optical network architecture lab. 2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan TEL: +81-49-278-7357 FAX: +81-49-278-7811 E-mail: otani@kddilabs.jp ------------------------------------ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Jul 2004 18:24:08 +0000 Message-ID: <000201c46e86$0e38e820$0301a8c0@tom3> Reply-To: "Tom Petch" <nwnetworks@dial.pipex.com> From: "Tom Petch" <nwnetworks@dial.pipex.com> To: "Richard Rabbat" <rabbat@fla.fujitsu.com>, <ccamp@ops.ietf.org> Subject: Re: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies Date: Mon, 19 Jul 2004 22:09:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I like it, find it useful but have a nagging doubt about how much I can trust the information therein. As is often stated, in the IETF we participate as individuals, not representing our organisations; but for this I-D to carry weight, it matters that the views in it are made by people with the authority to represent their organisations. In implementation reports, as in the advancement of a standard, I may see the name and details of whoever made the report on behalf of the organisation, which always reassures me as to the standing of the report. Could we have something similar here? Tom Petch -----Original Message----- From: Richard Rabbat <rabbat@fla.fujitsu.com> To: ccamp@ops.ietf.org <ccamp@ops.ietf.org> Date: 14 July 2004 19:54 Subject: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies Dear all, Please take a look at our new draft: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies available at: <http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-00.t x t> http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-00.tx t This draft presents the results of a survey about carrier interest in shared mesh restoration, their requirements and their concerns. We have tried to be as encompassing as possible going to carriers in Europe, Asia and North America. We are hoping to include input from more carriers and would like to ask the community in general and the carriers in particular to let us know what new information they would like to see surveyed in the next update. Basically, we have the following questions: - Are you interested in GMPLS-based solutions to the requirements? - Can you suggest additional contacts to enable us to reach more carriers and get their feedback? - Have we overlooked any aspect of restoration for shared mesh? - What additional questions would you like to see? Some of the surveyed carriers have already provided inputs on this and we'd like to ask others to give us their comments as well. Thanks, Richard. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Jul 2004 04:20:23 +0000 Date: Tue, 20 Jul 2004 13:18:20 +0900 From: Eiji Oki <oki.eiji@lab.ntt.co.jp> To: <ccamp@ops.ietf.org> Subject: draft-oki-pce-gmpls-req-00.txt and draft-oki-ccamp-gtep-00.txt Message-Id: <20040720131400.0FED.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi all, I submitted two drafts on Path Computation Elements (PCE), which I expect to discuss in the meeting of PCE BOF. 1. http://www.ietf.org/internet-drafts/draft-oki-pce-gmpls-req-00.txt Title: Requirements for Path Computation Element in GMPLS and IP/MPLS Networks 2. http://www.ietf.org/internet-drafts/draft-oki-ccamp-gtep-00.txt Title: Generalized Traffic Engineering Protocol The first draft presents requirements on PCE in GMPLS networks. The second one describes some related protocols. These drafts are related to CCAMP, as they discuss PCE issues in GMPLS networks. Any comments and suggestions are highly appreciated. Thank you. Eiji -- Eiji Oki NTT Network Service Systems Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Tel: +81-422-59-3441 Fax: +81-422-59-4549 E-mail: oki.eiji@lab.ntt.co.jp Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Jul 2004 21:57:06 +0000 Message-Id: <4.3.2.7.2.20040719174953.064dd500@wells.cisco.com> Date: Mon, 19 Jul 2004 17:55:30 -0400 To: ccamp@ops.ietf.org From: Jean Philippe Vasseur <jvasseur@cisco.com> Subject: Inter-domain work Cc: adrian@olddog.co.uk, Arthi Ayyangar <arthi@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Just to provide a quick update on where we stand. As agreed during the last IETF, we split the previous inter-area/AS TE draft (draft-vasseur-inter-area-as-te-00.txt) in several individual drafts in addition to some existing drafts. Here is an update on the Inter-domain (area/AS) work: New revision of loose path reoptimization draft has been posted: draft-vasseur-ccamp-loose-path-reopt-02.txt "A Framework for Inter-Domain MPLS Traffic Engineering" - draft-farrel-ccamp-inter-domain-framework-01.txt "Inter-domain Traffic Engineering LSP path computation methods" - draft-vasseur-ccamp-inter-domain-path-comp-00.txt "Inter domain MPLS Traffic Engineering - RSVP-TE extensions" - draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt Furthermore, there will be an additional draft related to the Applicability Statement for IETF-62. Of course, any comment is warmly welcome. JP. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Jul 2004 20:45:20 +0000 Message-ID: <044a01c46dd1$22368f90$ce849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Re: I-D ACTION:draft-ietf-ccamp-crankback-02.txt Date: Mon, 19 Jul 2004 21:43:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, FYI, there are no changes in substance in this draft. We're just keeping it alive while we wait for the inter-domain work to catch up. Adrian ----- Original Message ----- From: <Internet-Drafts@ietf.org> To: <i-d-announce@ietf.org> Cc: <ccamp@ops.ietf.org> Sent: Monday, July 19, 2004 8:20 PM Subject: I-D ACTION:draft-ietf-ccamp-crankback-02.txt > 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 : Crankback Signaling Extensions for MPLS Signaling > Author(s) : A. Farrel, et al. > Filename : draft-ietf-ccamp-crankback-02.txt > Pages : 30 > Date : 2004-7-19 > > In a distributed, constraint-based routing environment, the > information used to compute a path may be out of date. This means > that Multiprotocol Label Switching (MPLS) label switched path (LSP) > setup requests may be blocked by links or nodes without sufficient > resources. Crankback is a scheme whereby setup failure information is > returned from the point of failure to allow new setup attempts to be > made avoiding the blocked resources. Crankback can also be applied to > LSP restoration to indicate the location of the failed link or node. > > This document specifies crankback signaling extensions for use in > MPLS signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to > RSVP for LSP Tunnels', RFC3209, so that the LSP setup request can be > retried on an alternate path that detours around blocked links or > nodes. This offers significant improvements in the successful setup > and recovery ratios for LSPs, especially in situations where a large > number of setup requests are triggered at the same time. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-crankback-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-crankback-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. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Jul 2004 19:22:07 +0000 Message-Id: <200407191920.PAA17979@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-crankback-02.txt Date: Mon, 19 Jul 2004 15:20:11 -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 : Crankback Signaling Extensions for MPLS Signaling Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-crankback-02.txt Pages : 30 Date : 2004-7-19 In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) label switched path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP restoration to indicate the location of the failed link or node. This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to RSVP for LSP Tunnels', RFC3209, so that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-crankback-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-crankback-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: <2004-7-19152140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-crankback-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-crankback-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152140.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Jul 2004 06:50:04 +0000 Date: Sat, 19 Jul 2003 14:47:17 +0800 To: "Ccamp" <ccamp@ops.ietf.org> From: "Timhall" <timhall@dataconnection.com> Subject: Re: Message-ID: <muwjhldxzfofjhlthna@ops.ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------azfzlfewbnqxdnnxyhng" ----------azfzlfewbnqxdnnxyhng Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) Found virus WORM_BAGLE.AG in file Fish.cpl The file Fish.cpl can not be moved because /var/quarantine/virus/virSENwaIWfZ: No space left on device. This is a machine-generated message, please do not reply via e-mail. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770. --------------------------------------------------------- ----------azfzlfewbnqxdnnxyhng Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <html><body> The snake<br><br> <br> </body></html> ----------azfzlfewbnqxdnnxyhng Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) Fish.cpl is removed from here because it contains a virus. --------------------------------------------------------- ----------azfzlfewbnqxdnnxyhng-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Jul 2004 06:18:25 +0000 Date: Sat, 19 Jul 2003 14:15:00 +0800 To: "Ccamp" <ccamp@ops.ietf.org> From: "Timhall" <timhall@dataconnection.com> Subject: Re: Message-ID: <mijnrjgtaqljieacalm@ops.ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------nyenpebczdmucuhjemig" ----------nyenpebczdmucuhjemig Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <html><body> Screen<br><br> <br>Password: <img src="cid:owuriuydeq.gif"><br> <br> </body></html> ----------nyenpebczdmucuhjemig Content-Type: image/gif; name="owuriuydeq.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="owuriuydeq.gif" Content-ID: <owuriuydeq.gif> R0lGODlhOwAPAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A /wD//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAz mQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDM mQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMz mTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPM mTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYz mWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbM mWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkz mZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnM mZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswz mcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszM mczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8z mf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/M mf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAAA7AA8AAAj/AP8JHEiwoMGD CBMqXMiwocOHECNKnDhQmxBJ/4IIEaIxSMaNQZB4/KctkhBbA7eZjEQRoT9FQrQVhISS4CJY JGNuC0JNILUjOxe1NMhICJJtBG0JKUhtZC0h/v4JYUkwyMihArWxWXT1306cBE8K3Dh2aUqx WP/li8mRoMVqBJvKlHpEoMaBXGulFaiIpRC9A191/WdyICyo2/66jZn26TaLYP/5ExJZsuKB jNhYrDkwSJu0bTZynCrQVpC5Ag+jHmgaaUUhkPYKlNT1lRDXAmt1XbR0EcZ/T/8p5ZyWa1Wz A8lWbBOkcqQgilbLnj5dI0irIEV3xM7d+mjuyhUGAQQAOw== ----------nyenpebczdmucuhjemig Content-Type: application/octet-stream; name="Secret.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Secret.zip" ----------nyenpebczdmucuhjemig-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 18 Jul 2004 23:17:59 +0000 Reply-To: <v.sharma@ieee.org> From: "Vishal Sharma" <v.sharma@ieee.org> To: "CCAMP" <ccamp@ops.ietf.org> Cc: "Monique J. Morrow" <mmorrow@cisco.com>, "Thomas Nadeau" <tnadeau@cisco.com>, "Loa Andersson" <loa@pi.se> Subject: "Inter-Provider Service Quality on the Internet": IEEE Comm. Mag. CFP Date: Sun, 18 Jul 2004 16:15:56 -0700 Message-ID: <MMECLKMDFPCEJFECIBCMIELAEKAA.v.sharma@ieee.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, The IEEE Communications Magazine has just approved the publication of a Feature Topic issue on "Challenges in Enabling Inter-Provider Service Quality on the Internet." The CFP is attached below. We invite those working in this area to consider sending in their contributions. If you intend to submit a paper for this special issue, please do drop one of the Guest Editors a note, so that we can plan the issue. We look forward to your participation! Thanks, -Vishal **************************************************************** Vishal Sharma, Ph.D. Metanoia, Inc. Email: v.sharma@ieee.org. http://www.metanoia-inc.com **************************************************************** ========================================================================= CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "Challenges in Enabling Inter-Provider Service Quality on the Internet" ************************************************************************* As carriers and service providers build multi-services networks based on IP/MPLS- enabled infrastructures that are able to meet evermore stringent service level agreements (SLAs) and quality-of-service (QoS) requirements, it becomes a key issue to extend the ability to deliver these services across carrier and service provider domain boundaries, while at the same time preserving the same SLAs and QoS assurances as those provided within a given provider's network. The advent of new end-user applications, as well as new services based on MPLS technology, such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs), also means the emergence of added service quality requirements from operators deploying and interoperating these networks and the end-users themselves. As a result, providers and vendors require efficient means to enable inter-provider service quality, which comprises of several key elements including quality of service, class of service, security, OAM, and restoration and repair. This will is lead to the emergence of improved or novel tools and techniques to address these aspects, with the goal of guaranteeing service quality end-to-end, improving security and billing/accounting, and reducing operating costs. Standards organizations such as the IETF and the ITU are taking on significant work in this area, and various aspects of this subject are also being investigated by bodies such as the OIF, the MSF, the MPLS/Frame Relay Alliance, the IEEE, and the Metro Ethernet Forum, and are the themes for numerous upcoming conferences. This feature topic issue of the IEEE Communications Magazine has a multi-pronged focus on the delivery of inter-provider service quality: * Highlight operator and end-user concerns and requirements. * Feature current and/or planned deployment experiences. * Survey modern research and engineering developments. * Spotlight contemporary standards activity. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but certainly not limited to) the following topics: * Carrier requirements for efficient inter-provider service quality: Current operational needs, bottlenecks, future demands * Deployment experience with inter-provider service quality on IP/MPLS- based networks: comparative analysis, case studies * QoS management in an inter-provider environment: interconnection architectures using MPLS, Diffserv, QoS performance, path characterization, routing policies * Service assurance in inter-provider infrastructures: End-to-end SLA management, service billing/reporting, admission control * Failure and restoration requirements/challenges in inter-provider contexts * Interoperability and inter-working of diverse equipment types and technologies (ATM, FR, Ethernet) * Current engineering and research developments: E.g. Passive and active performance measurement and monitoring, TE, modelling and simulation * Standards activities and initiatives: new services and network architectures On-line CFP with submission instructions can be found at: http://www.metanoia-inc.com/IEEECommMag_InterProviderQoS_CFP.htm Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided there is consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at http://www.comsoc.org/pubs/commag/sub_guidelines.html. ** Please submit no later than 30 October 2004.** Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Manuscript Due: 30 October 2004 Acceptance Notification: 15 January 2004 Final Manuscript Due: 28 February 2005 Publication Date: June 2005 Guest Editors Monique J. Morrow, Cisco Systems, (mmorrow@cisco.com) Vishal Sharma, Metanoia, Inc. (v.sharma@ieee.org) Thomas D.Nadeau, Cisco Systems (tnadeau@cisco.com) Loa Andersson, Acreo (loa@pi.se) Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 18 Jul 2004 20:43:47 +0000 From: "Alessio D'Achille" <alessiored@fastwebnet.it> To: <adrian@olddog.co.uk>, <kireeti@juniper.net> Cc: "Vishal Sharma" <v.sharma@ieee.org>, "Ugo Monaco" <monaco@infocom.uniroma1.it>, "'Fabio Ricciato'" <ricciato@coritel.it>, "Marco Listanti" <marco@infocom.uniroma1.it>, <ccamp@ops.ietf.org> Subject: slot request Date: Sun, 18 Jul 2004 22:45:28 +0200 Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAACTxyMXRGGEW0D3jPP4Cu9sKAAAAQAAAAhuepHqBPiEWKgORd2udJBgEAAAAA@fastwebnet.it> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C46D18.ED053280" This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C46D18.ED053280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Kireeti and Adrian, Since we recently submitted a new version of our draft draft-dachille-inter-area-path-protection-01 (we called this new version draft-dachille-diverse-inter-region-path-setup-00) before the dead-line for the 60th IETF, we kindly ask for a 15-minute slot in the ccamp agenda, within the discussion on inter-area/TE. Thank you in advance for your attention, Best regards Alessio D'Achille ------=_NextPart_000_0004_01C46D18.ED053280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DProgId content=3DWord.Document> <meta name=3DGenerator content=3D"Microsoft Word 10"> <meta name=3DOriginator content=3D"Microsoft Word 10"> <link rel=3DFile-List href=3D"cid:filelist.xml@01C46D18.EC442C70"> <!--[if gte mso 9]><xml> <o:OfficeDocumentSettings> <o:DoNotRelyOnCSS/> </o:OfficeDocumentSettings> </xml><![endif]--><!--[if gte mso 9]><xml> <w:WordDocument> <w:SpellingState>Clean</w:SpellingState> <w:GrammarState>Clean</w:GrammarState> <w:DocumentKind>DocumentEmail</w:DocumentKind> <w:HyphenationZone>14</w:HyphenationZone> <w:EnvelopeVis/> <w:Compatibility> <w:BreakWrappedTables/> <w:SnapToGridInCell/> <w:WrapTextWithPunct/> <w:UseAsianBreakRules/> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--> <style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} h2 {mso-style-next:Normale; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:2.0cm; margin-bottom:.0001pt; text-align:justify; text-indent:-39.7pt; mso-pagination:widow-orphan; page-break-after:avoid; mso-outline-level:2; mso-list:l0 level2 lfo1; tab-stops:list 2.0cm; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Arial; mso-bidi-font-family:"Times New Roman"; mso-bidi-font-weight:normal; text-decoration:underline; text-underline:single;} h3 {mso-style-next:Normale; margin-top:12.0pt; margin-right:0cm; margin-bottom:3.0pt; margin-left:25.2pt; text-indent:-25.2pt; mso-pagination:widow-orphan; page-break-after:avoid; mso-outline-level:3; mso-list:l1 level3 lfo3; tab-stops:list 36.0pt; font-size:12.0pt; mso-bidi-font-size:13.0pt; font-family:Arial; mso-ansi-language:EN-GB;} a:link, span.MsoHyperlink {color:blue; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline; text-underline:single;} span.StileMessaggioDiPostaElettronica17 {mso-style-type:personal-compose; mso-style-noshow:yes; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Arial; mso-ascii-font-family:Arial; mso-hansi-font-family:Arial; mso-bidi-font-family:Arial; color:windowtext;} span.SpellE {mso-style-name:""; mso-spl-e:yes;} span.GramE {mso-style-name:""; mso-gram-e:yes;} @page Section1 {size:595.3pt 841.9pt; margin:70.85pt 2.0cm 2.0cm 2.0cm; mso-header-margin:35.4pt; mso-footer-margin:35.4pt; mso-paper-source:0;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:671226919; mso-list-template-ids:1145476774;} @list l0:level1 {mso-level-number-format:none; mso-level-text:"3\."; mso-level-tab-stop:18.0pt; mso-level-number-position:left; margin-left:18.0pt; text-indent:-18.0pt;} @list l0:level2 {mso-level-number-format:none; mso-level-style-link:"Titolo 2"; mso-level-text:"3\.1"; mso-level-tab-stop:2.0cm; mso-level-number-position:left; margin-left:2.0cm; text-indent:-39.7pt;} @list l0:level3 {mso-level-number-format:none; mso-level-text:"3\.2"; mso-level-tab-stop:61.2pt; mso-level-number-position:left; margin-left:61.2pt; text-indent:-25.2pt;} @list l0:level4 {mso-level-number-format:none; mso-level-text:"3\.2\.1"; mso-level-tab-stop:86.4pt; mso-level-number-position:left; margin-left:86.4pt; text-indent:-32.4pt;} @list l0:level5 {mso-level-number-format:none; mso-level-text:"5\.3"; mso-level-tab-stop:111.6pt; mso-level-number-position:left; margin-left:111.6pt; text-indent:-39.6pt;} @list l0:level6 {mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\."; mso-level-tab-stop:162.0pt; mso-level-number-position:left; margin-left:136.8pt; text-indent:-46.8pt;} @list l0:level7 {mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\."; mso-level-tab-stop:180.0pt; mso-level-number-position:left; margin-left:162.0pt; text-indent:-54.0pt;} @list l0:level8 {mso-level-number-format:none; mso-level-text:"5\.2"; mso-level-tab-stop:187.2pt; mso-level-number-position:left; margin-left:187.2pt; text-indent:-61.2pt;} @list l0:level9 {mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\."; mso-level-tab-stop:252.0pt; mso-level-number-position:left; margin-left:216.0pt; text-indent:-72.0pt;} @list l1 {mso-list-id:1583031056; mso-list-template-ids:1103390454;} @list l1:level1 {mso-level-start-at:2; mso-level-number-format:none; mso-level-text:"1\.2\.1"; mso-level-tab-stop:-18.0pt; mso-level-number-position:left; margin-left:-18.0pt; text-indent:-18.0pt;} @list l1:level2 {mso-level-start-at:2; mso-level-number-format:none; mso-level-text:"1\.2\.2"; mso-level-tab-stop:3.6pt; mso-level-number-position:left; margin-left:3.6pt; text-indent:-21.6pt;} @list l1:level3 {mso-level-number-format:none; mso-level-reset-level:level1; mso-level-style-link:"Titolo 3"; mso-level-text:"1\.3\.1"; mso-level-tab-stop:36.0pt; mso-level-number-position:left; margin-left:25.2pt; text-indent:-25.2pt;} @list l1:level4 {mso-level-number-format:none; mso-level-text:"1\.3\.2"; mso-level-tab-stop:72.0pt; mso-level-number-position:left; margin-left:50.4pt; text-indent:-32.4pt;} @list l1:level5 {mso-level-number-format:none; mso-level-text:"1\.3\.3"; mso-level-tab-stop:90.0pt; mso-level-number-position:left; margin-left:75.6pt; text-indent:-39.6pt;} @list l1:level6 {mso-level-number-format:none; mso-level-text:"1\.3\.4"; mso-level-tab-stop:126.0pt; mso-level-number-position:left; margin-left:100.8pt; text-indent:-46.8pt;} @list l1:level7 {mso-level-number-format:none; mso-level-text:"1\.4\.1"; mso-level-tab-stop:144.0pt; mso-level-number-position:left; margin-left:126.0pt; text-indent:-54.0pt;} @list l1:level8 {mso-level-number-format:none; mso-level-text:"1\.4\.2"; mso-level-tab-stop:180.0pt; mso-level-number-position:left; margin-left:151.2pt; text-indent:-61.2pt;} @list l1:level9 {mso-level-text:"%9%11\.4\.1"; mso-level-tab-stop:216.0pt; mso-level-number-position:left; margin-left:180.0pt; text-indent:-72.0pt;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} --> </style> <!--[if gte mso 10]> <style> /* Style Definitions */=20 table.MsoNormalTable {mso-style-name:"Tabella normale"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman";} </style> <![endif]--> </head> <body lang=3DIT link=3Dblue vlink=3Dpurple = style=3D'tab-interval:35.4pt'> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Hi <span class=3DSpellE>Kireeti</span> and <span = class=3DSpellE>Adrian</span>,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><span class=3DSpellE><span class=3DGramE><font = size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial'>Since</span></font></span></= span><span class=3DGramE><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family: Arial'> <span class=3DSpellE>we</span> <span = class=3DSpellE>recently</span> <span class=3DSpellE>submitted</span> a new <span = class=3DSpellE>version</span> of <span class=3DSpellE>our</span> <span class=3DSpellE>draft</span> draft-dachille-inter-area-path-protection-01 (<span = class=3DSpellE>we</span> <span class=3DSpellE>called</span> <span class=3DSpellE>this</span> new <span class=3DSpellE>version</span> draft-dachil</span></font></span><font = size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial'>le-diverse-inter-region-path= -setup-00) <span class=3DSpellE>before</span> the <span = class=3DSpellE>dead-line</span> <span class=3DSpellE>for</span> the 60th IETF, <span class=3DSpellE>we</span> = <span class=3DSpellE>kindly</span> <span class=3DSpellE>ask</span> <span = class=3DSpellE>for</span> a 15-minute slot in the <span = class=3DSpellE>ccamp</span> agenda, <span class=3DSpellE>within</span> the <span = class=3DSpellE>discussion</span> on inter-area/TE. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><span class=3DSpellE><font size=3D2 = face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>Thank</span></font></span><f= ont size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial'> <span class=3DSpellE>you</span> in <span class=3DSpellE>advance</span> <span class=3DSpellE>for</span> <span class=3DSpellE>your</span> <span = class=3DSpellE>attention</span>,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Best <span = class=3DSpellE>regards</span><o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Alessio D'Achille</span></font><o:p></o:p></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> </div> </body> </html> ------=_NextPart_000_0004_01C46D18.ED053280-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 18 Jul 2004 20:42:35 +0000 From: "Alessio D'Achille" <alessiored@fastwebnet.it> To: <ccamp@ops.ietf.org> Cc: "'Vishal Sharma'" <v.sharma@ieee.org>, "'Ugo Monaco'" <monaco@infocom.uniroma1.it>, "'Fabio Ricciato'" <ricciato@coritel.it>, "Marco Listanti" <marco@infocom.uniroma1.it> Subject: draft-dachille-diverse-inter-region-path-setup-00 Date: Sun, 18 Jul 2004 22:41:32 +0200 Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAACTxyMXRGGEW0D3jPP4Cu9sKAAAAQAAAAkHTJujgg6kyYNpUfP2tFXAEAAAAA@fastwebnet.it> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C46D18.6042A6C0" This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C46D18.6042A6C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, A revision of our draft draft-dachille-inter-area-path-protection-01 discussed at Seoul is now available in the IETF repository. We called this new version "draft-dachille-diverse-inter-region-path-setup-00" <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region- path-setup-00.txt . It obsoletes draft-dachille-inter-area-path-protection-01. <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> The main changes are the following: <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> 1. it focuses on inter-region path computation, not only for protection purposes; <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> Since our draft in fact addressed the general problem of diverse path computation, and we <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> received several comments about focusing on the general problem, the <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> new version focuses on inter-region path computation, and not just path protection. <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> 2. it incorporates major comments from Seoul IETF and subsequent CCAMP ML discussion <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> as usual, every comment and feedback will be welcome. <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> Best Regards <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> Alessio D'Achille <http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region -path-setup-00.txt> ------=_NextPart_000_0000_01C46D18.6042A6C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DProgId content=3DWord.Document> <meta name=3DGenerator content=3D"Microsoft Word 10"> <meta name=3DOriginator content=3D"Microsoft Word 10"> <link rel=3DFile-List href=3D"cid:filelist.xml@01C46D18.5F590A10"> <!--[if gte mso 9]><xml> <o:OfficeDocumentSettings> <o:DoNotRelyOnCSS/> </o:OfficeDocumentSettings> </xml><![endif]--><!--[if gte mso 9]><xml> <w:WordDocument> <w:SpellingState>Clean</w:SpellingState> <w:GrammarState>Clean</w:GrammarState> <w:DocumentKind>DocumentEmail</w:DocumentKind> <w:HyphenationZone>14</w:HyphenationZone> <w:EnvelopeVis/> <w:Compatibility> <w:BreakWrappedTables/> <w:SnapToGridInCell/> <w:WrapTextWithPunct/> <w:UseAsianBreakRules/> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--> <style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} h2 {mso-style-next:Normale; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:2.0cm; margin-bottom:.0001pt; text-align:justify; text-indent:-39.7pt; mso-pagination:widow-orphan; page-break-after:avoid; mso-outline-level:2; mso-list:l0 level2 lfo1; tab-stops:list 2.0cm; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Arial; mso-bidi-font-family:"Times New Roman"; mso-bidi-font-weight:normal; text-decoration:underline; text-underline:single;} h3 {mso-style-next:Normale; margin-top:12.0pt; margin-right:0cm; margin-bottom:3.0pt; margin-left:25.2pt; text-indent:-25.2pt; mso-pagination:widow-orphan; page-break-after:avoid; mso-outline-level:3; mso-list:l1 level3 lfo3; tab-stops:list 36.0pt; font-size:12.0pt; mso-bidi-font-size:13.0pt; font-family:Arial; mso-ansi-language:EN-GB;} a:link, span.MsoHyperlink {color:blue; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline; text-underline:single;} span.StileMessaggioDiPostaElettronica17 {mso-style-type:personal-compose; mso-style-noshow:yes; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Arial; mso-ascii-font-family:Arial; mso-hansi-font-family:Arial; mso-bidi-font-family:Arial; color:windowtext;} span.SpellE {mso-style-name:""; mso-spl-e:yes;} span.GramE {mso-style-name:""; mso-gram-e:yes;} @page Section1 {size:595.3pt 841.9pt; margin:70.85pt 2.0cm 2.0cm 2.0cm; mso-header-margin:35.4pt; mso-footer-margin:35.4pt; mso-paper-source:0;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:671226919; mso-list-template-ids:1145476774;} @list l0:level1 {mso-level-number-format:none; mso-level-text:"3\."; mso-level-tab-stop:18.0pt; mso-level-number-position:left; margin-left:18.0pt; text-indent:-18.0pt;} @list l0:level2 {mso-level-number-format:none; mso-level-style-link:"Titolo 2"; mso-level-text:"3\.1"; mso-level-tab-stop:2.0cm; mso-level-number-position:left; margin-left:2.0cm; text-indent:-39.7pt;} @list l0:level3 {mso-level-number-format:none; mso-level-text:"3\.2"; mso-level-tab-stop:61.2pt; mso-level-number-position:left; margin-left:61.2pt; text-indent:-25.2pt;} @list l0:level4 {mso-level-number-format:none; mso-level-text:"3\.2\.1"; mso-level-tab-stop:86.4pt; mso-level-number-position:left; margin-left:86.4pt; text-indent:-32.4pt;} @list l0:level5 {mso-level-number-format:none; mso-level-text:"5\.3"; mso-level-tab-stop:111.6pt; mso-level-number-position:left; margin-left:111.6pt; text-indent:-39.6pt;} @list l0:level6 {mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\."; mso-level-tab-stop:162.0pt; mso-level-number-position:left; margin-left:136.8pt; text-indent:-46.8pt;} @list l0:level7 {mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\."; mso-level-tab-stop:180.0pt; mso-level-number-position:left; margin-left:162.0pt; text-indent:-54.0pt;} @list l0:level8 {mso-level-number-format:none; mso-level-text:"5\.2"; mso-level-tab-stop:187.2pt; mso-level-number-position:left; margin-left:187.2pt; text-indent:-61.2pt;} @list l0:level9 {mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\."; mso-level-tab-stop:252.0pt; mso-level-number-position:left; margin-left:216.0pt; text-indent:-72.0pt;} @list l1 {mso-list-id:1583031056; mso-list-template-ids:1103390454;} @list l1:level1 {mso-level-start-at:2; mso-level-number-format:none; mso-level-text:"1\.2\.1"; mso-level-tab-stop:-18.0pt; mso-level-number-position:left; margin-left:-18.0pt; text-indent:-18.0pt;} @list l1:level2 {mso-level-start-at:2; mso-level-number-format:none; mso-level-text:"1\.2\.2"; mso-level-tab-stop:3.6pt; mso-level-number-position:left; margin-left:3.6pt; text-indent:-21.6pt;} @list l1:level3 {mso-level-number-format:none; mso-level-reset-level:level1; mso-level-style-link:"Titolo 3"; mso-level-text:"1\.3\.1"; mso-level-tab-stop:36.0pt; mso-level-number-position:left; margin-left:25.2pt; text-indent:-25.2pt;} @list l1:level4 {mso-level-number-format:none; mso-level-text:"1\.3\.2"; mso-level-tab-stop:72.0pt; mso-level-number-position:left; margin-left:50.4pt; text-indent:-32.4pt;} @list l1:level5 {mso-level-number-format:none; mso-level-text:"1\.3\.3"; mso-level-tab-stop:90.0pt; mso-level-number-position:left; margin-left:75.6pt; text-indent:-39.6pt;} @list l1:level6 {mso-level-number-format:none; mso-level-text:"1\.3\.4"; mso-level-tab-stop:126.0pt; mso-level-number-position:left; margin-left:100.8pt; text-indent:-46.8pt;} @list l1:level7 {mso-level-number-format:none; mso-level-text:"1\.4\.1"; mso-level-tab-stop:144.0pt; mso-level-number-position:left; margin-left:126.0pt; text-indent:-54.0pt;} @list l1:level8 {mso-level-number-format:none; mso-level-text:"1\.4\.2"; mso-level-tab-stop:180.0pt; mso-level-number-position:left; margin-left:151.2pt; text-indent:-61.2pt;} @list l1:level9 {mso-level-text:"%9%11\.4\.1"; mso-level-tab-stop:216.0pt; mso-level-number-position:left; margin-left:180.0pt; text-indent:-72.0pt;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} --> </style> <!--[if gte mso 10]> <style> /* Style Definitions */=20 table.MsoNormalTable {mso-style-name:"Tabella normale"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman";} </style> <![endif]--> </head> <body lang=3DIT link=3Dblue vlink=3Dpurple = style=3D'tab-interval:35.4pt'> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Hi <span class=3DSpellE>all</span>, = <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size: 12.0pt'> <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>A <span class=3DSpellE>revision</span> of <span = class=3DSpellE>our</span> <span class=3DSpellE>draft</span> draft-dachille-inter-area-path-pro= tection-01 <span class=3DSpellE>discussed</span> at <span = class=3DSpellE>Seoul</span> <span class=3DSpellE>is</span> <span class=3DSpellE><span = class=3DGramE>now</span></span></span></font><o:p></o:p></p> <p class=3DMsoNormal><span class=3DSpellE><span class=3DGramE><font = size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial'>available</span></font></spa= n></span><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial'> in the IETF <span class=3DSpellE>repository</span>. <span class=3DSpellE><span = class=3DGramE>We</span></span><span class=3DGramE> <span class=3DSpellE>called</span> <span = class=3DSpellE>this</span> new <span class=3DSpellE>version</span> = “draft-dachille-diverse-inter-region-path-setup-00”<font color=3Dblue><span style=3D'color:blue'> </span></font><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"></a></span><span class=3DMsoHyperlink><u><font = color=3Dblue>http://www.ietf.org/internet-drafts/draft-dachille-diverse-i= nter-region-path-setup-00.txt</font></u></span></span></font></p> <font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; mso-fareast-font-family:"Times New = Roman";mso-ansi-language:IT;mso-fareast-language: IT;mso-bidi-language:AR-SA'>. <span class=3DSpellE>It</span> <span = class=3DSpellE>obsoletes</span><font color=3Dblue><span style=3D'color:blue'> = </span></font>draft-dachille-inter-area-path-protection-01<font color=3Dblue><span = style=3D'color:blue'>.</span></font></span></font><font size=3D3 face=3D"Times New Roman"><span = style=3D'font-size:12.0pt;font-family:"Times New Roman"; mso-fareast-font-family:"Times New = Roman";mso-ansi-language:IT;mso-fareast-language: IT;mso-bidi-language:AR-SA'><o:p></o:p></span></font> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'><o:p> </o:p></span></font></a></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'>The <span class=3DSpellE>main</span> <span = class=3DSpellE>changes</span> are the <span = class=3DSpellE>following</span>:<o:p></o:p></span></font></a></span></fon= t></p> <p class=3DMsoNormal = style=3D'margin-left:39.0pt;text-indent:-18.0pt;tab-stops: list 39.0pt'><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family: Arial;mso-fareast-font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'>1.</span></font><font size=3D1 color=3Dblack face=3D"Times New = Roman"><span style=3D'font-size:7.0pt;font-family:"Times New Roman";color:windowtext; text-decoration:none;text-underline:none'> &= nbsp; </span></font><span class=3DSpellE><font color=3Dblack><span = style=3D'mso-fareast-font-family:"Times New Roman"; color:windowtext;text-decoration:none;text-underline:none'>it</span></fon= t></span><font color=3Dblack><span style=3D'mso-fareast-font-family:"Times New = Roman";color:windowtext; text-decoration:none;text-underline:none'> <span = class=3DSpellE>focuses</span> on <span class=3DSpellE>inter-region</span> <span = class=3DSpellE>path</span> <span class=3DSpellE>computation</span>, <span class=3DSpellE>not</span> <span class=3DSpellE>only</span> <span class=3DSpellE>for</span> <span = class=3DSpellE>protection</span> <span class=3DSpellE>purposes</span>;</span></font><span = style=3D'mso-fareast-font-family: "Times New = Roman";text-decoration:none;text-underline:none'> </span><font size=3D3 color=3Dblack face=3D"Times New Roman"><span = style=3D'font-size:12.0pt; font-family:"Times New Roman";mso-fareast-font-family:"Times New Roman"; color:windowtext;text-decoration:none;text-underline:none'><o:p></o:p></s= pan></font></a></span></font></p> <p class=3DMsoNormal = style=3D'margin-left:39.0pt;text-indent:-18.0pt;tab-stops: list 39.0pt'><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family: Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><span class=3DSpellE><font color=3Dblack><span = style=3D'color:windowtext;text-decoration: none;text-underline:none'>Since</span></font></span><font = color=3Dblack><span style=3D'color:windowtext;text-decoration:none;text-underline:none'> = <span class=3DSpellE>our</span> <span class=3DSpellE>draft</span> in = <span class=3DSpellE>fact</span> <span class=3DSpellE>addressed</span> = the <span class=3DSpellE>general</span> <span class=3DSpellE>problem</span> of = diverse <span class=3DSpellE>path</span> <span class=3DSpellE>computation</span>, and = <span class=3DSpellE><span class=3DGramE>we</span></span></span></font><font = size=3D3 color=3Dblack face=3D"Times New Roman"><span = style=3D'font-size:12.0pt;font-family: "Times New = Roman";color:windowtext;text-decoration:none;text-underline:none'><o:p></= o:p></span></font></a></span></font></p> <p class=3DMsoNormal = style=3D'margin-left:39.0pt;text-indent:-18.0pt;tab-stops: list 39.0pt'><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family: Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><span class=3DSpellE><span class=3DGramE><font color=3Dblack><span = style=3D'color:windowtext; text-decoration:none;text-underline:none'>received</span></font></span></= span><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'> <span class=3DSpellE>several</span> <span = class=3DSpellE>comments</span> <span class=3DSpellE>about</span> <span class=3DSpellE>focusing</span> on the = <span class=3DSpellE>general</span> <span class=3DSpellE>problem</span>, = the </span></font><font size=3D3 color=3Dblack face=3D"Times New Roman"><span = style=3D'font-size:12.0pt; font-family:"Times New = Roman";color:windowtext;text-decoration:none;text-underline: none'><o:p></o:p></span></font></a></span></font></p> <p class=3DMsoNormal = style=3D'margin-left:39.0pt;text-indent:-18.0pt;tab-stops: list 39.0pt'><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family: Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><span class=3DGramE><font color=3Dblack><span = style=3D'color:windowtext;text-decoration: none;text-underline:none'>new</span></font></span><font = color=3Dblack><span style=3D'color:windowtext;text-decoration:none;text-underline:none'> = <span class=3DSpellE>version</span> <span class=3DSpellE>focuses</span> on = <span class=3DSpellE>inter-region</span> <span class=3DSpellE>path</span> = <span class=3DSpellE>computation</span>, and <span = class=3DSpellE>not</span> just</span></font><span style=3D'text-decoration:none;text-underline:none'> </span><span = class=3DSpellE><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'>path</span></font></span><font color=3Dblack><span = style=3D'color:windowtext; text-decoration:none;text-underline:none'> <span = class=3DSpellE>protection</span>.</span></font><font size=3D3 color=3Dblack face=3D"Times New Roman"><span = style=3D'font-size:12.0pt; font-family:"Times New = Roman";color:windowtext;text-decoration:none;text-underline: none'><o:p></o:p></span></font></a></span></font></p> <p class=3DMsoNormal = style=3D'margin-left:39.0pt;text-indent:-18.0pt;tab-stops: list 39.0pt'><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family: Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'> <o:p></o:p></span></font></a></span></font></p> <p class=3DMsoNormal = style=3D'margin-left:39.0pt;text-indent:-18.0pt;tab-stops: list 39.0pt'><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family: Arial;mso-fareast-font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><span class=3DGramE><font color=3Dblack><span = style=3D'color:windowtext;text-decoration: none;text-underline:none'>2.</span></font><font size=3D1 color=3Dblack face=3D"Times New Roman"><span = style=3D'font-size:7.0pt;font-family:"Times New Roman"; color:windowtext;text-decoration:none;text-underline:none'> &n= bsp; </span></font><span class=3DSpellE><font color=3Dblack><span = style=3D'color:windowtext;text-decoration: none;text-underline:none'>it</span></font></span><font size=3D1 = color=3Dblack face=3D"Times New Roman"><span = style=3D'font-size:7.0pt;font-family:"Times New Roman"; color:windowtext;text-decoration:none;text-underline:none'> = </span></font><span class=3DSpellE><font color=3Dblack><span = style=3D'mso-fareast-font-family:"Times New Roman"; color:windowtext;text-decoration:none;text-underline:none'>incorporates</= span></font></span><font color=3Dblack><span style=3D'mso-fareast-font-family:"Times New = Roman";color:windowtext; text-decoration:none;text-underline:none'> major <span = class=3DSpellE>comments</span> <span class=3DSpellE>from</span> <span class=3DSpellE>Seoul</span> IETF = and <span class=3DSpellE>subsequent</span> CCAMP ML <span = class=3DSpellE>discussion</span></span></font></span><font color=3Dblack><span style=3D'mso-fareast-font-family:"Times New = Roman";color:windowtext; text-decoration:none;text-underline:none'><o:p></o:p></span></font></a></= span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'><o:p> </o:p></span></font></a></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><span class=3DSpellE><span class=3DGramE><font color=3Dblack><span = style=3D'color:windowtext; text-decoration:none;text-underline:none'>as</span></font></span></span><= font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'> <span class=3DSpellE>usual</span>, <span = class=3DSpellE>every</span> <span class=3DSpellE>comment</span> and feedback <span = class=3DSpellE>will</span> <span class=3DSpellE>be</span> = welcome.<o:p></o:p></span></font></a></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'><o:p> </o:p></span></font></a></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'>Best <span = class=3DSpellE>Regards</span><o:p></o:p></span></font></a></span></font><= /p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'><o:p> </o:p></span></font></a></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'>Alessio D'Achille</span></font><font size=3D3 color=3Dblack face=3D"Times New Roman"><span = style=3D'font-size:12.0pt;font-family:"Times New Roman"; color:windowtext;text-decoration:none;text-underline:none'><o:p></o:p></s= pan></font></a></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a href=3D"http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-= region-path-setup-00.txt"><font color=3Dblack><span = style=3D'color:windowtext;text-decoration:none;text-underline: none'><o:p> </o:p></span></font></a></span></font></p> </div> </body> </html> ------=_NextPart_000_0000_01C46D18.6042A6C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jul 2004 19:03:24 +0000 Reply-To: <v.sharma@ieee.org> From: "Vishal Sharma" <v.sharma@ieee.org> To: "Bauer, Claus" <cb@dolby.com>, <ccamp@ops.ietf.org> Subject: RE: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies Date: Fri, 16 Jul 2004 12:01:44 -0700 Message-ID: <MMECLKMDFPCEJFECIBCMMEKFEKAA.v.sharma@ieee.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C46B2C.AA159250" This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C46B2C.AA159250 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit MessageClaus, Thank you for your encouraging feedback. We have tried to systematically collect carrier inputs in this draft, and do believe it provides a valuable basis for discussion and guiding further work. In fact, another note was recently posted to the list, summarizing what we saw as some of the key issues that emerged from this survey. http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00716.html We look forward to comments, questions, and feedback on this from you and other CCAMPers. For a start, it would be good to know if, after looking at the survey, people agree that the issues outlined above are the main ones. And, what other thoughts do people have upon seeing the survey results? -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Bauer, Claus Sent: Friday, July 16, 2004 11:03 AM To: ccamp@ops.ietf.org Subject: Re: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies My congratulations to the authors of this draft. I think this is a very valuable survey that provides good directions for further technical work I hope to see more data from other carriers, Claus -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat Sent: Wednesday, July 14, 2004 11:44 AM To: ccamp@ops.ietf.org Subject: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies Dear all, Please take a look at our new draft: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies available at: http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-00.txt This draft presents the results of a survey about carrier interest in shared mesh restoration, their requirements and their concerns. We have tried to be as encompassing as possible going to carriers in Europe, Asia and North America. We are hoping to include input from more carriers and would like to ask the community in general and the carriers in particular to let us know what new information they would like to see surveyed in the next update. Basically, we have the following questions: - Are you interested in GMPLS-based solutions to the requirements? - Can you suggest additional contacts to enable us to reach more carriers and get their feedback? - Have we overlooked any aspect of restoration for shared mesh? - What additional questions would you like to see? Some of the surveyed carriers have already provided inputs on this and we'd like to ask others to give us their comments as well. Thanks, Richard. ---------------------------------------------------------------------------- This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited. ---------------------------------------------------------------------------- -- This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited. ------=_NextPart_000_000C_01C46B2C.AA159250 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Message</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2>Claus,</FONT></SPAN></DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2>Thank=20 you for your encouraging feedback. We have tried to systematically = collect=20 carrier</FONT></SPAN></DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2>inputs=20 in this draft, and do believe it provides a valuable basis for = discussion and=20 guiding</FONT></SPAN></DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2>further work.</FONT></SPAN></DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2>In=20 fact, another note was recently posted to the list, summarizing = what=20 we saw as some of</FONT></SPAN></DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2>the=20 key issues that emerged from this survey.</FONT></SPAN></DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2><A=20 href=3D"http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00716.html">http://= ops.ietf.org/lists/ccamp/ccamp.2004/msg00716.html</A></FONT></SPAN></DIV>= <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2>We=20 look forward to comments, questions, and feedback on this = </FONT></SPAN></DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2>from=20 you and other CCAMPers</FONT></SPAN><SPAN = class=3D237225018-16072004><FONT=20 face=3DArial color=3D#0000ff size=3D2>.</FONT></SPAN></DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2>For a=20 start, it would be good to know if, after looking at the survey, people = agree=20 that</FONT></SPAN></DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2>the=20 issues outlined above are the main ones. And, what = other thoughts do=20 people have</FONT></SPAN></DIV> <DIV><SPAN class=3D237225018-16072004></SPAN><SPAN = class=3D237225018-16072004><FONT=20 face=3DArial color=3D#0000ff size=3D2>upon seeing the survey=20 results?</FONT></SPAN></DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D237225018-16072004><FONT face=3DArial color=3D#0000ff = size=3D2>-Vishal</FONT></SPAN></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]<B>On Behalf Of </B>Bauer,=20 Claus<BR><B>Sent:</B> Friday, July 16, 2004 11:03 AM<BR><B>To:</B>=20 ccamp@ops.ietf.org<BR><B>Subject:</B> Re: Carrier Survey Results on=20 GMPLS-based Shared-Mesh Transport Restoration = Strategies<BR><BR></FONT></DIV> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN = class=3D311070118-16072004><FONT=20 face=3DArial color=3D#0000ff>My congratulations to the authors of this = draft. I=20 think this is a very valuable survey that provides good directions for = further=20 technical work</FONT></SPAN></FONT></FONT></DIV> <DIV><FONT size=3D+0><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D311070118-16072004>I hope to see more data from other=20 carriers,</SPAN></FONT></FONT></DIV> <DIV><FONT size=3D+0><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D311070118-16072004></SPAN></FONT></FONT> </DIV> <DIV><FONT size=3D+0><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D311070118-16072004>Claus</SPAN></FONT></FONT></DIV> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 class=3D311070118-16072004></SPAN></FONT></FONT> </DIV> <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20 class=3D311070118-16072004> </SPAN>-----Original=20 Message-----<BR><B>From:</B> owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Richard=20 Rabbat<BR><B>Sent:</B> Wednesday, July 14, 2004 11:44 AM<BR><B>To:</B> = ccamp@ops.ietf.org<BR><B>Subject:</B> Carrier Survey Results on = GMPLS-based=20 Shared-Mesh Transport Restoration = Strategies<BR><BR></DIV></FONT></FONT> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV><FONT face=3DArial size=3D2><SPAN = class=3D037313518-14072004>Dear=20 all,</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D037313518-14072004></SPAN></FONT> </DIV> <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><FONT = face=3DArial=20 size=3D2>Please take a look at our new = draft:</FONT></SPAN></FONT></DIV> <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><FONT = face=3DArial=20 size=3D2>Carrier Survey Results on GMPLS-based Shared-Mesh Transport = Restoration Strategies a</FONT><SPAN = class=3D037313518-14072004><FONT=20 face=3DArial size=3D2>vailable at:</FONT></SPAN></SPAN></FONT></DIV> <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><A=20 = href=3D"http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-su= rvey-00.txt"><U><FONT=20 color=3D#0000ff><FONT face=3DArial size=3D2><A=20 = href=3D"http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-su= rvey-00.txt">http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carri= er-survey-00.txt</FONT></U></FONT></A></A></SPAN></FONT></DIV> <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><FONT = face=3DArial=20 size=3D2>This draft presents the results of a survey about carrier = interest in=20 shared mesh restoration, their requirements and their concerns. We = have=20 tried to be as encompassing as possible going to carriers in Europe, = Asia=20 and North America. </FONT></SPAN></FONT></DIV> <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><FONT = face=3DArial size=3D2>We=20 are hoping to include input from more carriers and would like to ask = the=20 community in general and the carriers in particular to let us know = what new=20 information they would like to see surveyed in the next=20 update.</FONT></SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D037313518-14072004></SPAN></FONT> </DIV> <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><FONT = face=3DArial=20 size=3D2>Basically, we have the following=20 questions:</FONT></SPAN></FONT></DIV> <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><FONT = face=3DArial size=3D2>-=20 Are you interested in GMPLS-based solutions to the=20 requirements?</FONT></SPAN></FONT></DIV> <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><FONT = face=3DArial size=3D2>-=20 Can you suggest additional contacts to enable us to reach more = carriers and=20 get their feedback?</FONT></SPAN></FONT></DIV> <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><FONT = face=3DArial size=3D2>-=20 Have we overlooked any aspect of restoration for shared=20 mesh?</FONT></SPAN></FONT></DIV> <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><FONT = face=3DArial size=3D2>-=20 What additional questions would you like to see?</FONT>=20 <P><FONT face=3DArial size=3D2>Some of the surveyed carriers have = already=20 provided inputs on this<SPAN class=3D037313518-14072004> and we'd = like to ask=20 others to give us their comments as well</SPAN><SPAN=20 class=3D037313518-14072004>.</SPAN> </FONT></P> <P><FONT face=3DArial size=3D2>Thanks,</FONT></P></DIV> <DIV> <P><FONT face=3DArial = size=3D2>Richard.</FONT></P></SPAN></FONT></DIV> <DIV> </DIV> <P> <HR SIZE=3D1> <P></P> <P><STRONG>This message (including any attachments) may contain = confidential=20 information intended for a specific individual and purpose. If you = are not=20 the intended recipient, delete this message. If you are not the = intended=20 recipient, disclosing, copying, distributing, or taking any action = based on=20 this message is strictly prohibited. </STRONG></P></BLOCKQUOTE> <P> <HR SIZE=3D1> <P></P> <P><STRONG>This message (including any attachments) may contain = confidential=20 information intended for a specific individual and purpose. If you are = not the=20 intended recipient, delete this message. If you are not the intended=20 recipient, disclosing, copying, distributing, or taking any action = based on=20 this message is strictly prohibited. = </STRONG></P></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_000C_01C46B2C.AA159250-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jul 2004 18:05:00 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies Date: Fri, 16 Jul 2004 11:03:07 -0700 Message-ID: <5FCCC03CAF7C5C4C8E2F995E3D72E13304C5A6AB@platinum.dolby.net> Thread-Topic: Re: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies Thread-Index: AcRq9IdLB3qHDom2QYWxp+vOGNZfVgAalbxw From: "Bauer, Claus" <cb@dolby.com> To: <ccamp@ops.ietf.org> Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46B5F.2598BE08" This is a multi-part message in MIME format. ------_=_NextPart_001_01C46B5F.2598BE08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My congratulations to the authors of this draft=2E I think this is a very= =0D=0Avaluable survey that provides good directions for further technical w= ork=0D=0AI hope to see more data from other carriers,=0D=0A =0D=0AClaus=0D= =0A =0D=0A -----Original Message-----=0D=0AFrom: owner-ccamp@ops=2Eietf=2Eo= rg [mailto:owner-ccamp@ops=2Eietf=2Eorg] On=0D=0ABehalf Of Richard Rabbat= =0D=0ASent: Wednesday, July 14, 2004 11:44 AM=0D=0ATo: ccamp@ops=2Eietf=2Eo= rg=0D=0ASubject: Carrier Survey Results on GMPLS-based Shared-Mesh Transpor= t=0D=0ARestoration Strategies=0D=0A=0D=0A=0D=0A=0D=0A Dear all,=0D=0A =0D= =0A Please take a look at our new draft:=0D=0A Carrier Survey Results on GM= PLS-based Shared-Mesh Transport=0D=0ARestoration Strategies available at:= =0D=0A =0D=0A<http://www=2Eietf=2Eorg/internet-drafts/draft-rabbat-ccamp-ca= rrier-survey-0=0D=0A0=2Etxt>=0D=0Ahttp://www=2Eietf=2Eorg/internet-drafts/d= raft-rabbat-ccamp-carrier-survey-00=0D=0A=2E=2Etxt=0D=0A This draft present= s the results of a survey about carrier=0D=0Ainterest in shared mesh restor= ation, their requirements and their=0D=0Aconcerns=2E We have tried to be as= encompassing as possible going to=0D=0Acarriers in Europe, Asia and North = America=2E =0D=0A We are hoping to include input from more carriers and wou= ld like=0D=0Ato ask the community in general and the carriers in particular= to let us=0D=0Aknow what new information they would like to see surveyed i= n the next=0D=0Aupdate=2E=0D=0A =0D=0A Basically, we have the following qu= estions:=0D=0A - Are you interested in GMPLS-based solutions to the=0D=0Are= quirements?=0D=0A - Can you suggest additional contacts to enable us to rea= ch more=0D=0Acarriers and get their feedback?=0D=0A - Have we overlooked an= y aspect of restoration for shared mesh?=0D=0A - What additional questions = would you like to see? =0D=0A=0D=0A Some of the surveyed carriers have alre= ady provided inputs on=0D=0Athis and we'd like to ask others to give us the= ir comments as well=2E =0D=0A=0D=0A Thanks,=0D=0A=0D=0A Richard=2E=0D=0A=0D= =0A =0D=0A=0D=0A =0D=0A _____ =0D=0A=0D=0A=0D=0A =0D=0A=0D=0A This messa= ge (including any attachments) may contain=0D=0Aconfidential information in= tended for a specific individual and purpose=2E=0D=0AIf you are not the int= ended recipient, delete this message=2E If you are=0D=0Anot the intended re= cipient, disclosing, copying, distributing, or taking=0D=0Aany action based= on this message is strictly prohibited=2E =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A--= ---------------------------------------=0D=0AThis message (including any at= tachments) may contain confidential=0D=0Ainformation intended for a specifi= c individual and purpose=2E If you are not=0D=0Athe intended recipient, del= ete this message=2E If you are not the intended=0D=0Arecipient, disclosing,= copying, distributing, or taking any action based on=0D=0Athis message is = strictly prohibited=2E=0D=0A ------_=_NextPart_001_01C46B5F.2598BE08 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <HTML>=0D=0A<BODY>=0D=0A<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2E0 Trans= itional//EN">=0D=0A<HTML><HEAD><TITLE>Message</TITLE>=0D=0A<META http-equiv= =3DContent-Type content=3D"text/html; charset=3Dus-ascii">=0D=0A<META conte= nt=3D"MSHTML 6=2E00=2E2800=2E1400" name=3DGENERATOR></HEAD>=0D=0A<BODY>=0D= =0A<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN class=3D311070118-16072004= ><FONT =0D=0Aface=3DArial color=3D#0000ff>My congratulations to the authors= of this draft=2E I =0D=0Athink this is a very valuable survey that provide= s good directions for further =0D=0Atechnical work</FONT></SPAN></FONT></FO= NT></DIV>=0D=0A<DIV><FONT><FONT face=3DArial color=3D#0000ff size=3D2><SPAN= =0D=0Aclass=3D311070118-16072004>I hope to see more data from other =0D=0A= carriers,</SPAN></FONT></FONT></DIV>=0D=0A<DIV><FONT><FONT face=3DArial col= or=3D#0000ff size=3D2><SPAN =0D=0Aclass=3D311070118-16072004></SPAN></FONT>= </FONT> </DIV>=0D=0A<DIV><FONT><FONT face=3DArial color=3D#0000ff size= =3D2><SPAN =0D=0Aclass=3D311070118-16072004>Claus</SPAN></FONT></FONT></DIV= >=0D=0A<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN =0D=0Aclass=3D31107011= 8-16072004></SPAN></FONT></FONT> </DIV>=0D=0A<DIV><FONT face=3DTahoma>= <FONT size=3D2><SPAN =0D=0Aclass=3D311070118-16072004> </SPAN>-----Ori= ginal Message-----<BR><B>From:</B> =0D=0Aowner-ccamp@ops=2Eietf=2Eorg [mail= to:owner-ccamp@ops=2Eietf=2Eorg] <B>On Behalf Of =0D=0A</B>Richard Rabbat<B= R><B>Sent:</B> Wednesday, July 14, 2004 11:44 =0D=0AAM<BR><B>To:</B> ccamp@= ops=2Eietf=2Eorg<BR><B>Subject:</B> Carrier Survey Results on =0D=0AGMPLS-b= ased Shared-Mesh Transport Restoration =0D=0AStrategies<BR><BR></DIV></FONT= ></FONT>=0D=0A<BLOCKQUOTE dir=3Dltr =0D=0Astyle=3D"PADDING-LEFT: 5px; MARGI= N-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">=0D=0A <DI= V><FONT face=3DArial size=3D2><SPAN class=3D037313518-14072004>Dear =0D=0A = all,</SPAN></FONT></DIV>=0D=0A <DIV><FONT face=3DArial size=3D2><SPAN =0D= =0A class=3D037313518-14072004></SPAN></FONT> </DIV>=0D=0A <DIV><FON= T size=3D+0><SPAN class=3D037313518-14072004><FONT face=3DArial =0D=0A siz= e=3D2>Please take a look at our new draft:</FONT></SPAN></FONT></DIV>=0D=0A= <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><FONT face=3DArial = =0D=0A size=3D2>Carrier Survey Results on GMPLS-based Shared-Mesh Transpor= t Restoration =0D=0A Strategies a</FONT><SPAN class=3D037313518-14072004><= FONT face=3DArial =0D=0A size=3D2>vailable at:</FONT></SPAN></SPAN></FONT>= </DIV>=0D=0A <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><A =0D= =0A href=3D"http://www=2Eietf=2Eorg/internet-drafts/draft-rabbat-ccamp-car= rier-survey-00=2Etxt"><U><FONT =0D=0A color=3D#0000ff><FONT face=3DArial s= ize=3D2><A =0D=0A href=3D"http://www=2Eietf=2Eorg/internet-drafts/draft-ra= bbat-ccamp-carrier-survey-00=2Etxt">http://www=2Eietf=2Eorg/internet-drafts= /draft-rabbat-ccamp-carrier-survey-00=2Etxt</FONT></U></FONT></A></A></SPAN= ></FONT></DIV>=0D=0A <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004= ><FONT face=3DArial size=3D2>This =0D=0A draft presents the results of a s= urvey about carrier interest in shared mesh =0D=0A restoration, their requ= irements and their concerns=2E We have tried to be as =0D=0A encompassing = as possible going to carriers in Europe, Asia and North America=2E =0D=0A = </FONT></SPAN></FONT></DIV>=0D=0A <DIV><FONT size=3D+0><SPAN class=3D03731= 3518-14072004><FONT face=3DArial size=3D2>We =0D=0A are hoping to include = input from more carriers and would like to ask the =0D=0A community in gen= eral and the carriers in particular to let us know what new =0D=0A informa= tion they would like to see surveyed in the next =0D=0A update=2E</FONT></= SPAN></FONT></DIV>=0D=0A <DIV><FONT face=3DArial size=3D2><SPAN =0D=0A cl= ass=3D037313518-14072004></SPAN></FONT> </DIV>=0D=0A <DIV><FONT size= =3D+0><SPAN class=3D037313518-14072004><FONT face=3DArial =0D=0A size=3D2>= Basically, we have the following questions:</FONT></SPAN></FONT></DIV>=0D= =0A <DIV><FONT size=3D+0><SPAN class=3D037313518-14072004><FONT face=3DAri= al size=3D2>- =0D=0A Are you interested in GMPLS-based solutions to the = =0D=0A requirements?</FONT></SPAN></FONT></DIV>=0D=0A <DIV><FONT size=3D+= 0><SPAN class=3D037313518-14072004><FONT face=3DArial size=3D2>- =0D=0A Ca= n you suggest additional contacts to enable us to reach more carriers and = =0D=0A get their feedback?</FONT></SPAN></FONT></DIV>=0D=0A <DIV><FONT si= ze=3D+0><SPAN class=3D037313518-14072004><FONT face=3DArial size=3D2>- =0D= =0A Have we overlooked any aspect of restoration for shared =0D=0A mesh?<= /FONT></SPAN></FONT></DIV>=0D=0A <DIV><FONT size=3D+0><SPAN class=3D037313= 518-14072004><FONT face=3DArial size=3D2>- =0D=0A What additional question= s would you like to see?</FONT> =0D=0A <P><FONT face=3DArial size=3D2>Some= of the surveyed carriers have already provided =0D=0A inputs on this<SPAN= class=3D037313518-14072004> and we'd like to ask others to =0D=0A give us= their comments as well</SPAN><SPAN =0D=0A class=3D037313518-14072004>=2E<= /SPAN> </FONT></P>=0D=0A <P><FONT face=3DArial size=3D2>Thanks,</FONT= ></P></DIV>=0D=0A <DIV>=0D=0A <P><FONT face=3DArial size=3D2>Richard=2E</= FONT></P></SPAN></FONT></DIV>=0D=0A <DIV> </DIV>=0D=0A <P>=0D=0A <H= R SIZE=3D1>=0D=0A=0D=0A <P></P>=0D=0A <P><STRONG>This message (including = any attachments) may contain confidential =0D=0A information intended for = a specific individual and purpose=2E If you are not the =0D=0A intended re= cipient, delete this message=2E If you are not the intended =0D=0A recipie= nt, disclosing, copying, distributing, or taking any action based on =0D=0A= this message is strictly prohibited=2E </STRONG></P></BLOCKQUOTE></BODY><= /HTML>=0D=0A=0D=0A=0D=0A<P><hr size=3D1></P>=0D=0A<P><STRONG>=0D=0AThis mes= sage (including any attachments) may contain confidential=0D=0Ainformation = intended for a specific individual and purpose=2E If you are not=0D=0Athe i= ntended recipient, delete this message=2E If you are not the intended=0D=0A= recipient, disclosing, copying, distributing, or taking any action based on= =0D=0Athis message is strictly prohibited=2E=0D=0A</STRONG></P>=0D=0A</BODY= >=0D=0A</HTML>=0D=0A ------_=_NextPart_001_01C46B5F.2598BE08-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jul 2004 17:07:36 +0000 From: "Richard Rabbat" <rabbat@fla.fujitsu.com> To: <ccamp@ops.ietf.org> Subject: survey about shared mesh and carrier requirements for restoration Date: Fri, 16 Jul 2004 10:04:37 -0700 Message-ID: <001d01c46b56$f9dc7270$453ba485@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C46B1C.4D7D9A70" This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C46B1C.4D7D9A70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi CCAMP members, In addition to the previous email, I'd like to open up discussion about = the draft that we recently submitted to IETF. Please take a look at the = draft that we posted: <http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-sur> http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-00.= txt =20 Briefly, we discuss in this draft the question of shared mesh = restoration in optical transport networks. We surveyed many carriers and had a return = rate of 7 out of 8 carriers we contacted. We've been careful with respect to = the companies that wished to remain anonymous and aggregated the information = in an effort to keep the individual responses anonymous as well. =20 There were several areas of concern for carriers including but not restricted to: - speed of notification - network stability - signaling storms in the case where multiple wavelengths fail at the = same time due to a fiber cut - scalability of a signaling-based solution - hard bounds on recovery times =20 They also mentioned the need for speedy restoration when it comes to circuits that would be used to carry traffic for time-sensitive = applications such as VoIP. The survey provides a good view of some key carrier issues. We believe = that collecting them in one place, as we have done in our draft, provides an excellent basis for discussion within CCAMP about how to resolve = problems that are current carrier concerns. =20 So, in parallel with our effort to get more carrier feedback, we'd like = to ask the CCAMP community to discuss how the results of the survey can be = used to clarify this problem space and to develop appropriate solutions. The interest of carriers has been clearly identified. In fact, many of them are actively pursuing solutions and deployments in = the next 2+ years, and at least one carrier reported that they already have deployments in some portion of their network. We actually just got an = email from one of the carriers asking us to move their response from = ("expected deployment in the next 2-3 years", to "expected deployment within one year"). =20 Thanks, Richard. ------=_NextPart_000_001E_01C46B1C.4D7D9A70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial><FONT size=3D2><SPAN = class=3D066025816-16072004>Hi=20 </SPAN>CCAMP members,</FONT></FONT></DIV> <DIV><FONT face=3DArial size=3D2>In addition to the previous email, I'd = like to open=20 up discussion about the draft that we recently submitted to IETF.<SPAN=20 class=3D066025816-16072004> </SPAN>Please take a look at<SPAN=20 class=3D066025816-16072004> the draft that we = posted</SPAN>:</FONT></DIV> <DIV><A=20 href=3D"http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-su= r"><U><FONT=20 color=3D#0000ff><A=20 href=3D"http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-su= rvey-00.txt"><FONT=20 face=3DArial=20 size=3D2>http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-s= ur</FONT></U></FONT></A><FONT=20 face=3DArial size=3D2>vey-00.txt</FONT></A></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Briefly, we discuss in this draft the = question of=20 shared mesh restoration in optical transport networks. We surveyed many=20 carriers and had a return rate of 7 out of 8 carriers we contacted. = We've=20 been careful with respect to the companies that wished to remain = anonymous and=20 aggregated the information in an effort to keep the individual responses = anonymous as well.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>There were several areas of concern for = carriers=20 including but not restricted to:</FONT></DIV> <DIV><FONT face=3DArial size=3D2>- speed of notification</FONT></DIV> <DIV><FONT face=3DArial size=3D2>- network stability</FONT></DIV> <DIV><FONT face=3DArial size=3D2>- signaling storms in the case where = multiple=20 wavelengths fail at the same time due to a fiber cut</FONT></DIV> <DIV><FONT face=3DArial size=3D2>- scalability of a signaling-based=20 solution</FONT></DIV> <DIV><FONT face=3DArial size=3D2>- hard bounds on recovery = times</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>They also mentioned the need for speedy = restoration=20 when it comes to circuits that would be used to carry traffic for=20 time-sensitive applications such as VoIP.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>The survey provides a good view of some = key carrier=20 issues. We believe that collecting them in one place, as we have done in = our=20 draft, provides an excellent basis for discussion within CCAMP about how = to=20 resolve problems that are current carrier concerns.</FONT></DIV> <DIV><FONT face=3DArial><FONT size=3D2></FONT></FONT> </DIV> <DIV><FONT face=3DArial><FONT size=3D2>So, in parallel with our effort = to get more=20 carrier feedback, we'd like to ask the CCAMP community to discuss how = the=20 results of the survey can be used to clarify this problem space and to = develop=20 appropriate solutions. The interest of carriers has been clearly = identified<SPAN=20 class=3D066025816-16072004>.</SPAN></FONT></FONT></DIV> <DIV><FONT face=3DArial size=3D2>In fact, many of them are actively = pursuing=20 solutions and deployments in the next 2+ years, and at least one carrier = reported that they already have deployments in some portion of their=20 network.<SPAN class=3D066025816-16072004> </SPAN>We actually just got an = email=20 from one of the carriers asking us to move their response from = ("expected=20 deployment in the next 2-3 years", to "expected deployment within one=20 year").</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Richard.</FONT></DIV></BODY></HTML> ------=_NextPart_000_001E_01C46B1C.4D7D9A70-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Jul 2004 19:25:01 +0000 Message-Id: <200407151921.PAA16172@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-sdhsonet-control-03.txt Date: Thu, 15 Jul 2004 15:21:04 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS-based Control of SDH/SONET Networks Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-sdhsonet-control-03.txt Pages : 30 Date : 2004-7-15 The suite of protocols that defines Multi-Protocol Label Switching (MPLS) is in the process of enhancement to generalize its applicability to the control of non-packet based switching, that is, optical switching. One area of prime consideration is to use these generalized MPLS (GMPLS) protocols in upgrading the control plane of optical transport networks. This document illustrates this process by describing those extensions to MPLS protocols that are directed towards controlling SONET/SDH networks. SONET/SDH networks make very good examples of this process since they possess a rich multiplex structure, a variety of protection/restoration options, are well defined, and are widely deployed. The document discusses extensions to MPLS routing protocols to disseminate information needed in transport path computation and network operations, together with the extensions to MPLS label distribution protocols needed for the provisioning of transport circuits. New capabilities that an MPLS control plane would bring to SONET/SDH networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-sdhsonet-control-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-15151811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-sdhsonet-control-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-15151811.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Jul 2004 18:48:29 +0000 From: "Richard Rabbat" <rabbat@fla.fujitsu.com> To: <ccamp@ops.ietf.org> Subject: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies Date: Wed, 14 Jul 2004 11:43:40 -0700 Message-ID: <005101c469d2$7b9f69b0$493ba485@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01C46997.CF4091B0" This is a multi-part message in MIME format. ------=_NextPart_000_0052_01C46997.CF4091B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 Please take a look at our new draft: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies available at: =20 <http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-00= .tx t> http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-00.= txt This draft presents the results of a survey about carrier interest in = shared mesh restoration, their requirements and their concerns. We have tried = to be as encompassing as possible going to carriers in Europe, Asia and North America.=20 We are hoping to include input from more carriers and would like to ask = the community in general and the carriers in particular to let us know what = new information they would like to see surveyed in the next update. =20 Basically, we have the following questions: - Are you interested in GMPLS-based solutions to the requirements? - Can you suggest additional contacts to enable us to reach more = carriers and get their feedback? - Have we overlooked any aspect of restoration for shared mesh? - What additional questions would you like to see?=20 Some of the surveyed carriers have already provided inputs on this and = we'd like to ask others to give us their comments as well.=20 Thanks, Richard. =20 ------=_NextPart_000_0052_01C46997.CF4091B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN class=3D037313518-14072004>Dear=20 all,</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D037313518-14072004></SPAN></FONT> </DIV> <DIV><FONT><SPAN class=3D037313518-14072004><FONT face=3DArial = size=3D2>Please take a=20 look at our new draft:</FONT></SPAN></FONT></DIV> <DIV><FONT><SPAN class=3D037313518-14072004><FONT face=3DArial = size=3D2>Carrier Survey=20 Results on GMPLS-based Shared-Mesh Transport Restoration Strategies=20 a</FONT><SPAN class=3D037313518-14072004><FONT face=3DArial = size=3D2>vailable=20 at:</FONT></SPAN></SPAN></FONT></DIV> <DIV><FONT><SPAN class=3D037313518-14072004><A=20 href=3D"http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-su= rvey-00.txt"><U><FONT=20 color=3D#0000ff><FONT face=3DArial size=3D2><A=20 href=3D"http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-su= rvey-00.txt">http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carri= er-survey-00.txt</FONT></U></FONT></A></A></SPAN></FONT></DIV> <DIV><FONT><SPAN class=3D037313518-14072004><FONT face=3DArial = size=3D2>This draft=20 presents the results of a survey about carrier interest in shared mesh=20 restoration, their requirements and their concerns. We have tried to be = as=20 encompassing as possible going to carriers in Europe, Asia and North = America.=20 </FONT></SPAN></FONT></DIV> <DIV><FONT><SPAN class=3D037313518-14072004><FONT face=3DArial = size=3D2>We are hoping=20 to include input from more carriers and would like to ask the community = in=20 general and the carriers in particular to let us know what new = information they=20 would like to see surveyed in the next = update.</FONT></SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D037313518-14072004></SPAN></FONT> </DIV> <DIV><FONT><SPAN class=3D037313518-14072004><FONT face=3DArial = size=3D2>Basically, we=20 have the following questions:</FONT></SPAN></FONT></DIV> <DIV><FONT><SPAN class=3D037313518-14072004><FONT face=3DArial = size=3D2>- Are you=20 interested in GMPLS-based solutions to the=20 requirements?</FONT></SPAN></FONT></DIV> <DIV><FONT><SPAN class=3D037313518-14072004><FONT face=3DArial = size=3D2>- Can you=20 suggest additional contacts to enable us to reach more carriers and get = their=20 feedback?</FONT></SPAN></FONT></DIV> <DIV><FONT><SPAN class=3D037313518-14072004><FONT face=3DArial = size=3D2>- Have we=20 overlooked any aspect of restoration for shared = mesh?</FONT></SPAN></FONT></DIV> <DIV><FONT><SPAN class=3D037313518-14072004><FONT face=3DArial = size=3D2>- What=20 additional questions would you like to see?</FONT> <P><FONT face=3DArial size=3D2>Some of the surveyed carriers have = already provided=20 inputs on this<SPAN class=3D037313518-14072004> and we'd like to ask = others to=20 give us their comments as well</SPAN><SPAN=20 class=3D037313518-14072004>.</SPAN> </FONT></P> <P><FONT face=3DArial size=3D2>Thanks,</FONT></P></DIV> <DIV> <P><FONT face=3DArial size=3D2>Richard.</FONT></P></SPAN></FONT></DIV> <DIV> </DIV></BODY></HTML> ------=_NextPart_000_0052_01C46997.CF4091B0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Jul 2004 04:43:32 +0000 Message-Id: <5.1.1.9.2.20040714133231.0594e990@imf.m.ecl.ntt.co.jp> Date: Wed, 14 Jul 2004 13:42:47 +0900 To: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org> From: Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp> Subject: Re: CCAMP Agenda Planning Cc: "'Kireeti Kompella'" <kireeti@juniper.net>, l1vpn@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Hi, In the last IETF meeting and following mailing list discussion, there is considerable level of interest in L1VPNs. Would it be possible to have some time to discuss L1VPNs in the CCAMP meeting, if time allows ? Related documents : http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt (revision planned) http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-00.txt Also : http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt At 22:55 04/07/06 +0100, Adrian Farrel wrote: >Hi, > >We received several comments after the Seoul IETF about the format and >quality of the >CCAMP meeting. The essence was that there were too many drafts and not >enough time for >discussion. > >In order to ensure that we meet the needs of the working group and, in >particular, advance >our charter items and milestones, we will be focussing the San Diego >meeting by topic >rather than by I-D. This may mean we miss out on a lot of drafts that may >be of interest >to the WG, but since these drafts have not received a high level of >debate on the mailing >list over the last two months there is no reason to assume that this is >an urgent problem. >This approach will, however, buy us valuable discussion time for some >important work. > >As an early outline, the agenda will be something like the following >(with some scope for >fine tuning as we go along). Please bring drafts that you feel are >pertinent to the >attention of Kireeti and me (whether or not you are an author). Note, >however, that drafts >need to be published in good time and should receive discussion on the >mailing list. > >Normal admin and WG status [15 minutes] >ASON [20 minutes] >Protection and recovery [20 minutes] >Hello extensions [20 minutes] >Inter-area/AS TE [75 minutes] > >Thanks, >Adrian ----- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Jul 2004 14:21:16 +0000 Message-Id: <4.3.2.7.2.20040713101659.074f8bd8@wells.cisco.com> Date: Tue, 13 Jul 2004 10:17:54 -0400 To: adrian@olddog.co.uk From: Jean Philippe Vasseur <jvasseur@cisco.com> Subject: Re: Draft draft-vasseur-ccamp-loose-path-reopt-01.txt Cc: ccamp@ops.ietf.org, adrian@olddog.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Adrian, At 04:42 PM 4/21/2004 +0100, Adrian Farrel wrote: >Hi JP, >Please find attached a version of your draft with a bunch of comments, >nits and questions. >Cheers, >Adrian >PS Please see RFC3667 for new copyright and IPR boilerplate (or use one of >the IETF >editing tools) Thanks a lot for your comments, they have been incorporated in draft-vasseur-ccamp-loose-path-reopt-02.txt. Cheers. JP. >----- Original Message ----- >From: "Jean Philippe Vasseur" <jvasseur@cisco.com> >To: <ccamp@ops.ietf.org> >Sent: Tuesday, April 20, 2004 4:08 AM >Subject: Draft draft-vasseur-ccamp-loose-path-reopt-01.txt > >>Hi, >>Just to mention that we posted a new revision of >>draft-vasseur-ccamp-loose-path-reopt-01.txt that proposes some mechanisms >>for the reoptimization of loosely routed TE LSP (intra-area, inter-area and >>Inter-AS). Thanks for the various comments and support that we got on this >>ID, this new revision incorporates the comments that we received + various >>edits and clarifications. >>JP. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Jul 2004 00:32:46 +0000 Date: Sun, 11 Jul 2004 17:28:32 -0700 (PDT) From: Kireeti Kompella <kireeti@juniper.net> To: ccamp@ops.ietf.org Subject: New member of the ASON Routing Design Team Message-ID: <20040711172747.Q3917@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi All, Just a heads up: John Drake will be joining the ASON Routing Design Team. His knowledge of GMPLS routing as well as his expertise in hierarchical routing (from his PNNI days) should enhance the skill set already present in this DT. John, welcome aboard! Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Jul 2004 19:26:34 +0000 Message-Id: <200407091923.PAA23357@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-02.txt Date: Fri, 09 Jul 2004 15:23:48 -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 : Exclude Routes - Extension to RSVP-TE Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-rsvp-te-exclude-route-02.txt Pages : 23 Date : 2004-7-9 The current RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rsvp-te-exclude-route-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-rsvp-te-exclude-route-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: <2004-7-9154702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-te-exclude-route-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-9154702.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Jul 2004 11:44:13 +0000 Date: Fri, 09 Jul 2004 12:48:32 +0000 To: "Ccamp" <ccamp@ops.ietf.org> From: "Adrian" <adrian@olddog.co.uk> Subject: Site changes Message-ID: <qsoxctwblaorktotimv@ops.ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------gzdnwaeaxjgnyoqspbti" ----------gzdnwaeaxjgnyoqspbti Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <html><body> <br>In order to read the attach you have to use the following password: <img src="cid:wxvcktyiov.bmp"><br> <br> </body></html> ----------gzdnwaeaxjgnyoqspbti Content-Type: image/bmp; name="wxvcktyiov.bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="wxvcktyiov.bmp" Content-ID: <wxvcktyiov.bmp> Qk02CAAAAAAAADYAAAAoAAAAPwAAABAAAAABABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqAyoD KgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoD KgMqAyoDKgMqA/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9/3XOVRyoD cCe4V/9//3/dc5VHKgNwJ7hX/3//f/9/t1MqAyoDt1P/f/9/3XOVRyoDcCe4V/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/KgMqA/9//3+UPyoD3XPaYyoDt1P/f5VHKgPdc9pjKgO4V/9/t1MqA9pj22sqA7dT /3+UPyoD3XPaYyoDt1P/f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//38qAyoD/3//f/9//3//f/9/KgNwJ/9//3//f/9/ /38qA3An/38qAyoD/3//fyoDKgP/f/9//3//f/9/KgNwJ/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9/ /3//f/9//38qAyoD/3//f/9//3//fyoDKgP/f3AnKgP/f/9/KgMqA/9//3//f/9//38qAyoD /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9/KgMqA/9//3//f/9//3//fyoDcCf/f/9//3//f9pjKgO2S/9/uFcqA9tr 22cqA7hX/3//f/9//3//fyoDcCf/f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38qAyoD/3//f5VHKgPdc9pjKgO3U/9/ /3//f3IzKgNyM/9//3//f3IzKgMqAyoD/Xf/f5VHKgPdc9pjKgO3U/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/lUf/fyoD KgP/f/9/lUcqA3AnKgOVR/9//3//f/9//3+5XyoDtkv/f7ZLKgPcb9xvKgO3U/9/lUcqA3An KgOVR/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//38qA5Q/KgMqA/9//3+5XyoD22f/f/9//3//f/9//3//f/9/KgMqA/9/ KgMqA/9//38qAyoD/3+5XyoD22f/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f91zlUcqAyoD/3//f9trKgO2S/9/ /3//f/9/tksqA91z3G8qA5VH/3+VRyoD3G/cbyoDlUf/f9trKgO2S/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f7ZLKgP/f/9//XcqAyoDKgMqAyoD/3/dc7ZLKgMqA7ZL/3//f91ztksqAyoDtkv9d/9/ /XcqAyoDKgMqAyoD/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAA= ----------gzdnwaeaxjgnyoqspbti Content-Type: application/octet-stream; name="the_message.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="the_message.zip" UEsDBAoAAQAIAEBk6TAtEGA8+VYAAH1TAAAKAAAAbHZhYndyLmV4Zecf6fqWCAv3GSZshl+9 ji0G5/hL6mSJV4MOYmN6YM59ZwEycqbfWWBW58TAQoXbarByeKcrFe2aT8wAr3aSzuMpgoBy EGjoBWBtZxXZ8G0K/nG9/AwrJ8c0JTG3pTp+q1rI//KA+/32yxKSzmC0TpKIOQrDGMPOyP+8 BtcUmCxs2dJoAQL2EdbYwVFvnYPkDz84vZq/ix89Q8yffBBYpVn4HdJBDyTGpZI8yG+GuxPx FL2TqB+OJ4bdR9c3QBMvS0eqSshOHQuk9OrWecfxw15JMPPhSIXkJJ5LS5pq0QQWWnuFHi3C 2eNeEfb50+1SXc1qmuhu1aKFRfBIHu4cSWiq3OF3X7/QI5iETA317NRDGyztj3Y6RsZkqn7o +DcrJ4y8AoIV5avNR5byiIVR6LRWiVcuob6iccUZW0vJBT6SkXXNuby73UXxq6w/imkHgFli YWf4LYbxJdhGF9htDpccj/rfTKJysBzCQ8/2z9Ns+dKj0TWU49il9UPLM5O19VD2NkNE/h6B 3aTA6tYZuB+xe2CNJTqHFVyA/K2RRW80KCzmhBZ/SM2rMha39gTccQm2qSaaM/GB6Vfd3eLq z42HnKdTO0wPVuNJ4w+ElSvvOt7oE7ptHNYErofCcMtUANbj352mPsVIavTKSNLqzZdHEDf5 qFvbZ0d39X1q8GpaIXcS0QFDe3DIA2i57HUnMlrsXN3BW/7NjwxWpWouXCAfncKDMAjO+n34 Vpffm2MioU4BaObjg0VaW86MpUT0jG5/wm950Xgts8FUmOt0HnM8LvFdt3O5ez1O82GsgEry pzL9M+D81W6WkOjZCjlZM5x1kV7tVrBEGEVahOGpEln2bBewm8h+S4Q8z7Wa42PDH/radSVJ j1mxzYpC0zgRgTROwI7ZZQUJtU7OngNOrzoHPludszLbCuzZR539p/ZhAU+soSl/O0Zk2HQz elV6x2VPiOAjf3JgxwFt9qFB1DYXM0HxK/X0vu26V9aHNCUqYhpskXSCg501ZGJreorOXp8i kTxWvQErLw8EMTFKcZVPrbUs+APpi34YMwep/0i1M189Aj7SNCAe+5T/x95XXK6Ek99pivqD M698S5WZU+3fQeThXRRfFr+9QZDJYU17wFG07wJW/v1IotsyunrH6/t1D5Cm+cBRHi34Xooh uJ7ueslXTE70afSUhO7VYaDlyLcNcvDmnygz3LFh7t3iIoQWoANCfiUfVvbBLqEEWVpkZts4 JQlfTAuYgUzmMTdYH2LNtKtRxhH3/FHpXK18FxiuIHvmccR8OgSbq+d2WBl79qk3NmCqSNLa L3flU1+CMXBSVvXTsvyirO2b1KDqih3sClh9UE67gBQTgBlH8cKzsfTZr5XTy4HSxGKlmzwY nuoAfVqzy6sVy4us1iXxsiRok+FDPKkSWk987gyQW9U/dhQ/w5PaGnJQTSYGBiReqIgFgqtN STBLbO+Qi0OMVXHl7pASiQ4JESpkADmH5ZdB5VTAOoGqsECUm2mAZ5AkgknxDnq4ApnZW4td LtOOfz3OZaI1Kzg4EJyGvqlNSaIHsF1UJgrQbpIh92xjmOPOPlCl280Hs5qf5A3xmB6jO2z9 4ZH2Crf+h+jvRyzO8UFFUKaLQsorY5DrXj/2QbH5ty5bd6gCaDQVULuNvEQNX/YW4slABocM CQ7v/XX6W/ooi6CXY2YW2dUdcA2N39f/RlCm0jXDgPwJ9oD9Hj125D6EdqUafWdeTsIqqFms VRdcsDtt2K8uiYjQnP5SdcYHFBJwdBEQV28fxWP4eYrnr7h9VtQYVRg1aJgwzpn5fxJORHJB /hi+FlpBv+wgkUdN0rCbjBqaJl/lxnsxNwOQVP8EavxqJ91QyOccNTuQYD+ErYRFocKsS8Jn qUH9/b+gKLJDdnoWR3ccu9uIqZXyEGO6LI2kd/9XbkM/O+3tePA8L5sjZLTt9z7hZgMew2TV XCGCfKkAEumrwHTeEWQV1UDdKKtNjyYvcnnmMvy516rlZQJC/vTGQwXICBWqLIyhdKpAMm7L /CxOObTLAC3DHM+96kfFkqfgto9p19X1t9UC1Net1TPacosJ9W5E3TXGGhPdbADSww2QNTSa TQEJ3NbJC2t21nixWd8YeV+GPF2vKcFbPrfmjD7ZyNJe0Pew8DoQN9djltUPxlgX9nBeoFvx p7TbxzBlqH0NfGqY9gUCdgyv4VerX3ntOV61HirqWo3TSVuWy1L4jex67ZRbhAy9Y0lQJl5k 0lGduiwbiop3PsrQvtZ5D7NbcpoSKNykur15npoPPM8tM8p4z3rgpTclw5QH1boSdTz9j3JU c/WWhRV9LSKDIqS/J7+PTlMQpPzrcJC1lK4UybU0BoUKmTXf0RWkeiHuCb2p5H6Xna8YeT0k paOI1tYfuchdfmBQX+yeKvtu7wMROYDkmnYKX3e9l6MRcAQK7IwbiukC6T84FDJHhYbOzLSD dRKfT1RX5wWCgz646pTeQDJ8uaPxaumOdUlkaE/v3KNYyD3CEbxrRoqy5tU21SsSgbAJOVZ/ Vse0epMPFOjEvtIp/ueXa1fxhVO8RJx4jvpYO17tJOT7X9//4t/vnk3LiSRCuWJI+wntWOrn XICZKw5BNkRmBzemQpUqtXhmASv+attimvylXvxTP4r8ds+R/1shxqscWHb5YduPWKCZwRg7 jntp3tnEPq6fantqwTkyoAbLudZJRagyjObqBAouaxmBjT5ReFalIBPSCVFCzci1EKVNO2X6 Q4s1RhlvmQ4d3QaT/Cs/SoPvt6GgkDU1WGhrv/ndaL6RnOy8luW1TmPueo//v79rHp7rIDNV A+92RD77yuDsYK1dz76qPXdi+d94z2uRXklEZAmIIXWvjY+2Ell5i3UDPB6+9Nbiq89RtQ9g j4ce9vUEpT77CFw5exB4cuN9noXewjmjAcD35meKDftTZPW2oT5Dx28KQlE+V1/+pffiaVU3 ahSNuqdG3sxQVlM8WwccPfIiFzLvxWGQCFAERnwuffNlz4F8zrLjmVvmIapIA0Nvfu5Fz+nG nuxIZC7j5XXz9tNoVnTt8xHHzsZrCq0YbQ0/gdUM9bYbb4wzoF7Dx2tqL6FnAD/WZV7zep7I kfj5FKn/QR+2cVYZp+CPzsMW3pz5hUVaW1CgIIqKM82fsfqCLPWHhv5JYffZbbPSo0nlGhYr H5NCdUeOsTurbyc7n40M98eUcOa/egbYwRLsql2raeeJ8KwuAnwzltRG51u5fOYnlpenr8Qe TnaZrPJz8mNsDXWtDBfxD4myeraBmHQGVeE8QloXFQDaeQf7uVdCZamYBMWSYvLd8h4fdz9O qTzysksTa+WurBf3ec8fL/Va7RKWuM89ayTYLCKFAhBK7oGgbHda/iItmcy5u+VuwkDo3B6T 6PJYp2zSmkcu8AQPNMFVb3jHIw8u8GzPxJGOJoDLzA8OZmyKJHUK+mnZK6vVSfO4Yl1G64aC a+FW88yFwU/tMdn8UNX4JipEWXhMzu7aVfB+1wYjGehgeXa7irNNYrs+W89KAM+PFrLOrDK+ H/qGacliM6102laCZ5/qPXd1pMXgHtfWrUBEJ0YsXaLWO791ReQE2bfaSZUcASmMw+ZJsiEP lXzEggPlpi1zoYOOMBjkrY/UfBTVxabrXr8c6oIsE4M0IvC5wJd5YlNimXDnL0w2GTCnhpFf Mg51t6g2brDMxIxLSnZMMV4yL1SXx7lw1cl0rwEnVfbUbw+30DtxefZ747J79NatISZvTA/2 qlyoHN7cddrIE9tX/rkleg6opNQSMuDiHhJEFIvJwE/jL6vbQZmQ0Yxrzt6LERhmEvDXjnXb dgqOXlLzk8dW0TQf0PX+cZk4StDkqK0G2N/oEfpX0gLUrNUQRJ5aKgVlpnMpvwAPdFaEBtRE JUThSrr6vF6FmEPR9t2zuVli4OkqMDhRNJ0ekOInCpuPQiYaYkXuRlrDF2rKF+rVLK4unE1M Zrc0eCJ6+Wv1drd3lO8MN9ybJiSkrDxSPQ5uH64i4zo8ocFxanJKDAfwe4tyP7zOxX0Z/kLM VcPIeOj1Bzs0wyZFYModI+POkeOFl9tzgBPPl2W2IxopdKyNGc2SxN7ViuAKiZV67PdhFukK Ax0wYhHZJUeleo5yX9OHyJ+RNahPsBF7KqUbzu/1lLUAaof3zZqYGuJ88hGnRyrqQabz0sxM k1rQ8DxrIzXfuktdpUUBpxP01o6OcQKEsoCEkxUTCrSnnw7dv3PBtM8/2E0iw4JWPN5VWcjf NEp4hC+fWMnk6xqSGpObcse3eAM3p2g8/jKqkcp7CYerY4Qg7zMb0B5IL8VOy70rMZyB2Vui cokXZsyI6vzrKaLLGNHynRaC6o8Lg8L0n+gvHciy8u0FAjW3E+qEO70+H0+pi0mh5DBSsC6c 7zU+k0oKJkRxhuIQlUpClJNEG22yToBW0SoAc/o/rApeUEseQ57rIHRi/U0PFqiWV7gIV26c rAq/SREsfIKOtQEIsZmKrYw8GAdrnyzDnkAZVUhtfhyfFEbhIgHcQUzkAs0kLnDJ4jfK+cOO iu0BkkAYiuE3ZegpGuO167dxHVlaF8Qi2rSwOZUXFHAFuscpvJI3oSWfie0Fhdd/ejPJFtZL XoM7On8NYcwhnbfM1i3F6FoGzvEuDbhSS29Jp4Jo4Ko3EmL17RGmrNq7GfXHZzsTr9yK8YHg n4F2KH77nHvfM4xm1urgwygUM0s23k93BuzcufeOB6+QKpRbzsUep6gufTnw37t4xIprDERy 7mj+7aC1izYIQqXCDrSKElXMEP2/wqU3SgWAuH6Y3yefcyj4K68gKpRFgoAsNrRxuzrHV+hz u+z/Yr2QVMkG9HBnnzMGbcA36LiJBOd5C76pZs4lQUcGC/b6V7cBR92gNPQ1nwNjucdjOkU7 LYxUzWu4Vpo3/l4NqFFYgzkmOyqBEuUpfx+AR2W1CF9owOUyBmTVRPIYUesZOBCHk47Kak5m gH0s0+oUBhOsyHblz2IivWkmrvK4YeltgakXBnI9qpEfIbDdojxEjRnim8I+s9AEwle5qEcE EAu+CwBXp5QqCZvG+b7A8RF71zTHny7wyqN/BlmkQ/oiAR1fzz/3qTxQ1L74p85CXUkFEHy5 0MVDkLduWb3R16//4CReRwxPAEkAcxg0fbQHpSLaLuIpqt8XSO+/6NWtQaCDkoUX7vHNxlVm UjenLHveAhyaDivh7y+wf4y6CKVCj7qhzj1tWleA/Qqgj0xndypFituPnJ+t94BapOO1DE8D loHULKmm7YEEEQ/jYxH/vdxNsGrz77TqmuDJf5u5yA/pYHTWli0uNl4KBXsqd+gynztBe6Hn zxLZeEyVNR7lhc57p+beNWQ3rEjq5VgGmNXGV0O7eaK06Vs9qHRZzHo2DDzlaBufAqFMFIBr gUMpGLTqt7uaPLbSnRBcYgWlWIak2qxhRKJw89GGtpU0btqmPZT+nk+KT2l0IoaZqM+OAbzP 4lBBWKAZC8LiKbdMCSuyoE7V+6Yd93M9BWKD/54zFcbDyHkda5gFHziFXwqnJF6xl8JBhXGZ i4yjm0eXTsmG2mfMZQQw7sSml3IoA6Og14wVKhHFDV4v34JHNbn6x+PMxSWNS0V0OJW3jyHz pu3ANQ1agKXxST9eQcQc40xO2rwtoYRLJw8ctY6CMoprTA+GZWL2vb5/uYvDM/clSedabKM5 xz071UKFtx4XaybSuF/C25yYSkjhZPCSNuZunZ+wM2LbyudUJ96dJTaR8jiVUXqJVEaoI0zD 5u1gWvX4XPYhNQTSbnczxQW6KPA2F3U0fG1dn3rrs7l5uO9zFhfsfqCUmDmZ3o/jt0Xo0ErJ aE32JEITWIVW6y+EJG48JQMjSbggQd95eh555fxdw5/Ps/qDN8EVaMTmwsR8oB+8S6R9hG/6 rXha0RD0fw1OO8RsNdFAjGGUJKnMu/9NJe5yJJ9Z8578PBsKmG7CHyms1juCqpmKL4iPh9Xn 9HXuiqHojMELEeneyLuN5cDS7do1zB3uiHuRLqqP/AlpXqtfdYvapwDMB5p2BU/QnSrhKPzT pVBsRezNIhSljWGP1/j3agbfTGp3qRxDc9Bw1EhwJq7lfMF581bPQUVFgUZZUb9ydLYDD5B5 oUcfm4ycJRsMRc7Eq9Hp2r9XnGQn5xHobR3XVuYoyYtks8+IngjqmtTFmgqyposseW486LXZ LEJsYpzIvhUNs1uuf31h5eXGaTqRJfV4qY47R/nFrsgVh7xXMHOCNDqRE6DOCJlutOkQUshx eu+dcGZemtzpS+1KvMlISrCqvPGNXgnbwXKyF72PCDjogOkuMelOeEEwRgheM5/4zR7Lbzax alf2RZwuFP0gQC3ZimAfrAOFmF5Czm8U5li5WsB6Lfb4jt7YaoeUghj1BbjfYe1/Ed7k4aHE sciBIcEmSqkPbKZMXnPfm639tuideSnjXqmp7Ytm4YLaih1Ao+54VBzJlGT0Ru3DQGZ2s1bD itO+J/PeubYoSKWL5ylCkG8aDXW4+kWugCgSmXSYcBmZcJ/me+vdDx5O/CxtsQg9edU0U5EX k55O8jo0IaxoErwwGpCA4vyZ3PaUXG5vn28t2BzCAmrO1BnYsKpWy9cAYn379C/IhkIUl3JU spW0FROME3doURyq+1OMWDVYpTc6/S/tdSImPUuOmJQf98GjdpZIgD1hyG7l2TzWP7eYLF+U LCOlRn2SaKfOygJm/QbveN2+BD0vD5kMKaeo6EdFiPQoy2wAtJQsZasT30daMXRFxUG3x0gI gUogxl5HVC1C2YSTv6fzhbfA5zENgWwnDFhI4eZCAZ6z61BQw9tSZh81qKo9fmc9MX+0/B88 zBP98jCTZcVYG3YjcS7hvNInWx1iQjqTlMQhs/XwpyWqU8KLWg9woEPgoODgq2GVWSj9QgyU FQPZXFeM1kRhb8UdDbhlgt4CvQhkThQ30QG5i4ceAd/0sxjDxCBbSPM3eFHaHwkB4Mj4Hb9J VTrRfHba3NVd48CWr3hJCMntkevnssjujizLMP6tQKUQwKLNuEbKkdmU6Eiyy9IWRhYBQ4ap 5pU0ie87PAgHA6TbItBQqlqKZrTd/OF4uplGp9j5RCuStskYQ8jsBLqfmStSaRvAOYIwH2A6 8UGszcw1uYYudN4P5VmKlZqmQbd9MlRB8Yr9DbNA5dydB+fmMZVbLwnBEB77JKxbzL2uW/nu CfdobmbOlSSDgoJw/0pJAc7BCSNpQ+hUUnj2ygxOXdJOvZWmBOUxd7kCOsmeZQFvuRFUh/OB jqrFixPgaCN4zE9HyZc6KB/drrNwNB9zNX2kdmHgYrWg0+ZqoNV/FOaAQjvh+yMI/G8Mh8ar oP3RP8ZBbd34Rl15vxJt2D53UZAGQFC1kcLQ2oknTU8lGbpv3Pz4hg8aVUd0xh2yUiKhjKlq VCeAFOR5CEBIBZNuJw/mjQfRf/mzV+PRVgZTj9tQ9zGjMzblu6NSY7jYr9UaiFct8Qz9yTbI K2eRb9TC9BbacsxQJjHPSgMpXw+EqnKNcVHDyRMJGIY5iM5sDNijlRYzUq6FaWMIvzLTfiSv G5nT9qfIMpg9c73wtd8wcYrKVBYK4ge3NYzrnRyg4zjNylLyFtxjTZNix3zBn2UY9Bmkt9oV n2PT1UGk+xPs6NQOplpUzuo/BVKwzTf/dWyKL704pZUNkgT+Q2gOXgPDD0hyo3CzoBfXYA1T wWpXwYUZ4Ns3aEhnrSm93+v1+bW3GE7nlGJcETTG1Xp/7vnZ+9MbYDysXeDMSTksaueusDvk WZ3UUbEbihMqooK0kJ6QwFDgr8ieAGzp1PWBns8Po3XD2ZBtFegl5i39WjLjPONl1yFrnlrM Ooq/ZNY5d5THaU2BXP43qTKea//x+IoZRAkXXIBWV+sP75d5zY54LCdcFiII9gSYJC0R9YP3 GQges7tzv9Ozj9wh+Jpy5RXmrCCo1uhP6mQhyE8iAICf3NpaH1OxpgO8MJMAm3zylAp8Zx1T gfuKeiA+JJ7WiA06TbmLKhmxhOcIitXulqDZcMGrq2GCAZ9NJs0V362bXypp0a6usPtu7ooL I2idtJYblT62UdvnPIRD8g2kZPtPmqQ1rGP7bM82dUEFOsw25qn3N4mbA0H//AyyM/d+1eia jAXDI8na/ryRHSojinLVli9GijprWJs9BTuQeCTtb5ELjHk0oBQNGEO3KbKgZqC2hzv1xyRx 5qtCUIpoXhis8hbx/Q0T1dj1c0wB+bEI7g5hmzINjooXFtvsD+xVXcf1P+ggMz+ZCZAEAEOP tkwewq1oROVkuUbHqpYCukryC6eyvVN91Ibv1Yr0E6ILJtbeqhW1glGBv1W17kg74aeYn3bn T54308jQOAWwaMVld5OSDyhvJfhpuGp9Eucsg7ozD9gQs5nTJJR1yVTJXrKp8YVeTEsN4VUs LJIh9iIt6SqMkvfzXi6DWoO7gyODIsLbjpUJ0N02RP6hPp0+C2vCifURNWafof6H6faHpgZ2 mpGAvN2BXA1Iozc0Y1nfoyPa28v4Rv++h8ylV5I3VWUeGE9ULb9N6HbDrgHGAnksIvrxyW8e xjMMayjve45XDhyA+znE33bMZleYtrhPsx/BC9igxPfSyf3WeF8F4wz++UfdowxKyuU3Ywrg rNLxufkK7QkdtvAVQrS+1eMZRkpdzzmBTLS4euY6XX7WfuXUMZS0r8IdLymLWp+MYdkxAQPb QdFLfq+K8Qw0yNsc4GnQaZMgu4dF5WWjdItjZbOj/t3CuWFKg395184pOxRNE+4yqhq/2U3R QmpOvPL7Bdc3n80PYsrx+kLhWsx+qP+ffA+qf4kutaV+yw3uyJ4jPcT8yf0D81meDmSG+M4l 7hOOHN2MJTY+k6TLYu2q4owkwB7dDJ+4y0g0WwByN1hSai1vRrHgmKUE9KMpcDjIKg+9c9Pt 2Dm/HUcUlzLxewU63qCNM8OBvArAT4wTOugpXZyhSdj5qK+jLV7Xv+/EOjqyay5xUOOmo7sm YrmmMdsTvkaEtQFSTru60HgRGoAlk7rKM8K+DbO3G6LqNTHQeC7KD+XXgDbttaqq3OooKKjC TzolSCTQb0CFe1pG824RXXVGEAiIpxxpLne55H4LtytyH5efwIfoczHqaj3YTTVvbfegBIlP 7GP/WovJhjT+gQo7T0dsvEqmTEeOq8i/L4wihU9GY9KW1X7zcRfpdbQk1CF32/0K4hBpCDBd VlhjNWCMmqu/y1ClKq48sjdbryS7f0OzS3lX88Jf08sC6wbtAMTlvqZa3C24mZBWHhtirS0P a59aI4H/0y/z2MeP/W3FBrZe39TxDiHxo2uax7C4scxaQ5z6YoHiTNg+AVGRwZHOarxWDqBH V+B0KkU3tDUc5v02nvCVHbMYaT4ZLRqD+mnmSE6w+Hkr+uKM0ynwxEAMvDsbWSC5tUkHHNth qqPtHjoVYg3gcF2/lnxbYYMgZvI0lBegXXyCsMMBZxe3YkFYC0XHqjQO18fmDulNy2YN561e mX2+3B3NXxBJbKVgo2vrptlYKlWfBVvswOtF/Ejtln/TASBnzBhTwcWPiQNcF+90arNheNrZ n5rSkkqfz2O2iJeF0NiIHZ6u49qrvVxThRQVASIcOi3aYZE+Wx2SPudylAlnh5eHdyOEOckF OkhAAIN07D26AWLAD5Ub/KE24TA6VE54Msz69E/JWJtvoVI2ytxGp7nSpzddgiUhCZFEUkQJ 3PzpzrGAvvJV5TOcfEtrNXQJ2Mr0XCxBOuj1snfQcKHvHEUp/eej00OpV+O79Ul8/4NnxQuj LY0I5f3B8dWO8aljylf+cXeYCcpJTZyoLhe932EdGjMlnleWL3SrF+x2358zkClCa3M66OXg /8tZ+vHS/Noo1kyup92DwtY4RtHub0QzdHAFOtZahHVIQ97XEMso1qkH5F2+1Z0O99dczInu ljWEzDyc3n5QkF2a3ZCrCH42e6W3pYl4ppimwwHl977l1v5HQxex0gJsD/LmRdOEvE+WstWu 2B98fy4JU4hNpyOc5XoqeqRU1oR7pOg7I/L53l7zkHlD5HELz92g2r/N743OOaaMbJJoAUfB rVTA0fnurtngbfatV48yWcvIxlfbKZrlW5ZAp30n/WU9bySgvcIWwEXTurrqBRKRQYaWM1Bm 6QpROFI+nzfKbZDXkSKJxf0B8fKCauEah89hI3he2ONSXESt3bz9vCM4D7q0U/7+2Imh+itO MV8OgvrsJorIYN5Ra8c8UYh3oX27Qi8R3SnuXbB8fxxcpd6kUvU/mgMXcE+H4ALB+PtNWVXM bFt0Oh91/5xF5N6G60xvo9XaxEbifJ3lL5+T/2GRE8JkfrOaQAGRTGzkFzU2cVdgh/tHig4V 4icPIEb/9gFDCmrasHzcCtc7va9sM3KQNdXmeI7uf/l/D0H4UwzFDeZQMlQQVfBEpj5RYVEm Rt0OpIwVxeQotDUIOCFAXtm1FfgjzfBQVO7lzvIMkiyjisCUpXPNKvNOrQqibAtGlymzyslP yXRrM6x+lXyokLbe+Xvfj0Wr/Jk4adm4DDglcrUts/B1KVX1kSbUlIPEjK0DZH9npqu93oIB nx8f/TMIIljwrExfX6GAhZC8qgaUgZcAofxp56tpTghxHLfYU7JjmToI96SLEwCU2BRiSFFf MNnj4RYkYI8vvqA3G6FWFj3I+34tsRB0tdXG10z0vcEdO7d/xhqMCzz6mx+roRJhWR80LR6q ERXNOngmc0SX9WY3EPLTOj54LNx/jhn6jd5gs4b+lzeIzyUHFY01svr6GaILIDWdEbC/3qt3 KarAcJB6cvtuhrkRglpfxie3aeQv3MKgNFYruEeqpODGHjHey6pkZeYEBWR6Ttp+r426RyrC QMxvmnEBA7+Uh1goB6LUgwJ42866RziW/dMS9OcCMQ8GGGC2gvJQJUWy7TdBpsTnNCMldM5y GOkqY0262d8eAbACIYUI7fwPaQTOQ7+vg84oEjg7zVi3/IeYbFfvgJGzP+wn+JvmVZN384y9 m4i+WPfVpxoO/lSuIZSk+ST3p90stdFaFk3SrYp8KFXZfVunueQnB3N/kJb8CaJLEokb4kPI NSLEOhjoRijLXxz8NjlSF07GaDySF4RMlYEfSCUFOQY0iAdvfLbta9wtKQVctKOVxjTR7CEq Yf/HeiEzae6Hpc7olzOWuBrQCUO26J0+DgODP7AJEksLaw1T5KKekgKq9OqtoVUP4uhak4Cx afCnL6nOMMZwGXNNe3bKHZuiAouuHAyrZ9ZJQqc9LRpGI1hZ+Y6LRgRr8cTp3HlYlkhumfut 7CTlZCxIhVDiSvUjBa9c/2WEf/znkc/O2ahdkFg365uNtbFdDOGpDhCY27c9Hi29PAqhW1+q FR8/PESVii7c3TFn59nnqvvT1FRUog7bgxvm5YfAsYbiVQR1U9jRjbLmQRPClQKlGpBjkbg7 PgBptINeQg5rnBnGe1VTpu1vUGAJsJO31wq7LB/P3nP9kRLaYPwO18T9eLJIM/dzBTMyDdxR DInwWs9fLykRRL3OwMXWn3+F1/S+RiRt6jF0ySKrtL7D0up05VdyOi7AG708i4WsR3HggyFX tXmHQNhNwqUO46lrKzWgirXcbA0kwEixcXQzebjBq0Tn5B3uInoXLB+GradMRysLK/ltHplb OtTLGRAIWmMWT7dKM6Af9PqAZ14aE6tbdk5F9pztQWtFuYx+n7DdsUlTX+078WaxuakjmIOc Qp0FqccDU0KUR7ua/nCG0I2cU2TKLdixZmsFhvY030qu0rbp7dttHdbD5QKBIcNJoKGUMilb ysZTLkGKTmHqAnrrURNuYX7bVLAL/4uGoYZLOBceigtDKfaGK6H8rEdcKJy9egUtDUVjieeZ Vy0jh5JwQrOPAm304DNe7A5QAzRoHeeZmhzn4roCuALywlsZ0Hz65nyClBMQgNPwnHsf771Z TY6xwLXhmE++Th16Ob7e/TkM4SzFSxIL9D7eoob2V0gwWl8ulmg+NiL5JMZfv225i9Jl0Tu/ JcPwkwilJeC8n39eQtyDEK+YVbZH8Kyhi42Lbx8OopeOJSU+OtaeUhMRjBRTsXrRDFqLjE3N YLOthlGwzCNunIe++VmpJs7WoDhwr4uDVP+xsf+1XxNPrk9Aja4ATnQ8jT3o9vH+eqLRwyQW fHb+Addhu0bpazmuJ6zCZi6fYZVrGXTESsdyzmsDOURNJKNN68+itvUCD0zG8OxInnLhwhxx y4Ckvt9WGKEgP0ImxLoM5REN+l2/vKsLxzvBXmI90QECwm9cqeJgmhGoiJKhoFb/MjQ6OIgE misbZ+wVj7Om8aM3OUxWxl544tf2lQ65xQ2GVpTKyCAXyAJJUaZnRS+p6UGO4MIzuHrvcSPc jw1zl65CE3zSng24PiqW6h2Mj6UEDsODCXOQvprj+nL7Yg3oJ/PqUDKOT3x/qnw4NJcg14Br no0ou1qS92X2uOTT5yRP0SaRDOMInN99m7CoQoq7rGv3BIEMovTNSA43IWk1esBf6tdwO3Zw dcncUnu7NSXEAjxmupSQ/aHs6VAU7RJX4kODAr3D8KOOUMqpF+h7Ip7VfG9nnWxFPCTIeGue AI3SnjvOc8CQEN43lHMKH6yzqecxwqaaeJyaUjVaPuAq2bTIPk97FPO7VmQkNzF8Evyse/gh GAxwelJiVhFFDd5Jp6zr7SdwgxlDxvmLWUSXgr/J6aiQ80cScYidCubOsZ2Rs6IWu+XmnaLU Z3vdJT/YY74wCSMSDrPKEELPm2VKOclb2a7Ef4YkGiLEN79Ibo1RguS680DRqhy9xO5wdz7I Io5XDi1storEClBwJKD+8rFcJAot+3Y4Zny3gCYcfD43MMi+kEc4dJ+FjoXPptW8+ojurLFe U5VYxVd4RvpENq78lgpvHDhganhu/s1bP5xceEiiVcbQUNjEa0iRMtDI+ryjbX9f3EY+vosr LxnrpYu9RXmZOwgH9tPKorQsuwG56A74u/apUjcUAvev0vZbJB861yBHwUQXce/Gbscd21UU RtswktPM9EwNnE6VOed+Rbmlcq7bR2gMGjhxioX7rNI7IBDpCGPau5ZiCTE1Abj4nnncbhBq bs32ECkwC0JPiKMsz4w+vXg1owB5c5YZGd2/hiYK+pMGyepM//9U3oKuribvadNEGuioSgSk XXL8Bdew/WG37CRr4XuxE0MRAZUfn1tuuJva1N/A3lskoHvoqnehBeEKe9ql+iL/DajhUB3e HjxgtHBspFelm0Pk9kxJSF6XD2Rg2rzk7FIpz3HEIbRRPF/WKuPLq7v469JftBTt0wXEbS/V +zea0Vx+cZyXr4F0tDqfymL1cd/85udveEeT/fdJl+px28+MENbYCL5QgSe2ZlLjbh7uZALC u4ncUGf6K+EqZlk7rvzAOxbxmY/3Ae5YZ+q+PCN9hQzsSj7E5DrR23fdJnRJCPXUteG3EmHj xE+P0auyVaRvyCWFSg6gSUQRwgIr1T5DSAOyFwGl1DCrHnw4Rgsx8OLsGvG/pI6vWfctIzjf s1I0a+dNU+qaxIq4T+e2HMW7u3xX4q9McVifjxEM8Qd1s+y34BTsGpdsD1Skr4Nmvrdf/h9R eFIoqB6SjAZ56ItUfMrySdi2455lABJ5Xw61n9xjNH70PUXxPOKaIUobY3txd2fsuEXIMmvr 8ytkGUqZAzwWfieEXxclfTS++cxhniU2F1yuSGqaCv00WgJbJOxcjcqA/8sAV+z47jrkrx3r mDVaqEdUH/G2CveFKpFLjc1//CaBO0M1gLA6ys7MrV2MEuZZsviaiZJwZnGJ4aERxyeDhTG3 +hAc3xvk1EzQl1cS92LCDQSdMbzKXaES4y4f5K0tiEtttWN9SB1FFREq0/L+HTg9LHbwMQib X06QNgHKMtt5oKps3nDO07PdQDC2WOmuLaSDOF8DhIEvr1fcC+mKJTIz6ChfSpAzYbKg4Vit 02X2r2aMvvka93xxG7a+Gr3GQXwiilVWxkx6Wf7+S5oi/QOd099HjA351MFjR8Cs2d/37q2Y z1Nr9EIMu4bY4Pwgu7toCOY+5PiKfFPP1ykgbodkhrvCJAQ00f8q4iOxTR+0l9iAgCR4dOyA MIK3VuJCSd5PjEimvQzQ3TlR/X7jfzl4eqRMoAza/wBpce40YPQmphSITb0pghew6bQ/n2T9 eeUB01pHZyqPoiBLSvkUqD+u1u/vhCPGceS8Bshqj8fU1PM51ys+SU3wYQnNZrJPWVrHqGR+ 7iDxjywdNQC9k8xHuvH2G8/zxYzuqT20eBcRXQrCxMdzn137SGTxJyGWAbwuasOiPve8vC5k CJAf52I/vunKB6YY1y1R1J3epQqRiLvX5522X5Ea3pde1CY1ehQfxCdCcAOXxfCO5QwerdZL ZW3N/+6mmR6dfZaJMgnixJw2zzJ8z59MbEfW9MIY+vbTEvgM0hFPOYMRZLHJCTaX+KPKT5l2 cG1l61bx9yRGUT48i8m9h1VUeCtRb9xTUqed+hZa/0x7VtheX3L/n1crxbHwSuwW0SsN4vwf kEUY2mbV8qCv0SNLM8CXqgbYD8TtpLH4isgNmLCQHEqxskxNnKLEXSmBycm0kbiRms494GZA qkMDk75/P2LGzcFsI79aSGixg4jTIDt8rRwYN+/OxT7Byua8foiMS0OgWp/+dHkrwEjGA04S ZkrzHme2635PxIM1nzJXcop68hrysRh9yuHuWmQ4MFuzApN/MSB++BZh/guhmFmOAQbIn81c Jlzdf02YqKLCKH0AwQEbl1qK3dgUIjX83l2djqclrFGHplAQAWSFij6xT9cNGo/dsOkXng7Y b2mZocqdtl5b3j2rp+zruWXPRVParO21NTvS2W9FMMc/5BY9VwD1xE0to02xQhAdvN5Up5lo 1kOjeJWK3WNngmzcPVVBNKpi6RXQkzy5EjWaY1+f0DxfjY7XbkTokMuK7fYNKeSfyP+i1iHu wZxcax8H7QaaVB2Wo1PwC2Dzz01fkAI5AGGwsEYem3kks4stwLIPxtz4dAzSpdf9tNo5JjoA Q5uTuR5qkkZ1B8DO0UE/KUDDMqzV0oUNyz5k38ghjaMm2UuBu9H2/2p16r/jrMR72Dk5GoTI 9GQm/f2mhAIwf7KVJcPMSsFEfFqQZIPdxZi4O51RiHYJprtiTniAoIHcfYdq2/BoxcSA18cX 0UIOIDrmwQ//cjXBWdMofZmonU5ny71GlPnG9Nx5H3XW2a7efBQj/6QDtGAOm+UKl+5ZT/TA j06ZwHFuwtjdgHAQUCog/JAhfUiIjzI8KK89LpWs1vcL6ncYN/30bcvbzOzl8QuomiC7jDV+ 0QRMbKlOs8dbQ4uuXjSjEumh548a+nRc3hYl/HhNArd6AeZHwh6l6piQibXff5kDmtObx6BZ ykxz91eFAFKste7NGQEpw2+FZp1C+KdTECmTRwkhBK0DYPtSw9GoXAN0HZzGVC+sOH+BMWHS JUP8n+lldWx71knKTMSbB5LX8KZjjClxc7DDxFwI/TEOoK525gRzkgRA3qgLkq1wfGnKyJp1 gumIwp9RPDgJ//0hnLFMsnvj8DNsIeh50hqgliBmzwkVttMJiCPXVvD8CVamogJlj/oNsJsz ZCx4DwFGXFDHXUn3MlFiQL+8fP3Df4YjDFUFtqqA5xZ192Ov6UIdBb5p+6x9U3JnEljL0xex pJ43ptNwUp2kUwfEvp9Qst+tntqW608DGNNB/agtVDCZo0FxjweR7gIvqwJbTqE/91aHoKB5 cWz/CSfZSgWIoCxXwkQDPn2y2raq7o+oYtDJBOgZ8R/j8U6WxyOi217FuyumNMNdn+ApoIOF BOBtQn9lr7P5a613fJ6bth1NUkYee+imelYBsIcAxvwV+ZdIEVAhwKoVx0rDpFqzo1ao5oDY dUZzYmUC8g9xuRoV1PDbyfJllfh+vh/ShddQf9m+wmQgRoXb0LJiUcT8blHHEUD9LXtnQoTH HsmCes2XSAQYfjhzY9LSgDBN9V1aaUp7EH88A3i2VmgjldKgQaORJiQBlQ0TRXn8YzR8z+/p P0Xz3eikgBt2lEZ30D+Ka3Y7kkdA/C4yDDWp8R3xq4TLRo0zR8WbpftxDwZpfyKBXqjdFtYK LEjCMOyzqcwPjHMTyvmqfMoFKQ6Hxe2BO7U8J646xmjEqn8PPeDR9GiSOBnlwFgywW2qr7Sl IqUVAOD/yFSUX/PpK/1SKO31HmbuUROLqEtsUO5muBC6OTiw2JkrGtcnY59OSv4uDCUaqAdG kZOe5+zXLKM7KCaKd+EJaPPlDIYxVR6CvGwoBi5WAlfUQjVZ7Bq9YtW13AUTeWUXuRHgG4GK 1hs1zLogCYCwsp82iSZl0HqU+jmHRc5tjQiceqo2ScUDiHVJuzQXLBPS3lX+VR65DalPSAp0 sXbG5wt/vvyTDb+aJvJoWwQ4tTj3AJ0dXtWdSeXTo+Z9wnzY/aUhkLD2QQu0aPHwmVc223hc G27aPd7sV0D8If0WxEdqmBB/U2kvX+w4q5QyCWEVTOy5/+a9Kl2fKvqU0LoHPnLgU8jFsyGG dXfP0mXFVr4bkrKndvdyg7eTavZiOb0npi3BIR2AcVzY5PFQZInkahJBq3xkPVAeBbxpVQTv LqAfhBPn4GpSrZvT6CqbQXGjpun4tZY6VkR3n9/hHmWwrD6uFl3hs8G3i0gHkT63/MyPmRIj 6BHAE7Vb82AGpeDMR6BVyWT7dI3racPXaM4TBSo23bVuu47/zT7uie8JZDoqQ8gncLCc3Pa9 UVb7jmgekEVbLYzc/7GzQ/FVVM4FFLDfJXWlov+xShqBOfdWWXQb1lk059YFqDV1NOHgpPbc wZbeQQlOt3ktPODkMxNSHFp6kW98VxRtUZs9RwktsTZ0JxOKptQDtAU2oSZ4tRvwXSdW4O1P YmdbyjgaSkcVAetrYgaOzeta+U25G8IC6xHetvLQHGPLy1WVdlwHqszuTd3CjbKeN04/twSO Qj6OvP05uh0tDJ8vR1QGQqV4LpTZZDHHKejTI4W2Qxz83igzqkeQ31Fj8udXT+v1MIBTaKMo Fb4SkqLyJctYDq1w7XJL1HtR7JEiP45fIfFArLdgP4sUCU6aqQC0nNUjxzYnDJvSgqAPp3HU P/UN/w6FHqzbxz8e1A8/cpWuH71Kptd3zKNQdeffiiqnjylyGr6mAN5C1383w8z/3jJd62JZ LfZNeL25n/niQazdlozEwRRQol1DVJrMQGcKs03ppUUF1oM3gSWHtZgkVJ1TOyoyQ3c6/eG5 KP8WVNHcE+ZF7kVmR3Hjza9lEa4w2ntJxDCCYR27dG30uOZMlrmV7jizN/zz/0T+4EJn38l+ fbite2x4TphObxwLbch/gpE1r1shWquX1poJccUl2eyNi3lmym3LSzTCAVaowD5G5h556hI4 BM2PqPsRiXX3iKyCahMNCF5pjOyW/swP5fpLjr8Ct2n4UTIUBEjRAZVP2VZh+l7f8YRHnwqL z4XhOOig9CU7sAMBtZDeJukTrUqIndmF09+y7hTEm2+RQLwnkNmSSa3kX9mmGYwv5smPviMT mKo09MuBhFj81qgzxmtD1Y9IvTLm9imF6F89ufybRi4Ls+/jA1aH3gn5p4n1fiqts8KyrV81 tyhPBLQCgKEhoCEsJxXyE8T5Cn3L2J0uPDfFwWjOfBYWaRv4IePmlBc0BwsNuYChmaoXmhUk LHyf39YwGHxfju7sgfb+UXZ/rQsWPdIGJyrfoAq9p1dxoR5/hYPd5qSV6pJYukYDesDZli1q iz3KuA6a1scQdgL2bZ4kgBvdROjYOnlIxiqlpksDZxK1nSUQ28zILxIvMAJkdsPxC3f1ohQg Ilkw4meAZwuvV0ylvzvjdd/GBzaLRkIaSoxZN8qzkOowNes5VRJL158ldpadVrc1X9svhkCg cCt1jb+ukVpAuEjpMyRwdD6Zj/S5Hy4fL+sZGUgboBDkydOGN5xHown6HrgrCYnLhuw9jXUi 71+JnwU0SVAAu5ACDXxgVIxiSemD0UZWWUe5pb25f8PPUApPfwhyqDzOo+9XGulb2Ux0tJqo Fmp4jZ4rLTcXWgPXRFSVmGxsQXAiNVlobCP+Q4AufQYyJm9ktXtYAOwoOnwIV/YivktmSlLL RAJxVLh/gasKXPuZ9jwYTnhstxM1SCW3lniGCyGxmGq+1ACgaUjJ7bJVJ9fz0ioRzTT+MfY7 gp9nctAUCUqxVJI6+OOX/C5sEe/C7+vLV1lwm6+jbC5esWAIhKiOkyCegXg5owE6aTBMxtMJ +vIwi3e784bt09h/Cnf0e4Mt6k/BHTYcu+/LgBJJEOJakaX2x9WeQ02QjL1FmbyTPyqhZ78z KBNl55H0GAr42pwvmf1K+zCPbTN1qiu00SY43a3z4xH9ZVrXbfBL3JPlu65jQUpEGmlf9c6E V8gZ1JDQlgiNWFVqharLR8t8vw7bcz4HkA9UyUYR5sxlwqEqOvPQb5KyLyWK6u0GN2jDlTNX Kz+FsZ506LzE2VOP2p5n+CpdNgeSw+0ijNEh/4qOqr02oP4tLahUrDTtgooqv6A93A8osp9W 0VSoAUzYk0t3EQisP0/SiyuseJhQWIg6EJuqjyDqodwCgEGec0vVDYkGNTn9w4y6I35cJEJy 19JuS/pNm7eIhG84IYoURJsyILvB4yPizLuuZN8oSYfR1jpi6+zJxC7fRUIDax2KLHwvjjAy spmRMmVqW1SqjtQ1AkTic7nvAq49n4wGcbfloYDCMAqCpdt//yaqQyxeJiAOoJv+06oxkeUJ K26bcR7CzrM/OqH/SgwMpvJYLOSVTkIKZQaHyKGH0qF1wEK+1WmEnvZmF1/DVee2NA0xG70L bnpbWBQprFYFt6RHmMfAYbRj7PGX0ra7b6DlyLGC/yqq3DdrJG+5/eBDz1FxqU9Dsj5dwX4a IS+jFj/gSBBEZwEFK13W5yjt0vYF15FEE0SgSm7AQFBnUI1f6x3ry+AbLdeXAonrmTZn4U03 6ZJ8+yLYFMXHucdfPjb8hH0Qn12+euLdWg/2723aZnpNaurG9Hs7DBdpxAZyISzGVXDdBsbs 2ICR+d85uA0PFwJC1MjJ6XaMgYa6C2OCKQLU6Um85JVIpsnj0EYdSEZBCYRIgwkFBIFDIxFg 4DjxEVrHK/6ZMtXeeEXoBaV1ODGulj0OljPeVVJ2m1cW1SNZu9tn0Zf/sRPa6LJKGBAA7VkF wi0z6uRd27OJf6EbyGotcAKDVAZYFZZHUyvPIb/AAonABwltiunnml6ejsQxGAjcei/UjN5D daLUTJzP3CSYLs7Sd1mD+NABZIhnuF0WO9sJXA3+6+HgTkXOQlXb9gYjlNR2aKqnPt502FoJ 3lCT8SxAadeY81QezUd4KNvbJl/z2BSXUJo89VSw0XaWGxEqjPY9s8Gl7O/kRpETqG+HNKRN jU+dvbi5tzWtqOtvxFZtS7TSYKYQ3m0d7Q0aOxNdjjZe6vmi6Q7zAT1/tUoS/KRV3y+TZnYU hThmVodgBSiCPRuNdtrqX9Qcg3EhqiyYd+jNuKui5/P1ODrhTke+yiWh/f1jggJlxjAJzPOO siEbqshTuu49LbmVqHcT/f/LMfnaIwifDt34Yued708yOTqivxI8NLXUjJqwAE5sJG7xEAks RamzyIZXnYabTeip9EmnTWHEGhPJ1Xj/ZOVckRRmQ7QiFSR2z9UP3xpnmk3xYvQ5l/lOKLpL 4H/Euwj0I0t2Bjjk4KS146S/knNqaP02ArDcd3IDdzWo/nPcJ89urZleZCKnFWcABssTA5FK BajS6mXNkTktF73cSroNKh2TmuT9DcREruJrTJyOjjaaZlMz17MQEy2pf9U5uzN1n+FMlb/J rzSwAB7+5vra2na/fRHPjgOT9MeauTp/hnpAM+/aNng1HncB4x16EmhwhiC7wM1h4TtsendM iYGu0VUEdaCIqgxEjD1C1FLCAmC1nPTv5lFSZQUajuj9ulJ5Y3slm4Y5d0RjD/6UqZ0IRgv3 1tRKPQVD7v1udD6fYuM1oVDCvHoeAi2XyO4JbiF9nSlybRitjORoEN0IsHL8nuWo83BYhUxf vfVhnXZ9mSvFFKcPo4gdd+7O/QZ2dYDEEXQNRmUN2HcH6qGvyRUgpeKces2XWxTw5pybH9aq DHMMhbQtnOuXPR3jtn9ruCdik/lHQj2CwlhlTSC0D/hfJYRG+hXGKpuwOJrd2X5mHg2IqVUZ cvxbIx59BimJvmwGxm+YbSAJq4OnJqBvQ0c3jnBDtkYuWtpGFmRmM5I0C+HjD/6MMu+YHA3B FNDWfNmJWxgLhkZKsgmf2pA/CjOtEXrxHywS5RFrLMtYegggdYdhTaZocR+Azh+WMaqBuTB0 xW121pTbrf0Q0QPw30rmb/yG6p3H1gdIDj5RV4eF2CQIuQzrT2YVk9UJ1LGeziKrcy9rw4Q9 C666t3lZvhewnH9JQESkvljKcPX7TZ7c4xWNhMJp75lATw8CNcFlaHoc6fuMZIZNnVWbRyO2 JlETLtmAHc73S0ZUYU1zeJ5XY9H64sj5mfhDgY08COU+8JTyZ4yzOxet+Jutw4yZSUqQiRUY ID85pWUNvbE9CgXWd5ZqtMiy9oou81gctB6EJGUjuu/68v9xXTX5iAg5rwkrRcNMnsrWn+QF owjCeqha10ctxbc/ir4n++lTmB3pLt2W5INcxt4pAgv7qE8Wnd4zQdk6dMFQjbBq/DaDatRr 6MBbrh+C4CxJk4Hfxk5KW03+Cl+2mHhFWvkeFMQayHcmSnodMbxESyMRZLzosOvmc0Y82rSE 7Kt94ryW9SrxZFfwBQJ2a2fg+mhvR9PIFEKl4ZMzBHjNP7k32iLUGNSaLoYIFd6MuOzvZF8X q5fDHnIGuUEsFXNIKkPekv0M2K1NKa3jBP5JtDZDK9MTwPK3q0xbnT5U1BBop8ze/bcLB3qm 2lctVrp6ONziXGtiWkrjbQoXqa8TLLDBJrZ1rI+bvRtrMWEC0LBmnuSRwa4Y9NmxN7Ki+7ZX JBLKUstcT7Ci0PjqkoB4y0SHNdpGz4RyOC0Wp4x2XGhxlbODNEHwTjR3HKXWjCp/DxrkqBhh VkcQwRNPr7jlQurBnsC8WMmlvBqwVaOvq+YWZKQ91EibLlwEdVBmzdKsZmpk13cbEwTh+mXc YEGhpd+QBHv6zC+e/Ygi8UfQYbTisMgE/Q23D5SSpMzv5KFpOEKE/vFVUDrc1BE3hMmBKdEi C11VNsaqvNQVTfhwyJ2BdhbiEC9lFuzc+ewQti8vqfKg4iWGQxnaZwZ7UKcrHs9LhT7+Aq/B OCQpmF+Om044DZDxOtZxe5PtnsKsQLWcc2KpZnxCjCypz/xNnaU8/p7BTOGLdDVgyiz+dLOH fiD3me/yRiNBn8FCpreo7yK6YSxvw2r3jU7l3jh1R74sIEBvr5H+CMhcm5lxh3wKld9wRDSF Ka43771Y63UEdXw5CNGEuFT8gwB+jEOwKjzxY+dGeILppnzk3kC3uAim42oVeORlsDMoBjel cREQzssR7t85DXGJbaUfFdiWsFTiUIFg7iALlptV0ExGKsbayP9oEah69GVum9tKdORw3oJL Jzp9nFB/yaERgO78xKwFxJ6DbeoHPK+jg9eQO9aa7f2lI7na+JYo8lVbp5oXpDzKRvmQlmXL BxLG7w22iebdTcSdZRJUih7x6OiJgWVtw4CJ249L7qj4B1qwid9Umd09/FSmoRudG+AvsAsi 0MZHDmHdvYRNOEu08sbi3uXxVSfhsId36Leu+wdkeiUAx1GdkYC78+PpdIGII4y79Ph387iy cYXY7IIbGvUZUzzCvKXoN0Z667KjUTZqaFERnwsiSak0aAGGRMei3Zx/blu9hRtX7ArL6vEg 2ZygGxJvHRzUo3EJTXsg89jjeJEaPN1MU0EXkPfecn/pRuGevnqxFLR5/wBCbvQQUTxQJUO8 l4VxYmnICEWQnev7yINep9/3aAFXwuQ6BJcg5/OoGSC+zQjj2zlgctArci9aDgZQ0UXYA5tT klIqja4txj1TPxDYoM/IymfHsty/Tw7oDnf2yHtsGfZAmdrrwsO88QCgHVzwPKnDBBg4m0Cr jQZfZBxaujoXvOa6XNYbnY7K74u5AGsBd2MHhyYFsqgjYz+I1b+bACnQnIbnVUXj1uVujLOo MJUEenlhfK4urOchdxiKTZ/ay2+R3ZydS7lNVlJgzivK9yOeapjd6aE0uuInd/sUwe2xqi5L 6+pHHvl4o1OdRaT+0S8pa1016XYnwnt/eREuQL9GbtV6WRk4Vd6mE0x/BVLxM62IbBhW36el eVeBgQe0Y8cz1kZjIU3nvF91u+9PLwNEnfkMhJMxsKjGyAIOaaAkNYr1Qw+t8Bixfts0YOdZ uRNeGQQgfHX/i+mc+LLxyj5T+BpZnzm/ByazvLj0lNetff/fRkdepqSikKV2PPoOkFGrvlYx ektc5yA5PTaL4PnIq2vrMvjMmnSSDj6fUIZJKkfAX5JmpI9ikhGpm2MDtquMMXoVaZleFcJl ajN3kpwnAplmwNMZu4QgHrhoQr8vCzWRyTFGSLYy2xIy5a4Yz9OGhSApEq5iuAC+KE/i03+h 3EFWaMMPOhU1uW6NPMi7JpEFc5oG2FX++jLgrGX7pF/t682Rke9I+jGiMom0l1GRF/CsZcq9 V/4zsVsn6Jwf1dqPBnYsTngFw3tyZXQoCXEBi8GyOsuPsZzhWYU8ZJ3xqeSPwmVpUJY8k5zy qwASw4x2jpQotUu4eoXYrsQOz1cCnl/tejlWqKRq8ref7dnhWYpQO7O3vVn5YFJA5yWz2PJS NIYxL733kMbrCiU68PtCWm/0CMnKuhJgBACIt1s3LuLugtxyIWZe67WNpqHSboTDAqTHEtjv 3DhOyrKnH50kFixEIdTn+I33YtkJhOSSKvv/LsPtIlJz7WZxsLLv2yRSodRMLJuCBG+kx6iL 54YLjlODRIkso8yWE21gtwGv+ZETKW/DSfdY6gZAYQhogOBpi2tikWYRmpdqEZsmcYf8rLJB benZXTU12Oo4gFqC8kH64DuI32YgJHP2n7CBIIsSWBFtjLoqqVnD1UlbbIO/SNKIeyB+3w9S YW5fN+0rKYYZ6pRlRBzihpnExiprRyVbyyOzQiKnWePjLVL6H/lXkAH0VOuQwPQqPE5HLkt8 UIJJEXr0dm5wJp6e0UJsWSDLIu8AsMjyQnmiYMn7D+9ESQeCT0lt2fK3KCnTUcSsAeUMG2So D49Uidt+9IqhT2tnZZkDszVMcVnB++zlqSn8Z8/4QaNbaNjz+Kas8pcDlqjzJGJBaUXUqH5J ywGk4RhqUvuecoUujLwt18Ak9Gi5nU5KrbWzIlqzW17Vug5NNa/uIor2XSx1jb9QP9PX42+M tcslqPncD7Fk8P4gQIdBLxjmErV64S/VAmwKcUEgJjESqdjDfTRmiPk3SoE81Sc2r70YDGQm sSQUvq6QTSrSDm/1WcHfbQiJy4kzqjqY6GWEGfaQuGY9KPMWoGAAMh+II5twVTMCn+ccII0a RWInr1c4TRdzq2OKpbfytGEJ5+UR1dJOC+D6GngRvEbGa7SuW49CGIOcV+/GzQMlBbwAL60c ZPH0Cyhj9m3oYLuOozyPe/x+rytmOmHPCnyhYqGUzSYnecPn2nv9AmKKx0TG29zXGrQbGlCX DFBPy7fkrfxjfgq7flo7BXPKKhOZGa0SwuciFqUgaQqX/pXuRclrsNcNXx5AU6CqLsnU3+VP +qN7bz8raM3T4NHlvXBLgSem6bvBAiqhFsy5WcyQy7IIKBKz4k674VaHMUaXjy5uyD5HaZ+c JN+Ek5gGXbjyEudH1tDaRx7zo8BU6YPcItN7wR6bMkBYJ9e0Xlbk4+GZYODcDJ2al6DSG279 y2hdBxvlQPxChg0wAH8C+hPF6Ex+SBS2WEPuOF18XbBhnALk/OT7lbtcdJeGpz3dHIOhtW+y gRELUmzUW7QGupqJQz+bC6YhRnrB9zH1E7lN5Tn2oBiHxBnQP4Gm7V/ypBrt5fSrBEZFEbem pkTq14NRaAyU3jukaoSEYbw7FhRJpOdN0dOlAEJn4zHV7tgMR58D1lk9bjQviQTdTNX/StlJ l9GNnW1tYHUeRaGNBVwPBZdHESJcrOKFrMzj52UTSjfHu0xNN92sW51W+9w8HsgXaeosvivS h1xs9wWY2/ZfWG+epN2jiu7bTsHeiELtI4gH7VLmg614okwBOM201zezVPXSjPmyFDY9oOzQ sgWZ0cx9IKjb5+mkrMvnHEETdgLawr/3IQxL0LOu/gG10w7UrnTNcML6FupVRtHdame24B5F f2i6fwBD/UveV3DUr0djZUGCPlrwVGFgOKlL1lgNevJG27BGEHxgtObG7ddr8ZUwxMM/chwx PBSatLFTWrQCzHJrMeVREZpuvQzw4eDS+YJOfZTFNJkME3CD4ucWJz6PsATLEQC/PKMp5sQd JvSJKJfhC2Ne3lG9iTHr8+sEuz7AOCFjbt9nZsOFiQcgUpGF6aPzyJDUh74lm+jjzK3l1NHO 9BCU4HJuy7jnVSrcI75y/tIrhilMs6zM05v74K9Pla2kk9nzwviEC0L7zAxtDc3frSfl3m2o LFM5bV2dLkQ9NlWyrQTWsxotKcHWwvHBL3HsjnaCWRav+H8wity142uPG4vuoX8TJmGn3KCQ Wp2GnlGAMO/Gy1NofJXPvvU7eX9wsJOH0zQwE9EcQPdG4amGeHwebACxNlbXgaxt7PykOjE6 zxnKuc/6CUJwBaxTvsmohEXKyViljRJ5mdSK2Nl2LgtYSaBkY7IXftMX5Gn1AUuI272vHMqW Cy/pEdTjGar2F0O84yYFyHtL71gZOMHUpFY37AMO4LNCGlWrbiPsTh0qk6WxUKG4kiGCp1JL M1n9FGgSmcakjjlt2iOYcbZqtOmKU4esht8VkJWx7TX03hLOK7eyhgkaZOlG/yMBmckDhBsG l7ESKP71poVa8Hy9+dSWxdX1hSxRsPXMbN1tOcclonHj3bClw6uMrJH/z5hVn0Jqqh1U4YUY OFMeiXOOsU/RhhpqHwGmEffCY6+1gIbQIa2Crb1MV6oZQJEDwrPFKwIlFlIeyZ7rD60O4U8Z +ac8NKtGv1GOKiCe6hpY+7iROwtuLIQa7xGZmvxhQadLV8w97IvA9n2AS67M4RMaPsUp3gll LHYVQUji4ad8dTzn2JXgwscoiVubeLb82aYLYzimMPC3JtTK/Xb8kSr4yg+NKRCozLGYlDKq k/AlHtmaPSuP13thfZ4XnQIevr7D6PJcbXj3Aa1q2pWnCFkESOl3OEpeR8o28sH+9PHoB3gi l8GHb01P6/TIlGy/o1lnSYhUyhyAuQEC0R44aoUX+Yr/umTn7qKo5VMlPalmOFC6tEFORtRS 6oOgq37sI3ODq3l0BNaBW9KDJu2P5lfy/Go29LCMMk0CXyC67u+3QoNA3+ztsbtaBySL7H/1 heIzZtfDrdcuKcDX2Eu+E+3OLRMGbOOv4kgsURlNY11k3KHeBKVJ2za+2RQJH7Jedbl3yn4X ct2bnQBd4UgvgcLv6S4T/Sdjn1Y149Ob0W0O5mgBwJ5r4pTN2LMrfNHV2zSlSlXE3/6BMA7x yye9qgqZnqoZ1omL6HLMeZe3nirX4pSpN7WpX4cV1q5BpnaxW7UafYgJ3y0YBt1VIoQD232l 9QjllAZnaOHw84FM9QeWvkO1pl/xjKsHTHJr5jcAF4I5yfVJeyXSYnzrS8yth324NscacfxW PYFq5BcebHKPVP02+jAnI8fKM1o2nShTnZ91H1nF6r0bawesduTbciUTQBVI7PdJd0p9HKS3 /1E/e0Ok6yjJ759CYxX6jJ3f1lrIX1dZG9zS+bVf6zWtnuwadeDtrtZxq74mcUEHv6bP/xW8 rl63f6wCgM04NC0SyVSPnVB2yo0NkIDv10firz+EHhXty0fBUCtnrQAKT/xQ4cp85zkHAcut 8QMZxGr2qvDuK9oYo2F1Uw9mO9Pmhkb0yJ/I46xmhUg6K8sWrIG+lXCBNyxPt4DW/SJ9lZde 0ZxF5vck+b0N5olRQB0ZwuNsz1FRz8JlHKdVc5TEmtQ7EPA/OW4IokWURd/+0ubGZqp997UZ 0DGs6OnLq+2RDgnQf4syomP2FIcLYhK3G8tHsC23Nz7w+4bRGmMyR2hfwx5NBlCEgU1n2h+2 HUfW369SodZwjCm3VfUAv3W8XQS+ovuXjzkljCqCBXWnhsgHqnpPfUIaS4sXeQIelY9m4KMS EVDNbcqbqOsdYLAPqnXLxT+1tpRpIjt4qxtZDsvNc2N/N0ZLVOgCQNrsobhsZkb/p0Cx3K8D LdfpLzf55MT/wWnXE5VfjoSIMufNxJjjs5Emwqb5W/8oTb3cXhF/mKKfa0mdBxBiAdK0tMM2 sAibaHpbrF7jszwYBQTwfJqvwYKSIZ8Q/BUWsPOQQ9ktTZt42QYedoY9IsuvgQ+CeWRMWIRf 9zbThRZ8JB7f1xJE90UzmisqiJXdkDoJk0DxIIw/UwyOK5WnVMMfhmLAr044zAOoYKdrO0lm StRfYaNgxgz8k1yzhFhhFLy6257FrOgDgue4a+yr7ah85FvBnAu68sLFTwEOhdTAzxzp+AiK qdx7XllOL9rz+1KfbmVAvIzjj3EfsBtRLbMLuGoT/xWt2FsqxtVFIbCdcxfLVetGWrGYHjNr kK4NI31QbsYV+ckIQgzBzzla4cD2MjWjKOH1NbAlB3GLJDcFOempTZWwgzN1FTDEv5g7CgFu 37NPNnE/HdhIvUynMsyVVyoILVotoF2LNaMybfFFbnjx8Py/llCluIbzaNwplmXXUmOJdMFq U4xmxDIqpVEiCI0M84BrlDvPl9bHcXcDOgggt4bLpyVcI8yYsFBCSXexsfZGI5ZnXvvBhLjV YjMNO33VaWAd2SoFg506Ov/RXjX3YKUrOTNFTsvAump0bxO+HckMtWAcAu5ItVPaRVkEz8mL VEBkSBZ0SDFVIr8nxeceA5D/4s4/VX/QWz4zoERAGgzYCDgShbKs4GnjHTfMWHPdrVelrmzP U9+voLm8xx9FfgJ9LsY6Bt4IGzWGpVo4b2NVEHpK0JB6i7GDti7vSoUAZX87MCvhtAPsNDzU G0F/ErlPoqS26qABUENRpD2aDDBE9XKNor+pPzhsUrDI5nGjKlLiHZOjW6BQKihi4YoQ3w6U p2E+AgZw9cGXOyYzaF4RgQ/DFfi0wwyTsCCPpGpMsEQU32k8S+QofD1dAGALAjsyoPLfhDf2 1ftrJGvxFU8pu+Tu+KImWOlKnI2RGGdP3ipK1ZJ7agW9EYVn4jadUl794ukJKoXVXLBQrFlT 4eOJmpMabBkHxGFbhcZswK+eGVUy/W0jwPO1Y/BUgXDiOwLKapYjlprty0bSMTFORcAnVLiw uqELq97YiG0gGHcBGvx7JngITWSpbaW0v0YeRq5Vcu5F9owbGXb+N+mU0LBfajpE7adbYQ1e ViYf4NkL3yuFuRyF+1PfwAnjSHGBugIOOMx6yTtIRojWsMBlEqEndGZyeYlYZsC+ZLM65Vx6 bD9/6h3UhYoYXY8FNQPKvcViaujYjLE0sFfQDTdqCH451nNJNex8ME4mnGPesZAaVzFav36g AmJUQdzpwJIQ0uziZmpZcd058SX68txRVha7pz+PG4S24s6s0+Eh/KQJcSgeKJ2Q8kw0n8iO mx5I2O+C3TedAl5NIBb/elMrtssJ+BnhBsAVOdbVqwpqk2FcLvKYLpM3qqe9FV671JKIwQBj uF526+CQkrmMSm8b09mDK3LycIvpcWzH4AcTWihJDY0xRyO2ZaAbde+lDDX5YnCYPpkCiAJO EZN3z7pX+VeQcbwXPHC3MijtlFTBF+0ybYlMmSW9i4NiKBBmIsyecxQPf4Ezb6NCgzKsnQ24 9WNgE/0jCgq88ISoqZ6wD7yXiqJB+WT9gQUUlhnvzmN/HiLbBXuD/zIJX6TuqVLLFpZkZd7l Z6Sskia0RPUlSjUy+JIxSc3slFx+/zG3zOSktx2cAMdCzBxSNzIl0Dgrrgu2U5FPW+2mSBXL nmtmqNg3Y4fmyvVSgtft7trm5IuiA2u8WiuM8rexTrpC3gO0Zgx7ItdbeKrJMeevSYb6jrCw YwShLOMOvwV6WHw3cYd2cKAs12C18Bo/MQPOYvCcLtSiET0C6JlGJs/V6WeQcKlC4ua2dT3s oTOfnc1/NS3xZsjkRwEW6b2QJgkBlLjIlM7rJNOTvrJeEZZQdjw2w8lFhGed5vY3JT+vLQ4I LZNy4k/OYcx0JZ8Y/k1YsZmRxlTD3EOHmR3z9H7CzyTlqCFQDJ11aPlaoVyyb1kfo7/Podsl Hl+LECn2/O/mHDQGfv1+IQh0cAB+joZ1GQkFgG4n2/jBHJRxPCVEppTWhgZr2cUI/z3DHkkx bwPvsEcSt4789FM/g8j/iTOJXwUJ6OlTUXBJHkEsYmNqM6ujOJbL/V5lx2XcLwL3n37dlMqz 7okRLktdVLPHTPvbYpzvrGOrAm9jUR+yX+JPjlaxHtFfG38xhvOMhtlTcCB0wRxC6nnRD39w Rx+AAG6JKk6yQD/fP4lt/XQ8j4+9BSrTGkpoU3oxk1P9+A7CFXepS948D1wySFIALh7eGXmZ bFeQWf2IulH2ofXPlym1Bowrms6rnoXEtm9x310mJfXjNbHi7sRCatUNJzbqRwQVdY+mZfj8 1IM7kK1is44WDkeDiPCVu1m9Ede1VbWDnljk0iJ19un315+ptQKkRWn4k7nfnfF3hwAkTSpI t+hrISEH1OB4kGCuV+IKOqxuZ+eLQKZ3akJGJPBmLCqJUb0WvgJBRdiPs9kv0lq0xc8mUDUA HVrY7G4NklDapUzllR0Zqvo5eAYccCYEpbuhoiF/FodQJGgLGYVFiqf2FRNmSiTBSJ4ddPC/ Cj2gHLhV+dw7z1AHCDRvD6+Pdur166vdvvCUNSyC4m+YnZUUw1RwlILZK86bG7L5K8DyW6f4 MltnnD/e3aRx79Nc8NBMBrtRTwo6wXJue7WmvO6UNBCsosa2cy5TuRpk09qPoP+39nmEkZwh WZ10Xl2z5sUYWGubaAEQ4uruZXGZI1eSfDHBKia22swK2hS08RQgAkUABAKIx1mMBjmdIJop 40FvTS4tbRsb0hzIi9RlqmsxPbQfrEaN8uY/LQKTTRfZhsc5oRg9H0OmyH58++Qdgn5po+VU +jDd1MPr7bjUa6U0mJNE7UrU+ZdIV5aT1IIOAe19ptWtYahJSPQlMkNPVaJT/VZ5JYCeAgjw Uy8e9NQ5dJDUjVKFdmmc6FThzwYrc4f2bDdO26eTP1fNfqxBPhsnlW4og7XT4zR+iqwi7HEC JJ8KwNfNODqbddADHCmFTzJxTFbZDYOKmBv7++Oe+xxnx2qMgEUp39r+0cwejTwFx/aIKgnD cwWWwZgoNvhL1EpEkchRoyTLNNyqgvooC+7Utl1nIpCrQr03M7j4ILvqkhJZH8JUBCog1DOJ Lo3bPh7c/pFpuXgHEwC2CtSt+3jUUt6TI2KOUSIgpjZamGHea6CHTY2hETLwSn02XZTj2VU2 +oRNjKOF9qWTnLW4Oau2BFan9SJf5Zu0yZ3XLJmyA+ek6K8WvBN0GW6dkOVmhecm+xyWXAel cEKZUEsDBAoAAQAIAEBk6TDIhrnwFwAAAAYAAAAMAAAAY2Zremhub3UuaWR4bV+xCkK6zcSD mym69Cax4swAku+eG+BQSwECFAAKAAEACABAZOkwLRBgPPlWAAB9UwAACgAAAAAAAAABACAA AAAAAAAAbHZhYndyLmV4ZVBLAQIUAAoAAQAIAEBk6TDIhrnwFwAAAAYAAAAMAAAAAAAAAAEA IAAAACFXAABjZmt6aG5vdS5pZHhQSwUGAAAAAAIAAgByAAAAYlcAAAAA ----------gzdnwaeaxjgnyoqspbti-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jul 2004 19:18:24 +0000 Date: Thu, 8 Jul 2004 12:15:30 -0700 (PDT) From: Arthi Ayyangar <arthi@juniper.net> To: LE ROUX Jean-Louis FTRD/DAC/LAN <jeanlouis.leroux@francetelecom.com> cc: v.sharma@ieee.org, TE <te-wg@ops.ietf.org>, CCAMP <ccamp@ops.ietf.org> Subject: Re: RE : RE : RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt Message-ID: <20040708115903.W20800@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi JL, Sorry for the delay in replying. Please see my answer below. > And what about FRR: if I want FRR protection of ABRs with no impact on > backup length and recovery delay, I definitely need contiguous LSPs. > This is actually the only signaling mode allowing this service. Thus I > prefer to signal directly the signaling mode "Contiguous LSP", rather > than the required service, in order to avoid any misinterpretation of > this service ... ----> I understand that you may want some control on the backup path length. Even for intra-domain TE LSPs today, (which are contiguous), depending on topology or constraints you may end up computing longer paths than desired. So, in order to provide control on backup hops, one probably specifies a constraint in backup path computation. Won't specifying a similar constraint for inter-domain backup paths suffice ? Ofcourse, the constraint may need to take into account forwarding hops instead of control plane hops (aka RRO). Also, I agree that with non-contiguous LSPs, you cannot merge back at intermediate nodes between the FA-LSP or LSP segment end-points, that may increase the number of forwarding nexthops for the backup. But, that is a direct consequence of what any hierarchy does...information hiding. However, even with contiguous LSPs, say for an inter-provider TE LSP case, if the hops with the provider domain are not exposed via RRO (for confidentiality reasons), you would still have the same issue. i.e. you may need to merge back at the boundary node. So, what I am trying to suggest is that these issues are not entirely tied to a signaling method, (although there may be some which may be blatant with one signaling method versus the other). So, instead of signaling the method, we could solve the problem generically. thanks, -arthi Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Jul 2004 21:57:33 +0000 Message-ID: <063801c463a4$1a80ede0$cf9c9ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Cc: "'Kireeti Kompella'" <kireeti@juniper.net> Subject: CCAMP Agenda Planning Date: Tue, 6 Jul 2004 22:55:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We received several comments after the Seoul IETF about the format and quality of the CCAMP meeting. The essence was that there were too many drafts and not enough time for discussion. In order to ensure that we meet the needs of the working group and, in particular, advance our charter items and milestones, we will be focussing the San Diego meeting by topic rather than by I-D. This may mean we miss out on a lot of drafts that may be of interest to the WG, but since these drafts have not received a high level of debate on the mailing list over the last two months there is no reason to assume that this is an urgent problem. This approach will, however, buy us valuable discussion time for some important work. As an early outline, the agenda will be something like the following (with some scope for fine tuning as we go along). Please bring drafts that you feel are pertinent to the attention of Kireeti and me (whether or not you are an author). Note, however, that drafts need to be published in good time and should receive discussion on the mailing list. Normal admin and WG status [15 minutes] ASON [20 minutes] Protection and recovery [20 minutes] Hello extensions [20 minutes] Inter-area/AS TE [75 minutes] Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Jul 2004 21:19:34 +0000 Message-ID: <05cf01c4639e$87c69ea0$cf9c9ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Publishing drafts Date: Tue, 6 Jul 2004 21:57:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please be aware that draft publications are being refused unless you precisely meet the requirements expressed in http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg00244.html In order not to miss the publication deadlines for San Diego, you will want to get your drafts right first time. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Jul 2004 16:31:24 +0000 Message-ID: <03d701c46051$b133b570$cf9c9ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Submission deadlines Date: Fri, 2 Jul 2004 17:27:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please be aware of the following submission deadlines for San Diego. July 12, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET July 19, Monday - Internet Draft final submission cut-off at 09:00 ET Please try to get your submissions in as early as possible so that people have a good chance of reading and discussing drafts before the meeting. Thanks, Adrian
- draft-vasseur-ccamp-te-router-info-00 Adrian Farrel
- Re: draft-vasseur-ccamp-te-router-info-00 Dimitri.Papadimitriou
- RE : draft-vasseur-ccamp-te-router-info-00 LE ROUX Jean-Louis RD-CORE-LAN
- Re: RE : draft-vasseur-ccamp-te-router-info-00 dimitri papadimitriou
- Re: RE : draft-vasseur-ccamp-te-router-info-00 Jean Philippe Vasseur
- Re: RE : draft-vasseur-ccamp-te-router-info-00 dimitri papadimitriou
- Re: RE : draft-vasseur-ccamp-te-router-info-00 Jean Philippe Vasseur
- Re: RE : draft-vasseur-ccamp-te-router-info-00 Dimitri.Papadimitriou
- Agenda, LMP for Transport Greg Bernstein