Subject: Moving forward with the CCAMP charter

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Aug 2005 12:28:11 +0100

Hi,

Please find attached a file that contains:

- a set of proposed *draft* milestones
- a discussion of why there are so many milestones
- a high-level explanation of the work items.

Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D.

This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement.

I would welcome your (constructive!) comments.

Notes:
- Why isn't my I-D also cited as input material?
  No insult intended. The current list is simply there to
  show the ADs that work is already in progress. All I-Ds
  will be used as input.      
- Why isn't my pet topic included?
  Are you sure it is not there between the lines? This 
  list of milestones isn't completely proscriptive.
  
The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August.

Thanks,
Adrian

---

From: JP Vasseur <[email-masked]>
Date: Tue, 16 Aug 2005 11:36:50 -0400

Hi Adrian,

Looks like a detailed, ambitious constructive action plan.

Two comments:

(1) Analysis of inter-domain issues for disjoint and protected paths
       - Informational I-D to close off the topic and devolve to PCE
       * first version of WG draft
       * submit for IESG review

Could you briefly elaborate on this item ?

(2) May be in the same bucket as draft-ali-ccamp-mpls-graceful- 
shutdown, you may want to add draft-leroux-ccamp-ctrl- 
saturation-01.txt ?

thanks.

JP.

On Aug 16, 2005, at 7:28 AM, Adrian Farrel wrote:

> Note that this looks like a lot of milestones, but please read the  
> text on this issue in the attached file. The bottom line is that  
> this is a product of micro management where I have tried to  
> identify all of the I-Ds that we might produce to cover the  
> referenced work, and where I have placed two (sometimes three)  
> milestones for each I-D.
>
> This micro-management may be over the top, and represents a full  
> pendulum swing from the previous style of CCAMP milestones, but in  
> the light of the hiatus of the last 12 months, i think this may be  
> beneficial and might achieve rapid forwards movement.
>
> <ccamp-milestones.txt>

---

From: dimitri papadimitriou <[email-masked]>
Date: Tue, 16 Aug 2005 18:48:09 +0200

hi adrian

i would consider the saturarion document and probably cluster it with 
the set of items on "deployment/advices/BCPs/etc."

there is an item on "OAM Requirements for GMPLS Networks" with a 
lifetime of around 18 months, while it is difficult to have a detailed 
view on them wouldn't be advisable to think upon starting an item mid of 
next year where details (could be info) would be put together

several questions

 >     - ASON Routing solutions

-> does this mean you envision a single document for IS-IS and OSPF 
(note i hope these can be submitted to the IESG by 2Q'06 instead of 
October 2006) also cross-WG review period should be considered

 > Mar 06 First version of WG informational I-D Aligning GMPLS protocols 
across the standards bodies

and

 >     - Aligning GMPLS protocols across the standards bodies
 >       - Information I-D not intended for publication as an RFC

-> what the first sub-bullet implies ? note that i do not see other 
specific milestone(s) for this document while the second sub-bullet 
refers to a WG I-D ?

 > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D 
for IESG review

-> do you have more details on this specific work item

thanks for the hard work,
- dimitri.

Adrian Farrel wrote:
> ------------------------------------------------------------------------
> 
> CCAMP Working Group - Rechartering Effort
> 
> Below you will find
> - a list of proposed milestones
> - an explanation of why this is a long list
> - overview of proposed drafts and work items
> 
> In reviewing this we should look for:
> - topics that are irrelevant or unwanted by the WG
> - topics that have been left out but are wanted by the WG
> - topics that have been assigned the wrong priority or urgency
> - topics or collections or topics that are sufficiently large
>   to potentially warrant their own working group.
> 
> Proposed New milestones
> -----------------------
> 
> Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF
> Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh membership
> Nov 05 Submit ASON Routing evaluation I-D for IESG review
> Nov 05 First version of WG I-D on path computation implmentation advice
> Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF
> Nov 05 First version WG I-D MPLS to GMPLS migration strategies
> Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS
> Nov 05 First version WG I-D Change of LSP ownership between management and control planes
> Dec 05 First version of WG I-D for ASON Routing solutions
> Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review
> Dec 05 Submit Per-domain path computation signaling I-D for IESG review
> Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region Networks
> Dec 05 First version WG I-D for Evaluation of existing protocols for MLN/MRN
> Dec 05 First version WG I-D for Protocol solutions for MLN/MRN
> Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG review
> Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review
> Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module
> Jan 06 First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths
> Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review
> Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and solutions
> Jan 06 First version WG I-D GMPLS OAM Requirements
> Jan 06 First version WG I-D Routing and signaling for complex optical constraints
> Feb 06 Submit LSP Stitching I-D for IESG review
> Mar 06 First version of WG informational I-D Aligning GMPLS protocols across the standards bodies
> Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for IESG review
> Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module
> Mar 06 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions
> Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review
> Jun 06 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review
> Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review
> Jun 06 Submit Change of LSP ownership between management and control planes I-D for IESG review
> Aug 06 Submit path computation implmentation advice I-D for IESG review
> Oct 06 Submit ASON Routing solutions I-D for IESG review
> Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review
> Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG review
> Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review
> Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review
> Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
> Dec 06 Submit GMPLS OAM Requirements I-D for IESG review
> Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review
> Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review
> Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review
> Oct 07 Submit Routing and signaling for complex optical constraints I-D for IESG review
> Oct 07 Recharter or close Working Group
> 
> 
> Why so many milestons?
> ----------------------
> The number of milestones shown in this proposed list far exceeds
> anything I have ever seen in a working group charter. This is
> intentional and while it does indicate a heavy work-load it also
> indicates a higher level of micro-management than is usual within
> working groups. Thus two milestones are presented for each I-D
> (adoption as a WG I-D, and passing to the IESG post-WG-last-call).
> 
> This can be compared with the "normal" charter milestones which
> include a single work-related item that may span several I-Ds and
> refers vaguely only to the "submission" of I-Ds.
> 
> In other words, reviewers of this list should not panic because
> of its length, but should see this as beneficial.
> 
> 
> Explanation of I-Ds and work items
> ----------------------------------
> 
> The following text briefly introduces the work items that are
> represented by the milestones listed above. In this text an
> astrix (*) indicates a milestone to be set.
> 
> The work is divided into several categories according to how
> core it is and how it should be prioritized. Existing drafts
> are referenced to indicate that work is already in progress -
> this is not intended to provide a complete list of existing
> drafts.
> 
>   Completing existing work
>   ========================
> 
>     ASON
>     - ASON Routing evaluation
>       - already have draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt
>       * submit for IESG review
>     - ASON Routing solutions
>     - GMPLS signaling in support of Call Management
>       - already have draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt
>       * submit for IESG review
>     - GMPLS/ASON lexicography
>       - already have draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
>       * submit for IESG review
>     - Aligning GMPLS protocols across the standards bodies
>       - Information I-D not intended for publication as an RFC
>     Interoperability reports and advice
>     - signaling and routing
>       - already have draft-ietf-ccamp-gmpls-addressing-01.txt
>       * submit for IESG review
>     - path computation
>         - based on draft-otani-ccamp-gmpls-cspf-constraints-01.txt
>       * submit for IESG review
> 
>     Additional MIB modules
>     - OSPF-TE
>         - based on draft-otani-ccamp-gmpls-ospf-mib-00.txt
>       * submit for IESG review
>     - ISIS-TE
>     - Signaling
>       - Need "living" MIB module under development to catch
>         the minor protocol extensions that have been made
>     Inter-domain
>     - LSP Stitching
>       - already have draft-ietf-ccamp-lsp-stitching-01.txt
>       * submit for IESG review
>     - RSVP-TE extensions for interdomain
>       - already have draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
>       * submit for IESG review
>     - Per-domain path computation signaling
>       - already have draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
>       * submit for IESG review
>     - Analysis of inter-domain issues for disjoint and protected paths
>   New items already started and within existing charter
>   =====================================================
> 
>     Advertising TE Node Capabilities
>     - ISIS and OSPF in the same I-D
>         - based on draft-vasseur-ccamp-te-node-cap-00.txt
>       * review by IGP working groups
>       * submit for IESG review
> 
>     Automatic discovery of MPLS-TE mesh membership
>     - depends on TE Node capabilities I-D
>         - based on draft-vasseur-ccamp-automesh-00.txt
>       * submit for IESG review
> 
>     Multi-layer networks (also multi-region networks)
>     - Requirements
>         - based on draft-shiomoto-ccamp-gmpls-mrn-reqs-02.txt
>       * submit for IESG review
>     - Evaluation of existing protocols
>         - based on draft-leroux-ccamp-gmpls-mrn-eval-01.txt
>       * submit for IESG review
>     - Solutions
>         - based on draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt
>       * submit for IESG review
> 
>     MPLS-GMPLS interworking requirements and solutions
>         - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt
>       * submit for IESG review
> 
>     MPLS to GMPLS migration strategies
>       * Informational I-D first version of WG draft
>         - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt
>         - material from draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt
>       * submit Informational I-D for IESG review
> 
>   Minor items just starting but close to heart of WG
>   ==================================================
> 
>     GMPLS OAM Requirements
>     - Interesting and worthwhile
>         - based on immature draft-nadeau-ccamp-gmpls-oam-requirements-00.txt
>       * submit for IESG review
> 
>   Minor items just starting and important becuase of inter-SDO interactions
>   =========================================================================
> 
>     GMPLS coordination of VCAT and LCAS
>     - single requirements and solutions draft almost an applicablity statement
>         - based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt
>       * submit for IESG review
> 
>     Change of LSP ownership between management and control planes
>     - single requirements and solutions draft defines one bit and a procedure
>         - based on draft-caviglia-mp2cpcp2mp-02.txt
>       * submit for IESG review
> 
>   More forward-looking
>   ====================
> 
>     Routing and signaling for complex optical constraints
>         - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
>       * submit for IESG review

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Aug 2005 19:53:53 +0100

> Could you briefly elaborate on this item ?

I think we have the need for an informational I-D that is a bit like the
existing inter-domain framework I-D, but that examines the more complex
question of the provisioning of disjoint and protection paths across
domain boundaries. I am aware that there a lot of ideas out there and that
there has been a lot of research. I think we need to capture an overview.

It is my (personal - not WG chair) opinion that this I-D will point firmly
at the PCE WG. But just as for single paths we discovered that there are
some (limited) scenarios for single paths where signaling is suitable on
its own, we may find some solutions for diverse and protected paths.

> shutdown, you may want to add draft-leroux-ccamp-ctrl-

Yes. I am inclined to add a work item for "control plane robustness".

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Aug 2005 20:08:43 +0100

> the set of items on "deployment/advices/BCPs/etc."

Well, the control plane saturation I-D defines new protocol procedures and
encodings so it needs to be standards track if we do it.

Thus my response to JP.

If you are raising a new category of work (and I know you commented on
this in Paris) for deployment/advices/BCPs/etc. I would appreciate it if
you could:
- compare what you want with "Interoperability reports and advice"
- suggest some I-D titles that you might
   - want to see
   - be willing to work on (note, these two categories do not have to
overlapping)

> next year where details (could be info) would be put together

I think there is some detail missing from your suggestion. I think you are
saying that we should plan to start developing solutions to meet the OAM
requirements that we will document. This sounds very good, but I am
unwilling to insert a milestone without knowing what we are going to work
on or whether anyone has any intention of doing the work or developing the
software.

I would suggest that this is an item that we should monitor and know that
the chairs are likely to look favorably on solutions work that meets the
requirements.

In the back of my mind, however, is the tunnel trace I-D which lies in a
coffin with a stake through its heart. Not because there weren't
requirements (we have an RFC documenting the requirements) and not because
no-one wanted to write the I-D (we had several authors), but because
no-one wanted to implement.

> October 2006) also cross-WG review period should be considered

Not clear that a BGP draft isn't needed too!

These are generic milestones (I have already proposed too many
milestones!).
If the changes are tiny and use existing TLVs then a single I-D will
probably do.
Otherwise, one I-D per protocol.

> specific milestone(s) for this document while the second sub-bullet

Yes. We need to drive closer alignment between the various uses of GMPLS
protocols across the standard bodies. In order to colate our thoughts and
direct discussions in and out of CCAMP we will need to document our ideas
in an I-D. Because we wish to demonstrate CCAMP community cohesion behind
our thoughts, this will need to be a WG I-D (hence the milestone and
starred bullet).

However, it is far from clear that the I-D will need to progress to RFC.
After all, once we identify the actions that are needed, we will carry out
the actions. We will then need to update the I-D for further actions etc.

If, on the other hand, the I-D turns out to document longer-term or
ongoing procedures (like the GMPLS change process) we will certainly need
to progress the I-D.

> -> do you have more details on this specific work item

Not completely sure. It seems to me that if we are doing stuff for
signaling, we should also do it for routing. It is possible that this
folds natrually into the existing signaling (addressing) I-D. Hence this
milestone depends on the work item...

> thanks for the hard work,

You're welcome.
Thanks for the support.

Adrian

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 17 Aug 2005 00:40:46 +0200

> encodings so it needs to be standards track if we do it.

i am fine with a category "control plane robustness" separated from the 
one mentioned here below

note: however, i am not necessarily sure that the type outcome must be 
driver for classification e.g. the saturation document is an outcome of 
practicing RSVP-TE with mechanisms such as soft-provisioning

>    - be willing to work on (note, these two categories do not have to

yes, for the time being i think that two major topics are falling in 
this category:
1) TE link operation(s) and processing practices (which is at the end 
what makes GMPLS) is a typical topic that would require further development
2) inter-domain relationship(s)/exchanges and admission control policies

> on or whether anyone has any intention of doing the work or developing the

this is the reason why i did myself tried to position the requirement 
document (it is the same reasoning at the end) it is also clear that 
such a topic would benefit from more operational feedback on GMPLS 
network operation(s)

> the chairs are likely to look favorably on solutions work that meets the

ok

> no-one wanted to implement.

reason why it may be advisable to have a better view on the "toolset" 
that would be valuable for operating GMPLS networks (bottom-up)

> Not clear that a BGP draft isn't needed too!

a complete response to this question would deserve an I-D by itself ;-)

> Otherwise, one I-D per protocol.

ok

> our thoughts, this will need to be a WG I-D (hence the milestone and

the objective is sensible and i also think valuable to have such common 
view been written down

> ongoing procedures (like the GMPLS change process) we will certainly need

so, this document is meant to be a "process" I-D; therefore, its 
progress is indeed dependent on action lines that are to be documented

> milestone depends on the work item...

i see now to what you are referring to

note: i would also suggest focusing the below reference i-d on 
addressing space setting and processing practices (as the name indicates)

> .

---

From: JP Vasseur <[email-masked]>
Date: Tue, 16 Aug 2005 19:33:13 -0400

Hi Adrian,

> there has been a lot of research. I think we need to capture an  

ok fair enough ... I'll be happy to provide my input on the topic (as  
you can imagine ;-))

> Yes. I am inclined to add a work item for "control plane robustness".

Thanks.

JP.

---

From: Tomohiro Otani <[email-masked]>
Date: Wed, 17 Aug 2005 10:03:07 +0900

Hi Adrian,

Being related with your text and JP's messages, I would ask you
to touch upon the draft: draft-otani-ccamp-interas-gmpls-te-03.txt.
Is this related with a kind of baseline for (1) Analysis of inter-domain
issues ?

So far, there is a proposed draft of GMPLS inter-domain signaling
as we discussed in Paris, but there is no draft of GMPLS inter-domain
routing definition whether it is with TE extension or not.
(your framework draft covers these points)

Regards,

tomo

---

From: Kenji Kumaki <[email-masked]>
Date: Wed, 17 Aug 2005 11:18:18 +0900

Hi Adrian,

I have some comments on new items.

>   - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt

draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt includes MPLS/GMPLS
interworking requirements and soultions.
So I think this draft should be put in the first version of WG draft.

> * submit Informational I-D for IESG review

Zafar's draft is merged into draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt.
So I think you should replace Zafar's to mine.

Thanks,
Kenji

On Tue, 16 Aug 2005 12:28:11 +0100

-- 
Kenji Kumaki <[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Aug 2005 10:23:09 +0100

Hi Kenji,

> So I think this draft should be put in the first version of WG draft.

As I said

> >   - material from
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt
> Zafar's draft is merged into
draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt.
> So I think you should replace Zafar's to mine.

Noted.

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Aug 2005 10:41:05 +0100

Hi Tomo,

> (your framework draft covers these points)

Good point.

It seems that your draft is discussing two things:
1. TE reachability information exchange
2. Exchange of aggregated TE information for a domain

As you point out in section 4.2, the issue of scalability and policy needs
to be carefully considered before we pursue this too much further.

I think your work, especially the aggregation issues, meshes nicely with
the recent draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt. Therefore, I
propose the following changes to the draft I sent out before...

1. Delete
   Jan 06 First version WG I-D Routing and signaling for complex optical
constraints
   Oct 07 Submit Routing and signaling for complex optical constraints I-D
for IESG review
2. Insert
   Jan 06 First version WG I-D Routing and signaling for link viability
constraints
   Oct 07 Submit Routing and signaling for link viability constraints I-D
for IESG review
3. Delete
    More forward-looking
    ====================
      Routing and signaling for complex constraints and inter-domain
        * first version of WG draft
          - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
        * submit for IESG review
4. Add to Inter-domain section
    - Analysis and protocol changes for routing and signaling for link
viability constraints
      * first version of WG draft
        - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
        - material from draft-otani-ccamp-interas-gmpls-te-03.txt
      * submit for IESG review

Cheers,
Adrian

---

From: Wataru Imajuku <[email-masked]>
Date: Thu, 18 Aug 2005 10:20:13 +0900

Hi, Adrian

  Thank you for sending milestones.

  I noticed that the issue of coordination with lcas & vcat
will be based on
  draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt

  I understand that LCAS/VCAT control draft will be done in single draft
which have statements all of requirements, analysis, and solution.

  I believe that my draft includes some issues which have not addressed in
bernsteins draft.
  For example, the issue of section 5 in my draft.
  This is important issue when LCAS&VCAT will be applied in MRN.

  I understand your proposal is my requirement draft
    draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt
  will be merged with draft-bernstein-ccamp-....

  or simply discard ?

Best Regards,
Wataru

>Note that this looks like a lot of milestones, but please read the text on 
>this issue in the attached file. The bottom line is that this is a product 
>of micro management where I have tried to identify all of the I-Ds that we 
>might produce to cover the referenced work, and where I have placed two 
>(sometimes three) milestones for each I-D.
>
>This micro-management may be over the top, and represents a full pendulum 
>swing from the previous style of CCAMP milestones, but in the light of the 
>hiatus of the last 12 months, i think this may be beneficial and might 
>achieve rapid forwards movement.
>

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL +81-46-859-4315
FAX +81-46-859-5541

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Aug 2005 10:42:26 +0100

Hi Wataru,

>   will be merged with draft-bernstein-ccamp-....

As I said in my original email...
>>   show the ADs that work is already in progress. All I-Ds

Nothing of value will be thrown away.
All input to working group drafts is welcome whether it is supplied as
comments on the email list or as a separate I-D.

With regard to your section 5, I note that you consider the VCAT group
analogous with a link bundle. I don't think this is correct because the
members of a link bundle must be selected and used individually. A payload
data stream cannot be distributed across multiple component links of the
bundle...
   An LSP with a bandwidth requirement b and
   setup priority p fits in a bundled link if at least one component
   link has maximum LSP bandwidth >= b at priority p.
However, the whole point of a VCAT group is to produce a single entity
(pipe) with maximum LSP bandwidth greater than the capacity of any
individual component. A VCAT group, therefore, is not a bundle.

Following on from this, I think that the remainder of your section 5.1
will have some value, but needs to be corrected to properly reflect the
meaning of a VCAT group.

In general, I think your section 5 should generalize from the specific
case of the FA to include any TE link that is based on a VCAT group.

Section 5.2 seems to confuse "FA" with "FA LSP".

Regards,
Adrian

---

From: Wataru Imajuku <[email-masked]>
Date: Fri, 19 Aug 2005 05:59:21 +0900

Hi, Adrian

  Thank you for giving your time interim your hard work.

>Section 5.2 seems to confuse "FA" with "FA LSP".

  Regarding to VCAT, I agree to your comment.
  But, this draft also covers LAGR (link aggregation) which has some limitations
to transmit data-flow exceeding the bandwidth of each comopnent LSP.

  This is one of reason why the description wirtten in Section 5 exists, although
some terminologies are not proper as you noted.

Thanks
Wataru

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 19 Aug 2005 12:20:36 +0100

Hi,

Thanks for your comments.

Do you think it may be premature to apply 803.2ad techniques before we
have done any work to control Ethernet networks with GMPLS?

You are right that IEEE link aggregation is conceptually very close to
bundling.

I suggest that you need to separate TDM and Ethernet concepts in your I-D.
Take the TDM issues to Diego, Richard, Greg et alia for inclusion in the
VCAT/LCAS work. Take your LAGR issues to Dimitri and Loa for inclusion in
the "GMPLS control of Ethernet switching" work that they are doing.

Thanks,
Adrian

---

From: Wataru Imajuku <[email-masked]>
Date: Sun, 21 Aug 2005 02:59:12 +0900

Hi, Adrian

  Thanks.
  I'd like to do so.

Best Regards
Wataru

---

From: Tomohiro Otani <[email-masked]>
Date: Mon, 22 Aug 2005 08:25:10 +0900

Hi Adrian,

Thank you for your e-mail message clarifying my comments.
I agree with your proposed milestone.

One point is that as you mentioned, our draft covers;
1. TE reachability information exchange
2. Exchange of aggregated TE information for a domain
In addition to these, in our draft, I also assume that GMPLS
inter-domain routing is required to exchange reachability information.
The draft should be short enough to clarify whether we
rely on the same (existing) protocol mechanism as IP/MPLS.

Regards,

tomo