Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00

From: [email-masked]
Date: Fri, 30 Jul 2004 11:53:57 +0200

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.

Delivery-date: Fri, 30 Jul 2004 09:55:51 +0000
To: Jean Philippe Vasseur <[email-masked]>
Cc: [email-masked], [email-masked], LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
From: [email-masked]
Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00
Date: Fri, 30 Jul 2004 11:53:57 +0200

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.

Delivery-date: Fri, 30 Jul 2004 05:19:49 +0000
Date: Fri, 30 Jul 2004 01:17:33 -0400
To: [email-masked], [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00
Cc: [email-masked], LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]

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

Delivery-date: Thu, 29 Jul 2004 19:15:25 +0000
Date: Thu, 29 Jul 2004 21:12:21 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Arthi Ayyangar <[email-masked]>
CC: Adrian Farrel <[email-masked]>,  'Jean Philippe Vasseur' <[email-masked]>, [email-masked]
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt

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

Delivery-date: Thu, 29 Jul 2004 18:12:14 +0000
Date: Thu, 29 Jul 2004 11:10:41 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: "'Jean Philippe Vasseur'" <[email-masked]>, [email-masked]
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt

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

Delivery-date: Thu, 29 Jul 2004 17:27:16 +0000
Date: Thu, 29 Jul 2004 19:25:28 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC: Zafar Ali <[email-masked]>,  Dimitri Papadimitriou <[email-masked]>, 'Danny Prairie' <[email-masked]>, Reshad Rahman <[email-masked]>,  [email-masked]
Subject: Re: draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt

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

Delivery-date: Thu, 29 Jul 2004 17:01:20 +0000
Date: Thu, 29 Jul 2004 19:00:17 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Jean Philippe Vasseur <[email-masked]>
CC: [email-masked],  LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>, Adrian Farrel <[email-masked]>,  [email-masked]
Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00

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.

Delivery-date: Thu, 29 Jul 2004 16:56:33 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>, "'Jean Philippe Vasseur'" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt
Date: Thu, 29 Jul 2004 18:53:27 +0200

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"

Delivery-date: Thu, 29 Jul 2004 14:17:07 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>, "'Jean Philippe Vasseur'" <[email-masked]>
Cc: <[email-masked]>
Subject: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt
Date: Wed, 28 Jul 2004 16:13:22 +0100

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"

Delivery-date: Wed, 28 Jul 2004 20:58:33 +0000
Date: Wed, 28 Jul 2004 13:56:39 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: Re: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt

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
>

Delivery-date: Wed, 28 Jul 2004 07:30:38 +0000
Date: Wed, 28 Jul 2004 15:25:31 +0900
To: Tomohiro Otani <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: ogino <[email-masked]>
Subject: Re: draft-otani-ccamp-interas-gmpls-te-00.txt
Cc: <[email-masked]>

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   [email-masked]
>****************************** 

Delivery-date: Wed, 28 Jul 2004 01:45:23 +0000
Date: Wed, 28 Jul 2004 10:44:24 +0900
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Tomohiro Otani <[email-masked]>
Subject: Re: draft-otani-ccamp-interas-gmpls-te-00.txt
Cc: <[email-masked]>

--=====================_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.&nbsp; 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.&nbsp;&nbsp; <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.&nbsp; 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>&nbsp;<br>
<font face="courier" size=2>A nice short draft. Congratulations!<br>
</font>&nbsp;<br>
<font face="courier" size=2>Also, it is very good to see SPs bringing
forward requirement drafts. Thank you.<br>
</font>&nbsp;<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>&nbsp;<br>
<font face="courier" size=2>For example, suppose we modify the bandwidth
in your MPLS example network to:<br>
</font>&nbsp;<br>
<font face="courier" size=2>&nbsp;
+----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
+----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----+ 
<br>
&nbsp; | A1 |----//----| A3 |---------| B1 |----//----| B3 | <br>
&nbsp; +----+&nbsp;&nbsp; 10G&nbsp;&nbsp;&nbsp; +----+&nbsp;&nbsp;
10G&nbsp;&nbsp; +----+&nbsp;&nbsp; 2.5G&nbsp;&nbsp; +----+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;
=2.5G&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
=10G&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
=2.5G&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =2.5G
<br>
&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; <br>
&nbsp; +----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
+----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----+ 
<br>
&nbsp; | A2 |----//----| A4 |---------| B2 |----//----| B4 | <br>
&nbsp; +----+&nbsp;&nbsp; 2.5G&nbsp;&nbsp; +----+&nbsp;&nbsp;
10G&nbsp;&nbsp; +----+&nbsp;&nbsp; 10G&nbsp;&nbsp;&nbsp; +----+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPLS AS
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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>&nbsp;<br>
<font face="courier" size=2>&nbsp;<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>&nbsp;<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>&nbsp;<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>
&nbsp; not likely to be significant<br>
- we should, in any case, specify damping of computation<br>
&nbsp; 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>&nbsp;<br>
&nbsp;<br>
&nbsp;<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>&nbsp;<br>
<font face="courier" size=2>Thanks,<br>
Adrian</font></blockquote></body>
</html>

--=====================_7216640==.ALT--

Delivery-date: Wed, 28 Jul 2004 00:13:15 +0000
Date: Tue, 27 Jul 2004 20:11:28 -0400
To: [email-masked], [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00
Cc: LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>, [email-masked], Adrian Farrel <[email-masked]>, [email-masked]

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 : [email-masked]=20
>>>[mailto:[email-masked]] Envoy=E9 : jeudi 22 juillet=
 2004
>>>20:43 =C0 : Adrian Farrel Cc : [email-masked]; '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

Delivery-date: Wed, 28 Jul 2004 00:08:12 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, "Reshad Rahman" <[email-masked]>, "'Anca Zamfir'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: draft-aruns-ccamp-rsvp-restart-ext-01.txt
Date: Tue, 27 Jul 2004 20:05:48 +0100

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.

Delivery-date: Wed, 28 Jul 2004 00:08:04 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Zafar Ali" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, "'Danny Prairie'" <[email-masked]>, "Reshad Rahman" <[email-masked]>
Cc: <[email-masked]>
Subject: draft-ietf-ccamp-rsvp-node-id-based-hello-00.txt
Date: Tue, 27 Jul 2004 20:20:48 +0100

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 :-)

Delivery-date: Tue, 27 Jul 2004 09:44:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "TEWG" <[email-masked]>
Subject: PCE BOF date/time
Date: Tue, 27 Jul 2004 10:17:52 +0100

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

Delivery-date: Tue, 27 Jul 2004 09:44:19 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Tomohiro Otani" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: draft-otani-ccamp-interas-gmpls-te-00.txt
Date: Tue, 27 Jul 2004 10:41:28 +0100

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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>A nice short draft. =
Congratulations!</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;=20
+----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+----+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;=20
+----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+----+&nbsp;<BR>&nbsp; | A1 |----//----| A3 |---------| B1 |----//----| =
B3=20
|&nbsp;<BR>&nbsp; +----+&nbsp;&nbsp; 10G &nbsp;&nbsp; +----+&nbsp;&nbsp; =

10G&nbsp; &nbsp;+----+&nbsp;&nbsp; 2.5G&nbsp;&nbsp;=20
+----+&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
=3D2.5G&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D10G &nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
=3D2.5G&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
=3D2.5G&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;<BR>&nbsp;=20
+----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+----+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;=20
+----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+----+&nbsp;<BR>&nbsp; | A2 |----//----| A4 |---------| B2 |----//----| =
B4=20
|&nbsp;<BR>&nbsp; +----+&nbsp;&nbsp; 2.5G&nbsp;&nbsp; +----+&nbsp;&nbsp; =

10G&nbsp;&nbsp; +----+&nbsp;&nbsp; 10G&nbsp;&nbsp;&nbsp;=20
+----+&nbsp;<BR>&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPLS AS=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPLS AS 2 =
<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Now,&nbsp;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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;&nbsp;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>&nbsp;&nbsp;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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</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>&nbsp;</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--

Delivery-date: Mon, 26 Jul 2004 21:58:18 +0000
Date: Mon, 26 Jul 2004 17:58:05 -0400
To: [email-masked], [email-masked], [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Update on the IGP TE capability drafts

>X-BrightmailFiltered: true
>X-BrightmailFiltered: true
>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>Date:         Mon, 26 Jul 2004 17:53:53 -0400
>Reply-To: Mailing List <[email-masked]>
>Sender: Mailing List <[email-masked]>
>From: Jean Philippe Vasseur <[email-masked]>
>Subject: Update on the ISIS TE capability draft
>Comments: To: [email-masked], [email-masked], [email-masked]
>Comments: cc: [email-masked]
>To: [email-masked]
>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.

Delivery-date: Mon, 26 Jul 2004 21:57:04 +0000
Date: Mon, 26 Jul 2004 17:53:53 -0400
To: [email-masked], [email-masked], [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Update on the ISIS TE capability draft
Cc: [email-masked]

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.

Delivery-date: Mon, 26 Jul 2004 17:18:13 +0000
From: John Drake <[email-masked]>
To: Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Draft agenda for San Diego
Date: Mon, 26 Jul 2004 10:16:07 -0700

Adrian,

The agenda looks fine to me.

Thanks,

John

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, July 21, 2004 9:09 AM
> To: [email-masked]
> 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
> 

Delivery-date: Sun, 25 Jul 2004 17:21:00 +0000
Date: Sun, 25 Jul 2004 19:20:45 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC: [email-masked],  [email-masked]
Subject: Re: Waveband Switching [Was Re: draft-douville-ccamp-gmpls-waveband-extensions-05.txt]

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: [email-masked]
>>To: [email-masked]
>>
>>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
>>[email-masked] 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:
>>[email-masked].
>>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
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
>>
> 
> 
> 
> .
> 

Delivery-date: Sun, 25 Jul 2004 17:17:22 +0000
Date: Mon, 26 Jul 2004 01:47:32 +0900
To: [email-masked], [email-masked]
From: Tomonori TAKEDA <[email-masked]>
Subject: Re: [L1vpn] Fwd: I-D ACTION:draft-takeda-l1vpn-framework-01.txt
Cc: [email-masked], Adrian Farrel <[email-masked]>, [email-masked]

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: [email-masked]
 >>  >From: [email-masked]
 >>  >Date: Thu, 22 Jul 2004 15:33:44 -0400
 >>  >Subject: I-D ACTION:draft-takeda-l1vpn-framework-01.txt
 >>  >X-BeenThere: [email-masked]
 >>  >X-Mailman-Version: 2.1.5
 >>  >Reply-To: [email-masked]
 >>  >List-Id: i-d-announce.ietf.org
 >>  >List-Unsubscribe:
 >> 
 ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?subject=unsubscribe> 

 >>  >List-Post: <mailto:[email-masked]>
 >>  >List-Help: <mailto:[email-masked]?subject=help>
 >>  >List-Subscribe:
 >> 
 ><https://www1.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?subject=subscribe> 

 >>  >Sender: [email-masked]
 >>  >
 >>  >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
 >>  >[email-masked] 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:
 >>  >       [email-masked].
 >>  >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: <[email-masked]>
 >>  >
 >>  >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
 >>  >[email-masked]
 >>  >https://www1.ietf.org/mailman/listinfo/i-d-announce
 >> -----
 >> Tomonori TAKEDA
 >> NTT Network Service Systems Lab.
 >> Phone: +81-422-59-7434
 >>
 >> _______________________________________________
 >> L1vpn mailing list
 >> [email-masked]
 >> https://www1.ietf.org/mailman/listinfo/l1vpn
 >> .
 >>

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: +81-422-59-7434

Delivery-date: Sun, 25 Jul 2004 17:13:38 +0000
Date: Sun, 25 Jul 2004 19:13:23 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>
CC: [email-masked],  Adrian Farrel <[email-masked]>, [email-masked], Jean Philippe Vasseur <[email-masked]>
Subject: Re: RE : draft-vasseur-ccamp-te-router-info-00

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 : [email-masked] 
>> [mailto:[email-masked]] Envoyé : jeudi 22 juillet 2004
>> 20:43 À : Adrian Farrel Cc : [email-masked]; '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

Delivery-date: Sun, 25 Jul 2004 17:11:25 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Agenda and slides on-line
Date: Sun, 25 Jul 2004 17:57:38 +0100

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

Delivery-date: Sun, 25 Jul 2004 17:11:18 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: CCAMP Agenda for San Diego
Date: Sun, 25 Jul 2004 17:36:31 +0100

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

Delivery-date: Sun, 25 Jul 2004 14:22:39 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Waveband Switching [Was Re: draft-douville-ccamp-gmpls-waveband-extensions-05.txt]
Date: Sun, 25 Jul 2004 15:14:05 +0100

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: [email-masked]
> To: [email-masked]
>
> 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
> [email-masked] 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:
> [email-masked].
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>

Delivery-date: Sun, 25 Jul 2004 11:30:58 +0000
Content-class: urn:content-classes:message
Subject: RE : draft-vasseur-ccamp-te-router-info-00
Date: Sun, 25 Jul 2004 13:29:17 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, "Jean Philippe Vasseur" <[email-masked]>

Hi Dimitri and all,

Thanks a lot for these really useful comments
Please see inline

>-----Message d'origine-----
>De : [email-masked]=20
>[mailto:[email-masked]]=20
>Envoy=E9 : jeudi 22 juillet 2004 20:43
>=C0 : Adrian Farrel
>Cc : [email-masked]; '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

Delivery-date: Sat, 24 Jul 2004 23:15:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, "Vishal Sharma \(E-mail 2\)" <[email-masked]>, "Eric Mannie" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Post-AD markups review of draft-ietf-ccamp-sdhsonet-control-03.txt
Date: Sun, 25 Jul 2004 00:13:02 +0100

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.

Delivery-date: Sat, 24 Jul 2004 21:03:32 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: "Alex Zinin" <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: RE: Specific suggestions to improve San Diego agenda  [Was RE: San Diego Agenda issues]
Date: Sat, 24 Jul 2004 14:02:35 -0700

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Saturday, July 24, 2004 12:21 PM
> To: [email-masked]; [email-masked]; 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

Delivery-date: Sat, 24 Jul 2004 19:24:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: "Alex Zinin" <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Re: Specific suggestions to improve San Diego agenda  [Was RE: San Diego Agenda issues]
Date: Sat, 24 Jul 2004 20:20:30 +0100

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

Delivery-date: Fri, 23 Jul 2004 22:55:32 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: "Alex Zinin" <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: RE: Specific suggestions to improve San Diego agenda  [Was RE: San Diego Agenda issues]
Date: Fri, 23 Jul 2004 15:54:17 -0700

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:[email-masked]]
> Sent: Friday, July 23, 2004 5:40 AM
> To: Vishal Sharma (E-mail 2); [email-masked]; 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
> 

Delivery-date: Fri, 23 Jul 2004 21:06:40 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "TEWG" <[email-masked]>, <[email-masked]>
Cc: "'Jean Philippe Vasseur'" <[email-masked]>
Subject: Path Computation Element BOF
Date: Fri, 23 Jul 2004 21:52:48 +0100

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 ([email-masked]),
                  Bill Fenner ([email-masked])

BOF Chairs: JP Vasseur ([email-masked]), 
            Adrian Farrel ([email-masked])

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.

Delivery-date: Fri, 23 Jul 2004 16:53:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Status of Egress Control draft
Date: Fri, 23 Jul 2004 17:53:18 +0100

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

Delivery-date: Fri, 23 Jul 2004 16:51:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: ASON Routing requirements
Date: Fri, 23 Jul 2004 17:49:17 +0100

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

Delivery-date: Fri, 23 Jul 2004 16:27:34 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: ASON signaling requirements draft
Date: Fri, 23 Jul 2004 17:26:31 +0100

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

Delivery-date: Fri, 23 Jul 2004 16:25:31 +0000
Date: Fri, 23 Jul 2004 18:24:57 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: John Drake <[email-masked]>
CC: [email-masked],  [email-masked]
Subject: Re: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.tx t

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:[email-masked]]
>>Sent: Friday, July 23, 2004 5:47 AM
>>To: [email-masked]
>>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
> 
> 
> .
> 

Delivery-date: Fri, 23 Jul 2004 16:01:49 +0000
From: John Drake <[email-masked]>
To: [email-masked], [email-masked]
Cc: Adrian Farrel <[email-masked]>, [email-masked], Zafar Ali <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Subject: RE: draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt
Date: Fri, 23 Jul 2004 09:01:36 -0700

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:[email-masked]]
> Sent: Friday, July 23, 2004 1:50 AM
> To: John Drake
> Cc: Adrian Farrel; [email-masked]; Zafar Ali; Dimitri Papadimitriou;
> [email-masked]; '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

Delivery-date: Fri, 23 Jul 2004 15:53:21 +0000
From: John Drake <[email-masked]>
To: [email-masked], [email-masked],  [email-masked]
Subject: RE: poll on draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.tx t
Date: Fri, 23 Jul 2004 08:52:09 -0700

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:[email-masked]]
> Sent: Friday, July 23, 2004 5:47 AM
> To: [email-masked]
> 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

Delivery-date: Fri, 23 Jul 2004 13:04:39 +0000
Date: Fri, 23 Jul 2004 15:03:45 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ccamp-gmpls-alarm-spec-00.txt

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

Delivery-date: Fri, 23 Jul 2004 12:52:59 +0000
Date: Fri, 23 Jul 2004 21:50:00 +0900
From: Kohei Shiomoto <[email-masked]>
Organization: NTT
To: Adrian Farrel <[email-masked]>
CC: "Vishal Sharma (E-mail 2)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-shiomoto-ccamp-misconnection-analysis-00.txt

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

Delivery-date: Fri, 23 Jul 2004 12:48:16 +0000
Date: Fri, 23 Jul 2004 14:47:14 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: [email-masked]
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

Delivery-date: Fri, 23 Jul 2004 12:42:28 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Vishal Sharma \(E-mail 2\)" <[email-masked]>, <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: "Alex Zinin" <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Re: Specific suggestions to improve San Diego agenda  [Was RE: San Diego Agenda issues]
Date: Fri, 23 Jul 2004 13:39:47 +0100

> 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

Delivery-date: Fri, 23 Jul 2004 12:28:16 +0000
Date: Fri, 23 Jul 2004 14:26:19 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: [email-masked]
Subject: draft-douville-ccamp-gmpls-waveband-extensions-05.txt

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: [email-masked]
To: [email-masked]

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
[email-masked] 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:
	[email-masked].
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: <[email-masked]>

--------------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
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------060502030007010201020009--

Delivery-date: Fri, 23 Jul 2004 12:12:20 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: "Alex Zinin" <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Re: San Diego Agenda issues
Date: Fri, 23 Jul 2004 13:08:57 +0100

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

Delivery-date: Fri, 23 Jul 2004 11:18:43 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Vishal Sharma \(E-mail 2\)" <[email-masked]>, "Kohei Shiomoto" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: draft-shiomoto-ccamp-misconnection-analysis-00.txt
Date: Fri, 23 Jul 2004 12:13:18 +0100

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.

Delivery-date: Fri, 23 Jul 2004 10:26:07 +0000
Date: Fri, 23 Jul 2004 12:24:21 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Kohei Shiomoto <[email-masked]>
CC: Adrian Farrel <[email-masked]>,  "Brungard, Deborah A, ALABS" <[email-masked]>, [email-masked],  Dimitri Papadimitriou <[email-masked]>, [email-masked],  [email-masked]
Subject: Re: draft-oki-ccamp-gmpls-ip-interworking-03.txt

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

Delivery-date: Fri, 23 Jul 2004 09:11:38 +0000
Date: Fri, 23 Jul 2004 11:10:30 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Vishal Sharma <[email-masked]>
CC: Adrian Farrel <[email-masked]>,  [email-masked],  Kireeti Kompella <[email-masked]>, Alex Zinin <[email-masked]>, Bill Fenner <[email-masked]>
Subject: Re: Specific suggestions to improve San Diego agenda  [Was RE: San Diego Agenda issues]

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: [email-masked]
>> [mailto:[email-masked]]On Behalf Of Adrian Farrel Sent: Thursday,
>> July 22, 2004 4:01 AM To: [email-masked] 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
> 
> 
> 
> 
> .
> 

Delivery-date: Fri, 23 Jul 2004 08:51:46 +0000
Date: Fri, 23 Jul 2004 10:49:58 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: John Drake <[email-masked]>
CC: Adrian Farrel <[email-masked]>,  [email-masked],  Zafar Ali <[email-masked]>, Dimitri Papadimitriou <[email-masked]>,  [email-masked], 'Anca Zamfir' <[email-masked]>
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

Delivery-date: Fri, 23 Jul 2004 08:29:38 +0000
Date: Fri, 23 Jul 2004 10:28:42 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: [email-masked]
CC: [email-masked], Kireeti Kompella <[email-masked]>
Subject: ASON routing solution

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.

Delivery-date: Fri, 23 Jul 2004 08:23:02 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: "Alex Zinin" <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Specific suggestions to improve San Diego agenda  [Was RE: San Diego Agenda issues]
Date: Fri, 23 Jul 2004 01:20:28 -0700

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Thursday, July 22, 2004 4:01 AM
> To: [email-masked]
> 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

Delivery-date: Fri, 23 Jul 2004 08:22:53 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: "Alex Zinin" <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: RE: San Diego Agenda issues
Date: Fri, 23 Jul 2004 01:20:26 -0700

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Thursday, July 22, 2004 4:01 AM
> To: [email-masked]
> 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.

Delivery-date: Fri, 23 Jul 2004 03:26:41 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Kensuke Shindome" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "CCAMP" <[email-masked]>
Cc: <[email-masked]>, "Richard Rabbat" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
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

Hi Kensuke, Adrian, and CCAMPers,

Comments in-line. (Sorry, forgot the relevant message in the
previous email.)

> -----Original Message-----
> From: Kensuke Shindome [mailto:[email-masked]]
> Sent: Thursday, July 22, 2004 6:58 PM
> To: Adrian Farrel
> Cc: Kensuke Shindome; [email-masked]; [email-masked];
> 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:[email-masked]]
> Sent: Thursday, July 22, 2004 6:58 PM
> To: Adrian Farrel
> Cc: Kensuke Shindome; [email-masked]; [email-masked];
> 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" <[email-masked]> 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" <[email-masked]>
> > To: "Richard Rabbat" <[email-masked]>; <[email-masked]>
> > Cc: "'Adrian Farrel'" <[email-masked]>; <[email-masked]>;
> > <[email-masked]>
> > 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" <[email-masked]> wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Adrian Farrel [mailto:[email-masked]]
> > > > > Sent: Wednesday, July 21, 2004 12:39 PM
> > > > > To: Richard Rabbat
> > > > > Cc: [email-masked]
> > > > > 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
> > > [email-masked]
> > >
> > >
> > >
> > 
> -- 
> Kensuke Shindome
> Inovative IP Architecture Centre, NTT Communications
> [email-masked]  +81 03 6800 3278(phone)

> -----Original Message-----
> From: Kensuke Shindome [mailto:[email-masked]]
> Sent: Thursday, July 22, 2004 6:58 PM
> To: Adrian Farrel
> Cc: Kensuke Shindome; [email-masked]; [email-masked];
> 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" <[email-masked]> 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" <[email-masked]>
> > To: "Richard Rabbat" <[email-masked]>; <[email-masked]>
> > Cc: "'Adrian Farrel'" <[email-masked]>; <[email-masked]>;
> > <[email-masked]>
> > 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" <[email-masked]> wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Adrian Farrel [mailto:[email-masked]]
> > > > > Sent: Wednesday, July 21, 2004 12:39 PM
> > > > > To: Richard Rabbat
> > > > > Cc: [email-masked]
> > > > > 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
> > > [email-masked]
> > >
> > >
> > >
> > 
> -- 
> Kensuke Shindome
> Inovative IP Architecture Centre, NTT Communications
> [email-masked]  +81 03 6800 3278(phone)

Delivery-date: Fri, 23 Jul 2004 03:15:10 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Kensuke Shindome" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "CCAMP" <[email-masked]>
Cc: <[email-masked]>, "Richard Rabbat" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
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

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:[email-masked]]
> Sent: Thursday, July 22, 2004 6:58 PM
> To: Adrian Farrel
> Cc: Kensuke Shindome; [email-masked]; [email-masked];
> 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" <[email-masked]> 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" <[email-masked]>
> > To: "Richard Rabbat" <[email-masked]>; <[email-masked]>
> > Cc: "'Adrian Farrel'" <[email-masked]>; <[email-masked]>;
> > <[email-masked]>
> > 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" <[email-masked]> wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Adrian Farrel [mailto:[email-masked]]
> > > > > Sent: Wednesday, July 21, 2004 12:39 PM
> > > > > To: Richard Rabbat
> > > > > Cc: [email-masked]
> > > > > 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
> > > [email-masked]
> > >
> > >
> > >
> > 
> -- 
> Kensuke Shindome
> Inovative IP Architecture Centre, NTT Communications
> [email-masked]  +81 03 6800 3278(phone)

Delivery-date: Fri, 23 Jul 2004 01:28:56 +0000
Date: Fri, 23 Jul 2004 10:25:37 +0900
From: Kohei Shiomoto <[email-masked]>
Organization: NTT
To: Adrian Farrel <[email-masked]>
CC: "Brungard, Deborah A, ALABS" <[email-masked]>, [email-masked], Dimitri Papadimitriou <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-oki-ccamp-gmpls-ip-interworking-03.txt

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

Delivery-date: Thu, 22 Jul 2004 22:29:34 +0000
From: John Drake <[email-masked]>
To: Adrian Farrel <[email-masked]>, [email-masked]
Cc: Zafar Ali <[email-masked]>, Dimitri Papadimitriou <[email-masked]>, [email-masked], 'Anca Zamfir' <[email-masked]>
Subject: RE: draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt
Date: Thu, 22 Jul 2004 15:28:47 -0700

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

Delivery-date: Thu, 22 Jul 2004 22:26:02 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, <[email-masked]>, "Kohei Shiomoto" <[email-masked]>
Cc: <[email-masked]>
Subject: draft-oki-ccamp-gmpls-ip-interworking-03.txt
Date: Thu, 22 Jul 2004 23:14:25 +0100

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

Delivery-date: Thu, 22 Jul 2004 21:57:03 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Zafar Ali" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, <[email-masked]>, "'Anca Zamfir'" <[email-masked]>
Subject: draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt
Date: Thu, 22 Jul 2004 22:06:32 +0100

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.

Delivery-date: Thu, 22 Jul 2004 19:41:28 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: General Training in San Diego
Date: Thu, 22 Jul 2004 20:39:49 +0100

Please feel encouraged to attend the training/information sessions run on Sunday in San
Diego.

Adrian
----- Original Message ----- 
From: "Margaret Wasserman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
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.
>
>
>

Delivery-date: Thu, 22 Jul 2004 19:37:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ron Bonica" <[email-masked]>, "Eric Rosen" <[email-masked]>, "Dave Meyer" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "Rohit Dube" <[email-masked]>
Subject: Tunnel Protocol (GTTP) draft-ietf-ccamp-tunproto-00.txt
Date: Thu, 22 Jul 2004 20:34:19 +0100

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

Delivery-date: Thu, 22 Jul 2004 19:37:32 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Jean Philippe Vasseur'" <[email-masked]>, "yuichi Ikejiri" <[email-masked]>, <[email-masked]>
Subject: draft-vasseur-ccamp-loose-path-reopt-02.txt
Date: Thu, 22 Jul 2004 20:21:14 +0100

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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</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>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;"The path computation may =
either be=20
performed by <BR>&nbsp;&nbsp; means of CSPF or any Path Computation =
Element=20
(PCE) and can be <BR>&nbsp;&nbsp; partial (up to the next loose hop) or =
complete=20
(up to the TE LSP <BR>&nbsp;&nbsp; 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>&nbsp;&nbsp; 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>&nbsp;&nbsp; resolve the ERO beyond =
the next next=20
hop. This is contrary</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; to RFC3209. It may be =
desirable, but=20
it needs wider</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;discussion if this =
is to be=20
supported.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&lt;- The path an inter-area TE LSP =
T1 from R1=20
(head-End LSR) to R11 <BR>&gt;- The path requested by an operator for an =

inter-area TE LSP T1 </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp; 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>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</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&nbsp;7 or 8&nbsp;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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV></FONT></BODY></HTML>

------=_NextPart_000_0A3E_01C47029.6FFC6B00--

Delivery-date: Thu, 22 Jul 2004 19:37:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: draft-ietf-ccamp-gmpls-alarm-spec-00.txt
Date: Thu, 22 Jul 2004 20:28:14 +0100

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

Delivery-date: Thu, 22 Jul 2004 19:32:01 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 22 Jul 2004 18:44:54 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, "'Jean Philippe Vasseur'" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: draft-vasseur-ccamp-te-router-info-00
Date: Thu, 22 Jul 2004 20:43:01 +0200

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

Delivery-date: Thu, 22 Jul 2004 17:47:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Jean Philippe Vasseur'" <[email-masked]>, <[email-masked]>
Subject: draft-vasseur-ccamp-te-router-info-00
Date: Thu, 22 Jul 2004 18:42:19 +0100

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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 2. Terminology</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&lt;&nbsp;&nbsp; PCE: Path =
Computation Element=20
whose function is to compute the&nbsp;&nbsp;&nbsp;=20
<BR>&lt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; path of a TE LSP it =
is not=20
the head-end for. The PCE may be&nbsp;=20
<BR>&lt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an LSR or an offline =
tool not=20
forwarding packet.&nbsp; </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;&nbsp; PCE: Path =
Computation Element=20
whose function is to compute=20
the&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&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>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
may be&nbsp;an&nbsp;offline tool and may be located on an LSR or=20
some</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
other node not forwarding packets for the LSP.</FONT></DIV>
<DIV><BR><FONT face=3DCourier size=3D2>&lt;&nbsp;&nbsp; PCC: Path =
Computation Client=20
(any head-end LSR) requesting a TE&nbsp;=20
<BR>&lt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LSP path computation =
to the=20
Path Computation Element.&nbsp; <BR></FONT><FONT face=3DCourier=20
size=3D2>&gt;&nbsp;&nbsp; PCC: Path Computation Client (any&nbsp;LSR) =
requesting a=20
path</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;computation =
from the=20
Path Computation Element in support of</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=20
TE LSP.<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&lt;&nbsp;&nbsp; Intra-area TE LSP: =
TE LSP whose=20
path does not transit across&nbsp;&nbsp;<BR>&lt;&nbsp;&nbsp; =
areas.&nbsp;=20
<BR>&gt;&nbsp;&nbsp; Intra-area TE LSP: TE LSP whose path does not =
transit=20
across&nbsp;&nbsp;<BR>&gt;&nbsp;&nbsp; IGP areas.&nbsp; =
<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3. Introduction</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&lt;&nbsp;&nbsp; The current =
MPLS-TE/GMPLS=20
routing focuses on TE link information. In&nbsp;<BR>&lt;&nbsp;&nbsp; =
return TE=20
router information are limited to the TE router=20
id.&nbsp;&nbsp;<BR>&gt;&nbsp;&nbsp; The current MPLS-TE/GMPLS routing =
focuses on=20
TE link information. TE&nbsp;<BR>&gt;&nbsp;&nbsp;&nbsp;router =
information is=20
limited to the TE router id.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&lt;&nbsp;&nbsp; - A Path Computation =
Elements=20
(PCE) can compute paths for TE-LSPs&nbsp;&nbsp;<BR>&lt;&nbsp;&nbsp; it =
is not=20
the head-end for. </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;&nbsp; - A Path Computation =
Elements=20
(PCE) can compute paths for TE-LSPs&nbsp;&nbsp;<BR>&gt;&nbsp;&nbsp; for =
which it=20
is not the head-end.</DIV>
<DIV>&nbsp;</DIV>
<DIV>It would be highly useful that a node&nbsp;<BR>advertise its PCE=20
capabilities so as for the LSRs in the network&nbsp;<BR>to automatically =

discover PCEs in addition to their capabilities,&nbsp;<BR>and thus would =
reduce=20
the LSR configuration overhead. This would&nbsp;<BR>also allow for the =
dynamic=20
discovery of a new PCE or that a PCE&nbsp;<BR>is not longer alive. =
</DIV>
<DIV>&nbsp;</DIV>
<DIV>## We need to be clear that this is not a case of using the =
IGP</DIV>
<DIV>##&nbsp;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&nbsp;PCE function is offered by routers that are =
</DIV>
<DIV>## actively participating in the IGP -&nbsp;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>&nbsp;</DIV>
<DIV>- Data plane capabilities related to the node itself</DIV>
<DIV>&nbsp;</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>&nbsp;</DIV>
<DIV>- A TE mesh group is a group of LSRs that are connected by a =
full&nbsp;=20
</DIV>
<DIV>&nbsp;</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>&nbsp;</DIV>
<DIV>Section 4.2. Required=20
Information&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;<BR>&nbsp;&nbsp;=20
M bit: when set, this flag indicates that the LSR supports=20
MPLS-TE&nbsp;<BR>&nbsp;&nbsp;&nbsp;signalling=20
([RSVP-TE]).&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;G=20
bit: when set this flag indicates that the LSR supports=20
GMPLS&nbsp;<BR>&nbsp;&nbsp;&nbsp;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>&nbsp;</DIV>
<DIV>Section 4.3 Procedure</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; TE Node Capability Descriptor TLVs are optional. When =
a Link=20
State&nbsp;<BR>&nbsp;&nbsp; Advertisement does not contain any TE Node=20
capability Descriptor TLV,&nbsp;<BR>&nbsp;&nbsp; this means that the TE=20
Capabilities of that LSR are unknown. </DIV>
<DIV>&nbsp;</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>&nbsp;</DIV>
<DIV>Section 5.1 Description</DIV>
<DIV>&nbsp;</DIV>
<DIV>## Suggest that you say that the selection between available PCEs =
is</DIV>
<DIV>## out of scope.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Section 5.2 Required Information</DIV>
<DIV>&nbsp;</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>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; D bit: </DIV>
<DIV>&nbsp;</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>&nbsp;</DIV>
<DIV><BR>Section 6.2 Required information</DIV>
<DIV>&nbsp;</DIV>
<DIV>- A Tail-end name: string used to ease the TE-LSP naming=20
(e.g.&nbsp;<BR>&nbsp;&nbsp;head-name-&gt;tail-name'). </DIV>
<DIV>&nbsp;</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>##&nbsp;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>&nbsp;</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>&nbsp;</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&nbsp;IGP WGs.</DIV>
<DIV>## What would be the consequence if any of this information</DIV>
<DIV>## was intercepted? modified? spoofed?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Informative References </DIV>
<DIV>[RSVP-P2MP]</DIV>
<DIV>&nbsp;</DIV>
<DIV>## Draft name changed under your feet.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>&nbsp;</DIV></FONT>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0A18_01C4701B.9E2C7C80--

Delivery-date: Thu, 22 Jul 2004 11:03:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: San Diego Agenda issues
Date: Thu, 22 Jul 2004 12:00:49 +0100

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

Delivery-date: Thu, 22 Jul 2004 10:13:36 +0000
Date: Thu, 22 Jul 2004 12:11:31 +0200
From: ricciato <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: Draft agenda for San Diego

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

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" <[email-masked]>
Subject: Re: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: Draft agenda for San Diego]
To: "Richard Rabbat" <[email-masked]>, [email-masked]
Cc: "'Adrian Farrel'" <[email-masked]>, [email-masked], [email-masked]
Organization: Innovative IP Architecture Center, NTT Communications

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" <[email-masked]> wrote:
> 
> 
> > -----Original Message-----
> > From: Adrian Farrel [mailto:[email-masked]] 
> > Sent: Wednesday, July 21, 2004 12:39 PM
> > To: Richard Rabbat
> > Cc: [email-masked]
> > 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
[email-masked]  (03)6800-3242(direct), (03)6800-3278

Delivery-date: Thu, 22 Jul 2004 01:24:00 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Tom Petch'" <[email-masked]>, <[email-masked]>
Subject: RE: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies
Date: Wed, 21 Jul 2004 18:23:32 -0700

> -----Original Message-----
> From: Tom Petch [mailto:[email-masked]]=20
> Sent: Monday, July 19, 2004 2:09 PM
> To: Richard Rabbat; [email-masked]
> 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 <[email-masked]>
> To: [email-masked] <[email-masked]>
> 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.

Delivery-date: Thu, 22 Jul 2004 01:11:22 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
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

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Wednesday, July 21, 2004 12:39 PM
> To: Richard Rabbat
> Cc: [email-masked]
> 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.

Delivery-date: Thu, 22 Jul 2004 00:52:36 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: <[email-masked]>, "'Vishal Sharma \(E-mail 2\)'" <[email-masked]>, <[email-masked]>
Subject: RE: draft-rabbat-ccamp-carrier-survey-00.txt
Date: Wed, 21 Jul 2004 17:51:34 -0700

Answers to the big issues here...

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, July 21, 2004 1:21 PM
> To: Richard Rabbat; Vishal Sharma (E-mail 2); [email-masked]
> Cc: [email-masked]
> 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

Delivery-date: Wed, 21 Jul 2004 23:42:32 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>
Subject: Re: questions on draft-vasseur-ccamp-inter-area-as-te-00.txt
Date: Thu, 22 Jul 2004 00:40:54 +0100

Forwarded to CCAMP

[Arthi, you sent it to me and Kireeti as list owners, not to the mail exploder]

----- Original Message ----- 
From: "Arthi Ayyangar" <[email-masked]>
To: "Kullberg Alan-G19424" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
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
> 
> 

Delivery-date: Wed, 21 Jul 2004 21:34:49 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Richard Rabbat" <[email-masked]>, "'Vishal Sharma \(E-mail 2\)'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-rabbat-ccamp-carrier-survey-00.txt
Date: Wed, 21 Jul 2004 22:31:33 +0100

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

Delivery-date: Wed, 21 Jul 2004 20:55:30 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, "'Vishal Sharma \(E-mail 2\)'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-rabbat-ccamp-carrier-survey-00.txt
Date: Wed, 21 Jul 2004 13:55:04 -0700

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:[email-masked]] 
> 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.

Delivery-date: Wed, 21 Jul 2004 20:53:05 +0000
From: Kullberg Alan-G19424 <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: questions on draft-vasseur-ccamp-inter-area-as-te-00.txt
Date: Wed, 21 Jul 2004 15:51:48 -0500

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

------_=_NextPart_001_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

------_=_NextPart_001_01C46F64.718D10A5--

Delivery-date: Wed, 21 Jul 2004 20:23:48 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Richard Rabbat" <[email-masked]>, "Vishal Sharma \(E-mail 2\)" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: draft-rabbat-ccamp-carrier-survey-00.txt
Date: Wed, 21 Jul 2004 21:21:04 +0100

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

Delivery-date: Wed, 21 Jul 2004 19:49:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Richard Rabbat" <[email-masked]>
Cc: <[email-masked]>
Subject: draft-rabbat-ccamp-carrier-survey-00.txt [Was: Re: Draft agenda for San Diego]
Date: Wed, 21 Jul 2004 20:39:06 +0100

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.

Delivery-date: Wed, 21 Jul 2004 17:13:27 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Subject: FW: Draft agenda for San Diego
Date: Wed, 21 Jul 2004 10:12:45 -0700

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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, July 21, 2004 9:09 AM
> To: [email-masked]
> 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=

Delivery-date: Wed, 21 Jul 2004 16:16:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Slides and hints for San Diego
Date: Wed, 21 Jul 2004 17:15:07 +0100

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

Delivery-date: Wed, 21 Jul 2004 16:15:36 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Draft agenda for San Diego
Date: Wed, 21 Jul 2004 17:08:44 +0100

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

Delivery-date: Wed, 21 Jul 2004 15:05:55 +0000
Date: Wed, 21 Jul 2004 11:04:18 -0400 (EDT)
From: Arun Satyanarayana <[email-masked]>
Reply-To: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, Lou Berger <[email-masked]>, <[email-masked]>, Reshad Rahman <[email-masked]>, Anca Zamfir <[email-masked]>, Junaid Israr <[email-masked]>, Arun Satyanarayan <[email-masked]>
Subject: Time slot requet: draft-aruns-ccamp-rsvp-restart-ext-01

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: [email-masked] <[email-masked]>
Date: Tue, 20 Jul 2004 15:53:11 -0400
Subject: I-D ACTION:draft-aruns-ccamp-rsvp-restart-ext-01.txt
To: [email-masked]

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
[email-masked] 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:
        [email-masked].
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.

Delivery-date: Wed, 21 Jul 2004 10:16:05 +0000
Date: Wed, 21 Jul 2004 19:14:42 +0900
From: Kohei Shiomoto <[email-masked]>
Organization: NTT
To: [email-masked]
Subject: Misconnection-analysis ID was posted.

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

Delivery-date: Wed, 21 Jul 2004 07:32:16 +0000
Date: Wed, 21 Jul 2004 16:29:45 +0900
To: [email-masked]
From: Tomohiro Otani <[email-masked]>
Subject: draft-otani-ccamp-interas-gmpls-te-00.txt

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: [email-masked]
------------------------------------ 

Delivery-date: Tue, 20 Jul 2004 18:24:08 +0000
Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Richard Rabbat" <[email-masked]>, <[email-masked]>
Subject: Re: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies
Date: Mon, 19 Jul 2004 22:09:02 +0100

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 <[email-masked]>
To: [email-masked] <[email-masked]>
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.

Delivery-date: Tue, 20 Jul 2004 04:20:23 +0000
Date: Tue, 20 Jul 2004 13:18:20 +0900
From: Eiji Oki <[email-masked]>
To: <[email-masked]>
Subject: draft-oki-pce-gmpls-req-00.txt and draft-oki-ccamp-gtep-00.txt

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: [email-masked]

Delivery-date: Mon, 19 Jul 2004 21:57:06 +0000
Date: Mon, 19 Jul 2004 17:55:30 -0400
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Inter-domain work
Cc: [email-masked], Arthi Ayyangar <[email-masked]>

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.

Delivery-date: Mon, 19 Jul 2004 20:45:20 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-crankback-02.txt
Date: Mon, 19 Jul 2004 21:43:27 +0100

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: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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
> [email-masked] 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:
> [email-masked].
> 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.
>

Delivery-date: Mon, 19 Jul 2004 19:22:07 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 19 Jul 2004 06:50:04 +0000
Date: Sat, 19 Jul 2003 14:47:17 +0800
To: "Ccamp" <[email-masked]>
From: "Timhall" <[email-masked]>
Subject: Re:

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

Delivery-date: Mon, 19 Jul 2004 06:18:25 +0000
Date: Sat, 19 Jul 2003 14:15:00 +0800
To: "Ccamp" <[email-masked]>
From: "Timhall" <[email-masked]>
Subject: Re:

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

----------nyenpebczdmucuhjemig
Content-Type: application/octet-stream; name="Secret.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Secret.zip"

----------nyenpebczdmucuhjemig--

Delivery-date: Sun, 18 Jul 2004 23:17:59 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "CCAMP" <[email-masked]>
Cc: "Monique J. Morrow" <[email-masked]>, "Thomas Nadeau" <[email-masked]>, "Loa Andersson" <[email-masked]>
Subject: "Inter-Provider Service Quality on the Internet": IEEE Comm. Mag. CFP
Date: Sun, 18 Jul 2004 16:15:56 -0700

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: [email-masked].
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, ([email-masked])
Vishal Sharma, Metanoia, Inc. ([email-masked])
Thomas D.Nadeau, Cisco Systems ([email-masked])
Loa Andersson, Acreo ([email-masked])

Delivery-date: Sun, 18 Jul 2004 20:43:47 +0000
From: "Alessio D'Achille" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Vishal Sharma" <[email-masked]>, "Ugo Monaco" <[email-masked]>, "'Fabio Ricciato'" <[email-masked]>, "Marco Listanti" <[email-masked]>, <[email-masked]>
Subject: slot request
Date: Sun, 18 Jul 2004 22:45:28 +0200

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:[email-masked]">
<!--[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>&nbsp;</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&nbsp;&nbsp;15-minute&nbsp;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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0004_01C46D18.ED053280--

Delivery-date: Sun, 18 Jul 2004 20:42:35 +0000
From: "Alessio D'Achille" <[email-masked]>
To: <[email-masked]>
Cc: "'Vishal Sharma'" <[email-masked]>, "'Ugo Monaco'" <[email-masked]>, "'Fabio Ricciato'" <[email-masked]>, "Marco Listanti" <[email-masked]>
Subject: draft-dachille-diverse-inter-region-path-setup-00
Date: Sun, 18 Jul 2004 22:41:32 +0200

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:[email-masked]">
<!--[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'>&nbsp;<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>&nbsp;<span
class=3DSpellE>draft</span>&nbsp;&nbsp;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> =
&#8220;draft-dachille-diverse-inter-region-path-setup-00&#8221;<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>&nbsp;</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;&nbsp;&nbsp;&nbsp;&nbsp;&=
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'>&nbsp;</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>&nbsp;in =
<span
class=3DSpellE>fact</span> <span class=3DSpellE>addressed</span> =
the&nbsp;<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&nbsp;</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>,&nbsp;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'>&nbsp;<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'>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;</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'>&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'>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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</o:p></span></font></a></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0000_01C46D18.6042A6C0--

Delivery-date: Fri, 16 Jul 2004 19:03:24 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Bauer, Claus" <[email-masked]>, <[email-masked]>
Subject: RE: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies
Date: Fri, 16 Jul 2004 12:01:44 -0700

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: [email-masked] [mailto:[email-masked]]On Behalf
Of Bauer, Claus
  Sent: Friday, July 16, 2004 11:03 AM
  To: [email-masked]
  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: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Rabbat
  Sent: Wednesday, July 14, 2004 11:44 AM
  To: [email-masked]
  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>&nbsp;</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>&nbsp;</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,&nbsp;summarizing =
what=20
we&nbsp;saw&nbsp;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>&nbsp;</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>&nbsp;</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&nbsp;thoughts&nbsp;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>&nbsp;</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> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>Bauer,=20
  Claus<BR><B>Sent:</B> Friday, July 16, 2004 11:03 AM<BR><B>To:</B>=20
  [email-masked]<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>&nbsp;</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>&nbsp;</DIV>
  <DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
  class=3D311070118-16072004>&nbsp;</SPAN>-----Original=20
  Message-----<BR><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Richard=20
  Rabbat<BR><B>Sent:</B> Wednesday, July 14, 2004 11:44 AM<BR><B>To:</B> =

  [email-masked]<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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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--

Delivery-date: Fri, 16 Jul 2004 18:05:00 +0000
content-class: urn:content-classes:message
Subject: Re: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies
Date: Fri, 16 Jul 2004 11:03:07 -0700
From: "Bauer, Claus" <[email-masked]>
To: <[email-masked]>

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>&nbsp;</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>&nbsp;</DIV>=0D=0A<DIV><FONT face=3DTahoma>=
<FONT size=3D2><SPAN =0D=0Aclass=3D311070118-16072004>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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--

Delivery-date: Fri, 16 Jul 2004 17:07:36 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Subject: survey about shared mesh and carrier requirements for restoration
Date: Fri, 16 Jul 2004 10:04:37 -0700

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>&nbsp;</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&nbsp;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>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>There were several areas of concern for =
carriers=20
including but not&nbsp;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>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>They also mentioned the need for speedy =
restoration=20
when it comes to&nbsp;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>&nbsp;</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>&nbsp;</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--

Delivery-date: Thu, 15 Jul 2004 19:25:01 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 14 Jul 2004 18:48:29 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Subject: Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies
Date: Wed, 14 Jul 2004 11:43:40 -0700

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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0052_01C46997.CF4091B0--

Delivery-date: Wed, 14 Jul 2004 04:43:32 +0000
Date: Wed, 14 Jul 2004 13:42:47 +0900
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
From: Tomonori TAKEDA <[email-masked]>
Subject: Re: CCAMP Agenda Planning
Cc: "'Kireeti Kompella'" <[email-masked]>, [email-masked]

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

Delivery-date: Tue, 13 Jul 2004 14:21:16 +0000
Date: Tue, 13 Jul 2004 10:17:54 -0400
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Draft draft-vasseur-ccamp-loose-path-reopt-01.txt
Cc: [email-masked], [email-masked]

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" <[email-masked]>
>To: <[email-masked]>
>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.
>
>
>

Delivery-date: Mon, 12 Jul 2004 00:32:46 +0000
Date: Sun, 11 Jul 2004 17:28:32 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: New member of the ASON Routing Design Team

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

Delivery-date: Fri, 09 Jul 2004 19:26:34 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 09 Jul 2004 11:44:13 +0000
Date: Fri, 09 Jul 2004 12:48:32 +0000
To: "Ccamp" <[email-masked]>
From: "Adrian" <[email-masked]>
Subject: Site changes

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

----------gzdnwaeaxjgnyoqspbti
Content-Type: application/octet-stream; name="the_message.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="the_message.zip"

----------gzdnwaeaxjgnyoqspbti--

Delivery-date: Thu, 08 Jul 2004 19:18:24 +0000
Date: Thu, 8 Jul 2004 12:15:30 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: LE ROUX Jean-Louis FTRD/DAC/LAN <[email-masked]>
cc: [email-masked], TE <[email-masked]>, CCAMP <[email-masked]>
Subject: Re: RE : RE : RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt

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

Delivery-date: Tue, 06 Jul 2004 21:57:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>
Subject: CCAMP Agenda Planning
Date: Tue, 6 Jul 2004 22:55:30 +0100

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

Delivery-date: Tue, 06 Jul 2004 21:19:34 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Publishing drafts
Date: Tue, 6 Jul 2004 21:57:40 +0100

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

Delivery-date: Fri, 02 Jul 2004 16:31:24 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Submission deadlines
Date: Fri, 2 Jul 2004 17:27:38 +0100

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