Subject: Liaison Reply regarding L1VPNs

From: Kireeti Kompella <[email-masked]>
Date: Mon, 28 Jun 2004 02:53:34 -0700 (PDT)

To:          Mr. Marco Carugi, Rapporteur for Question 11 of ITU-T Study Group 13.
 From:        Adrian Farrel and Kireeti Kompella
                 Co-chairs of the CCAMP Working Group of the IETF
 Cc:          Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
 For:         Information
 Deadline:    None
 Subject:     Reply to Liaison Statement on L1VPNs

Dear Mr. Carugi,

Thank you for your liaison statement COM13-LS23 dated 3-12 February
2004 on the subject of Layer One VPNs and related work within Study
Group 13.

Thanks also to the members of Study Group 13 Question 11 for their
work on draft-takeda-l1vpn-framework-00.txt which represents so clearly
the motivations for L1VPNs, the high level (service level) requirements,
and the architectural models that might be used to build L1VPNs.

Members of the CCAMP working group have expressed a considerable
interest in this work and we are keen to pursue a working relationship
with SG13 to advance the description of the functional requirements,
assess current protocols for suitability, and develop any protocol
extensions that may be necessary.

Some feedback on draft-takeda-l1vpn-framework-00.txt has already been
made on the CCAMP mailing list and we know that the authors of the
draft are aware of the comments.  Hopefully this is valuable input and
will be taken back for discussion in Q.11 where appropriate.

In order to further facilitate the discussion of L1VPN within the
IETF, we have started a new mailing list designated for L1VPN emails
only.  In keeping with all IETF mailing lists, this list is open to
all and we would welcome active participation from SG13 delegates and
attendees, and from anyone else who can contribute in this area.

We anticipate that initial discussions will focus on
draft-takeda-l1vpn-framework-00.txt, but that we will move on to an
analysis of the short-comings of existing IETF protocols in the
delivery of L1VPNs.

To join the mailing list please visit
https://www1.ietf.org/mailman/listinfo/l1vpn.  The mailing list will
also be archived and can be read on the Web at
ftp://ftp.ietf.org/ietf-mail-archive/l1vpn/

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Delivery-date: Mon, 28 Jun 2004 09:56:57 +0000
Date: Mon, 28 Jun 2004 02:53:34 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Marco Carugi <[email-masked]>
cc: Adrian Farrel <[email-masked]>, Bill Fenner <[email-masked]>, Kireeti Kompella <[email-masked]>, Alex Zinin <[email-masked]>, [email-masked], IESG Secretary <[email-masked]>
Subject: Liaison Reply regarding L1VPNs

 To:          Mr. Marco Carugi, Rapporteur for Question 11 of ITU-T Study Group 13.
 From:        Adrian Farrel and Kireeti Kompella
                 Co-chairs of the CCAMP Working Group of the IETF
 Cc:          Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
 For:         Information
 Deadline:    None
 Subject:     Reply to Liaison Statement on L1VPNs

Dear Mr. Carugi,

Thank you for your liaison statement COM13-LS23 dated 3-12 February
2004 on the subject of Layer One VPNs and related work within Study
Group 13.

Thanks also to the members of Study Group 13 Question 11 for their
work on draft-takeda-l1vpn-framework-00.txt which represents so clearly
the motivations for L1VPNs, the high level (service level) requirements,
and the architectural models that might be used to build L1VPNs.

Members of the CCAMP working group have expressed a considerable
interest in this work and we are keen to pursue a working relationship
with SG13 to advance the description of the functional requirements,
assess current protocols for suitability, and develop any protocol
extensions that may be necessary.

Some feedback on draft-takeda-l1vpn-framework-00.txt has already been
made on the CCAMP mailing list and we know that the authors of the
draft are aware of the comments.  Hopefully this is valuable input and
will be taken back for discussion in Q.11 where appropriate.

In order to further facilitate the discussion of L1VPN within the
IETF, we have started a new mailing list designated for L1VPN emails
only.  In keeping with all IETF mailing lists, this list is open to
all and we would welcome active participation from SG13 delegates and
attendees, and from anyone else who can contribute in this area.

We anticipate that initial discussions will focus on
draft-takeda-l1vpn-framework-00.txt, but that we will move on to an
analysis of the short-comings of existing IETF protocols in the
delivery of L1VPNs.

To join the mailing list please visit
https://www1.ietf.org/mailman/listinfo/l1vpn.  The mailing list will
also be archived and can be read on the Web at
ftp://ftp.ietf.org/ietf-mail-archive/l1vpn/

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Delivery-date: Fri, 25 Jun 2004 19:07:10 +0000
Content-Class: urn:content-classes:message
Subject: RE: Path Computation Element (PCE) BOF
Date: Fri, 25 Jun 2004 14:01:23 -0500
From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
To: <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>, <[email-masked]>, "TEWG" <[email-masked]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>, "Jean Philippe Vasseur" <[email-masked]>, "Adrian Farrel" <[email-masked]>

All,

Please review and comment on "Path Computation Element (PCE) Problem
Statement"
http://www.ietf.org/internet-drafts/draft-ash-pce-problem-statement-00.t
xt.  The PCE is an approach to MPLS traffic engineering that is
applicable to inter-area and inter-AS path computation.  A problem
statement and overview of solution alternatives is provided.  This will
be discussed during the PCE BOF outlined below.

Thanks,
Jerry=20

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Thursday, June 17, 2004 5:01 PM
To: [email-masked]; [email-masked]'; [email-masked];
[email-masked]; TEWG
Cc: 'Jean Philippe Vasseur'
Subject: Path Computation Element (PCE) BOF

Hi,
=20
We will be holding a BOF in San Diego under the care of the Routing
Area.
=20
Please see the description, a draft agenda, and proposed charter below.
=20
We'd welcome any thoughts for additions to the agenda, and any pointers
to existing drafts that you consider already fit within this scope.
=20
If you have views for or against, please bring them to the BOF where we
will hopefully have time to air them fully.
=20
Thanks,
Adrian and JP
=20
=3D=3D=3D=3D
Path Computation Element BOF (PCE BOF) Agenda
60th IETF, San Diego, August 2004
=20
Routing Area Ads: Alex Zinin ([email-masked] <mailto:[email-masked]> ),
                  Bill Fenner ([email-masked]
<mailto:[email-masked]> )

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

Description:
In certain MPLS TE networks it may be beneficial or desirable to have
path=20
computation performed by a distinct node (termed the Path Computation=20
Element  PCE) that is not the LSR that needs to know the path. This BOF=20
examines the scope of such function, what extensions to existing
protocols=20
might required, what additional protocols may need to be developed, and=20
whether there is cuase and support for this work within the IETF.

---

Proposed BOF agenda
1) Introduction, admin, statement of objectives of the BOF (10 minutes)
2) Overview of PCE-based LSP Path computation (10 minutes)
         - terminology
         - dichotomy (centralized versus distributed, statefull versus=20
           stateless, ...)
3) Requirements for PCE-based path computation (5 minutes)
         - for intra-area TE LSP (packet and non packet LSP, multiple=20
           criteria optimization techniques, online/offline)
         - for inter-area and inter-AS TE (shared information or=20
           collaborative computation)
4) Functional requirements of a PCE-based path computation system  (10
minutes)
         - Framework,
         - Path computation model
         - discovery of PCEs within a network
         - distribution of TE information to PCEs
         - LSR-PCE communication
         - Monitoring and Management (MIBs)
         - Policy/Security/Confidentiality in the context of
inter-providers
5) Current status of drafts and early implementations (10 minutes)
6) Why should this be IETF work? (5 minutes)
         - CCAMP or new Working Group?
         - Is this work limited to MPLS-TE? What about BGP route
servers?
7) Proposed charter (see below) (10 minutes)
8) Open discussion (50 minutes)
9) Summary and conclusions (10 minutes)

---

Proposed WG Charter
=20
Organizational Overview
The PCE working group coordinates the work within the IETF of defining
the=20
operation of path computation elements within the Internet. Path=20
computation elements are responsible for computing paths through IP=20
networks for uses such as traffic engineering so that a prime consumer
of=20
such paths might be an MPLS-TE LSR. Areas of responsibility will include

the collection of attributes relevant to the computation of paths, the=20
discovery by LSRs of available path computation elements, the
communication=20
with LSRs for the request of path computation, the collaboration between

path computation elements within the network, and analysis of path=20
computation algorithms with a view to ensuring consistency between
computed=20
paths. The working group will work closely with many working groups in
the=20
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=20
  techniques involving Path Computation Element(s). This includes the
intra=20
  IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path=20
  computation for Point-to-Point, Point-to-Multipoint and=20
  Multipoint-to-Multipoint TE LSPs.
- Definition of protocol-independent metrics and constraints defining
path=20
  quality measurement criteria, algorithm complexity and scalability
criteria=20
  related to path computation techniques.
- Definition of requirements for communication between LSRs and PCEs=20
  including routing extensions in support of PCE discovery techniques
within=20
  an IGP area and across multiple IGP areas, ASes and Provider networks,
and=20
  including the development of new protocols or protocol extensions for=20
  requesting path computation and supplying responses. Any protocol=20
  extensions will developed in conjunction with the working groups in
charge=20
  of the specific protocols.
- Specification of routing (OSPF, ISIS, BGP) and signalling extensions=20
  (RSVP-TE) required by PCE-based path computation techniques. The
extensions=20
  will developed in conjunction with the working groups in charge of the

  specific protocols.
- Specification of requirements and protocol extensions related to the=20
  policy, security and confidentiality aspects of PCE-based path
computation=20
  techniques involving PCEs of multiple Providers.
- Definition of MIBs, management procedures related to the protocol=20
  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=20
  PCE model.

  Select a single candidate protocol from communication between LSRs=20
  and PCEs.

  Submit document(s) that define various path computation models
=20
  Submit an analysis document examining the requirements for coherent
  computation techniques and the implication of cooperation between=20
  PCEs.

  Submit a document defining the protocol for communication between=20
  LSRs and PCEs.

  Submit document(s) defining extensions to routing and signalling=20
  protocols necessary to support the use of a PCE model within MPLS
  networks.
=20
  Submit a document defining MIB modules for modeling and management=20
  of PCE systems.

Delivery-date: Fri, 18 Jun 2004 13:51:39 +0000
Content-class: urn:content-classes:message
Subject: RE : RE : RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Fri, 18 Jun 2004 15:49:56 +0200
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>
Cc: <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>

Hi Arthi

Please see inline

Regards,

JL

>> >As I explained in my email to JP, it is still somewhat=20
>unclear as to=20
>> >what the ability to signal the desired method buys the=20
>provider, and=20
>> >exactly why or how that simplifies LSP management.
>>
>> Basically, as mentionned by JP, the signaling method used=20
>will have a=20
>> non negligeable impact on important features (Reoptimization, FRR,=20
>> rerouting). For instance, if you use sitching or nesting, you will=20
>> face FRR issues as regards ABR protection.
>----------> Let me try to explain this, if possible with a couple of
>examples:
>Re-optimization
>---------------
>Actually, nothing prevents you from having Head-end Control of=20
>re-optimzation even with the non-contiguous signaling methods.=20
>It is just that with the non-contiguous signaling methods, one=20
>can, if desired, also have the ability to do a local=20
>re-optimization. But if you do not want this 'intermediate=20
>re-optimization' behavior for certain LSPs, you may want to=20
>signal that explicitly or configure it on the box.

Agree

>
>Crankback/Re-routing
>---------------------
>The crankback document actually provides a similar ability for=20
>controlling re-routing at intermediate nodes by signaling this=20
>explicitly.

Agree,

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

Delivery-date: Fri, 18 Jun 2004 12:23:45 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Response to OIF communication of June 4th
Date: Fri, 18 Jun 2004 09:14:21 +0100

Response from Steve Joiner...
----- Original Message ----- 
From: "Steve Joiner" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>; <[email-masked]>; "'Bill Fenner'"
<[email-masked]>; "'Kimberly Chiu'" <[email-masked]>; <[email-masked]>;
"'Jim Jones'" <[email-masked]>; <[email-masked]>
Sent: Thursday, June 17, 2004 9:49 PM
Subject: RE: Response to OIF communication of June 4th

Adrian,

I received your communication and will forward it to our membership.  It
will be reviewed at our next meeting in late July.

We look forward to continued open communication.

Let me know when you are ready to pursue more formal relationship
between the two bodies.

-steve
OIF TC Chair

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Thursday, June 17, 2004 12:42 PM
To: Steve Joiner
Cc: 'Kireeti Kompella'; Adrian Farrel; [email-masked]; Bill Fenner;
Kimberly Chiu; [email-masked]; Jim Jones; [email-masked]
Subject: Response to OIF communication of June 4th

To        OIF, Technical Committee Chair, Steve Joiner,
<mailto:[email-masked]> [email-masked]
Cc         <mailto:[email-masked]> [email-masked]
             <mailto:[email-masked]> [email-masked]
            A. Zinin, B. Fenner (IETF Routing ADs)
            K. Kompella, A. Farrel (CCAMP WG chairs)
            CCAMP WG

Dear Mr. Joiner,

Thank you for your response of June 4th, it is good to have opened
up some communication channels between the OIF and CCAMP. We will
investigate what is necessary to establish a more formal
relationship between the two bodies.

We are happy to note the importance that you put on the feedback
process from the OIF to the IETF with respect to GMPLS
standardisation, and in view of this we are pleased to inform the
OIF that IETF CCAMP WG has initiated a Design Team on GMPLS ASON
Routing Solutions.  The GMPLS ASON Routing Solutions Design Team's
Charter is as below. Initially the output will be in the form of
IETF drafts. We will send you the output of the DT over the next
months.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

=====

ASON Routing Solutions Design Team
----------------------------------

Members (alphabetical order):

       Chris Hopps < <mailto:[email-masked]> [email-masked]>
       Lyndon Ong < <mailto:[email-masked]> [email-masked]>
       Dimitri Papadimitriou < <mailto:[email-masked]>
[email-masked]>
       Jonathan Sadler < <mailto:[email-masked]>
[email-masked]>
       Stephen Shew < <mailto:[email-masked]>
[email-masked]>
       Dave Ward < <mailto:[email-masked]> [email-masked]>

Charter:
-------
To evaluate existing IETF routing protocols against the ASON routing
requirements that were documented in
<draft-ietf-ccamp-gmpls-ason-routing-reqts> as a joint effort of the
IETF CCAMP Working Group and ITU-T SG15.

This evaluation is to be produced by a close examination of
applicability scenarios.  The result of the evaluation of these
scenarios is an integral part of the output of this design team.

The design team will then move on to the design of extensions to
the IETF routing protocols as appropriate in close collaboration
with the corresponding Working Groups (such as the OSPF, IS-IS and
IDR working groups).

Consideration should also be given to the exclusion of protocol
elements or procedures that are not appropriate or relevant in
the ASON routing scenarios that the team describes.

Finally, the design team is responsible for drafting liaison
statements from the CCAMP WG to the ITU-T SG15 and OIF regarding
GMPLS ASON routing solutions, as well as for drafting replies to
liaisons received from the ITU-T SG15 and OIF.  Note that no
Liaisons drafted by the design team will be sent or replied to
without approval from the CCAMP WG chairs, ADs and rough
consensus of the CCAMP WG.

Standard design team disclaimer: this design team has no special
status in the CCAMP WG.  Any documents they produce are subject to
the usual WG procedures.  Individuals are encouraged to interact
with the design team, to offer suggestions, review the output and,
if they feel so inclined, to submit their own drafts.

Milestones (all on the 15th of the month):
----------

Jun '04: send Liaison to ITU-T SG15 and OIF stating creation of DT
         and charter
Jul '04: first draft of "Evaluation of existing IETF routing
         protocols against ASON routing requirements including
         evaluation scenarios"
Aug '04: first CCAMP WG document of "Evaluation of existing IETF
         routing protocols against ASON routing requirements
         including evaluation scenarios"
Aug '04: send Liaison to ITU-T SG15 and OIF soliciting input on
         above WG document
Sep '04: first drafts of protocol-specific "Protocol extensions and
         usage procedures for ASON"
Oct '04: first CCAMP WG protocol-specific documents on "Protocol
         extensions and usage procedures for ASON"
Oct '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
         WG documents
Dec '04: CCAMP WG Last Call (including appropriate Routing WG Last
         Call)
Jan '05: hand off documents to IESG

Interactions with other WGs:
------------------------------
The design team is expected to interact with other IETF working groups
as appropriate.  Protocol extensions are not to be developed without
full consultation with the "owning" working group.  That is, while the
protocol extensions are developed within CCAMP, they must be presented
to and discussed with the owning working group which must be given the
opportunity to comment and suggest alternate solutions.  This may
include the IS-IS, OSPF and IDR working groups.

Relevant meetings:
------------------
It is suggested that the design team take full advantage of the
following meetings to advance their discussions face-to-face.  The
team may wish to hold "open" meetings on these occasions to solicit
wider input.

60th IETF San Diego, California, August 1st-6th 2004
ITU-T SG15 Inter-regnum meeting on ASON routing, Berlin, Germany,
   November 1st-5th 2004
61st IETF Washington, DC, November 7th-12th 2004

Delivery-date: Thu, 17 Jun 2004 21:30:23 +0000
Date: Thu, 17 Jun 2004 14:28:14 -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 : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt

Hi JL,

Some comments inline.

<snipped>
> ><snip>
> >
> >As I explained in my email to JP, it is still somewhat unclear
> >as to what the ability to signal the desired method buys the
> >provider, and exactly why or how that simplifies LSP management.
>
> Basically, as mentionned by JP, the signaling method used will have a
> non negligeable impact on important features (Reoptimization, FRR,
> rerouting). For instance, if you use sitching or nesting, you will face
> FRR issues as regards ABR protection.
----------> Let me try to explain this, if possible with a couple of
examples:
Re-optimization
---------------
Actually, nothing prevents you from having Head-end Control of
re-optimzation even with the non-contiguous signaling methods. It is just
that with the non-contiguous signaling methods, one can, if desired, also
have the ability to do a local re-optimization. But if you do not want
this 'intermediate re-optimization' behavior for certain LSPs, you may
want to signal that explicitly or configure it on the box.

Crankback/Re-routing
---------------------
The crankback document actually provides a similar ability for
controlling re-routing at intermediate nodes by signaling this
explicitly.

So, I think that it is basically upto the solutions documents to
address these functionalities. In fact, Dimitri had a very good
example of how by restricting the 'signaling method' you could
shoot down one set of benefits for the other.

thanks,
-arthi

> I agree that we could just signal the function/service
>  "FRR protection of ABRs", "Head-end Control of reoptimization"...
> This would clearly require the "contiguous" signaling mode

> IMHO, this is simpler to directly signal the signaling mode. I don't
> really see any interop issue here. Basically if an ABR does not support
> the signaling mode, it simply rejects the LSP setup.
>
>
> >
> >
> >> Let's have a look at the FRR draft: There are two modes defined, and
> >> the desired mode (one-to-one or bypass) is signaled on a
> >per-LSP basis
> >> (within the FRR object). I did not see any objection on that.
> >
> >I think the FRR draft is really a solutions draft, and it
> >presents two solutions which offer somewhat different
> >services, in my view. The detour provides the ability to
> >protect segments of a _given_ LSP, while the bypass tunnel
> >provides the ability to simultaneously protect _multiple_ LSPs
> >sharing a given resource (node(s) or link).
> >
> >Also, as Adrian mentioned, it has lead to interop issues.
>
> FRR interop issues was IMHO not related to this flag in the FRR object.
>
>
> >
> >> >
> >> >8. Sec. 7.3 on path optimality talks only of the optimality of a
> >> >single path computed in isolation. What is the definition of
> >> >optimality to be applied for computing diverse paths? (Sec.
> >7.7 later
> >> >does not specifically discuss this aspect either.) If one used CSPF
> >> >in sequence to compute two diverse paths (as this section would
> >> >imply) then the computation may fail, even though a set of optimal
> >> >diverse paths exists (as acknowledged in Sec. 7.7 ahead).
> >>
> >> Agree, we should add a definition of optimality to be applied when
> >> computing diverse path This maybe: A placement of two
> >diverse paths is
> >> optimal if their cumulative cost is minimal.
> >
> >Yes, this is one definition. I think in  some previous email
> >exchanges, Fabio had provided a good definition of optimality
> >for diverse path routing. (I'll try to dig it up in the
> >archives, and post a note separately on it.)
>
> Thanks
>
> >
> >
> >> >9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to underscore
> >> >Adrian's point on specifying the scaling requirements themselves
> >> >(with respect to areas, amount of flooded info. etc.)
> >rather than the
> >> >realization of those requirements (by not adding any info. to the
> >> >LSAs, for example).
> >>
> >>
> >> It seems that you are OK with 5.3 (no comments)
> >> "Containment of routing information MUST not be compromised to allow
> >> inter-area traffic
> >>    engineering. Information propagation for path-selection
> >MUST continue
> >>    to be localized.".
> >> Thus you should also be OK with 7.4
> >
> >Actually, 5.3 imposes a requirement to preserve IGP hierarchy
> >and scalability, but at least leaves open the possibility for
> >the IGP to carry extra information as long as it is not an
> >"unreasonable amount of extra information" that does not
> >"unreasonably increase IGP flooding frequency".
>
> Basically 5.3 points out that information propagation for PATH-SELECTION
> MUST continue to be localized.
> It also means that we allow for the IGP to carry extra information provided that it is NOT topology related...
>
> >
> >I thought 7.4 should probably provide some specifics on what
> >unreasonable is, and leave it to the protocol designers to
> >devise protocols that keep within those limits. Instead it
> >seems to prescribe a realization -- one where no topology
> >related info. of any sort should be added to the IGP LSAs.
> >
> >> Basically we want to preserve IGP hierachy concept, are there
> >> objections to that point ?
> >
> >Depends on whether you want to preserve it in spirit or to the
> >letter :-). I think it may be useful to give protocol
> >designers some wiggle room.
>
> IMHO it is also useful to tell protocol designers what we don't want in our networks...
>
> >
> >> This means, for ISPs contributing to this draft, "no leaking of any
> >> topology related info accross areas". Of course, this does not
> >> preclude the addition of info to the LSA, provided that it is not
> >> topology related.
> >>
> >> >
> >> >If solutions can meet the scaling requirements by adding a bit of
> >> >info. to the IGP, I think this should be allowed, otherwise
> >there is
> >> >really not much that could be achieved using current mechanisms
> >> >(since no modifications to them seem permissible, and we already
> >> >established that these, as they exist, do not provide for adequate
> >> >inter-area MPLS TE).
> >> >
> >> >BTW, one of the points made in this regard in these
> >> >email thread was about the use of path computation servers,
> >which can
> >> >supposedly compute optimal paths without any impact on the IGP.
> >> >
> >> >I think this argument isn't quite complete, since it hides the
> >> >signaling extensions required for these as well as the scalability
> >> >impact of recursive PCE-type schemes (btw, this was a question that
> >> >came up in independent discussions with JP in the context
> >of the ARO
> >> >and PCE schemes, and is still under discussion).
> >>
> >> Let's continue this discussion in another thread addressing solutions
> >
> >Ok, sure.
> >
> >
> >> >10. Sec. 7.6, the figure O(N^2) makes the assumption that
> >each of the
> >> >N ARBs at the border of the neighboring areas is connected to each
> >> >other ABR. No? In reality, the number of crankback's may be
> >> >significantly less therefore.
> >>
> >> No, basically if you have X1 ABRs in head-end area and X2 ABRs in
> >> tail-end area you may have up to X1*X2 crankbacks, provided
> >that there
> >> is a path between all ABRs. This does not assume direct connectivity
> >> between ABRs.
> >
> >
> >Ok, thanks. I see now what you are saying.
> >
> >> >11. Sec. 7.7, I guess it would be useful to qualify what is
> >> >considered "extra-load" in signaling and routing here. Is
> >that to be
> >> >interpreted as _absolutely no change_ to current signaling and
> >> >routing protocol objects?
> >>
> >> No, this should not be interpreted as "absolutely no change".
> >> Basically the solution must respect scalability requirements
> >spelt out
> >> in 5.2 Will clarify in next revision.
> >>
> >>
> >> >seem feasible, if inter-area routing/TE is to be achieved, so
> >> >something more specific is implied, which would be good to
> >spell out.
> >> >
> >> >BTW, also tend to agree with Adrian's point that this section seems
> >> >to be describing the computation of diverse paths rather than the
> >> >establishment of diverse paths, which would seem to be the
> >> >requirement.
> >>
> >> Yes this is basically a requirement on computation, but in this
> >> inter-domain context Path computation and Path establishment are no
> >> longer necessarily independant (see your ARO proposal)
> >>
> >>
> >> >
> >> >12. Sec. 7.9, what is meant by "inter-area head end LSR"?
> >> >An LSR that is the head-end of an inter-area LSP (that is, an LSP
> >> >traversing multiple areas)?
> >>
> >> Yes, will reword
> >>
> >> >
> >> >13. Sec. 8.2, not sure that is providing a real measurable
> >evaluation
> >> >criterion. If it is to be kept, some specifics should probably be
> >> >given.
> >
> >JL, sure. The perf. requirements are given in Sec. 8.1, but I
> >was looking at Sec. 8.2.
>
> OK, in 8.2 the criteria is more qualitative than quantitative
>
> >
> >Also, even for 8.1, it may be good to add the = to explanation
> >for (1) and (2) that you've given below.
>
> OK
>
> >
> >> IMHO what we list is clearly measurable
> >>    (1) Optimality of the computed inter-area TE LSP path.
> >> = Computed cost - Shortest cost
> >>    (2) Optimality of the computed backup tunnel path
> >protecting against
> >>        the failure of an ABR, capability to share bandwidth
> >among backup
> >>        tunnels protecting independent facilities
> >> = Total backup bandwidth consumption
> >>    (3) Inter-area TE LSP set up time.
> >>  = clearly measurable
> >>    (4) RSVP-TE and IGP scalability (state impact, number of messages,
> >>        message size)
> >>  = Memory footprint increase, CPU load increase, Message size
> >> Increase...This is also definitely measurable.
> >>
>
> >
>
> Thanks again for these comments. We will post, on Monday, a new revision incorporating received comments.
>
> Regards,
>
> JL
>
>

Delivery-date: Thu, 17 Jun 2004 21:07:56 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "[email-masked]'" <[email-masked]>, <[email-masked]>, <[email-masked]>, "TEWG" <[email-masked]>
Cc: "'Jean Philippe Vasseur'" <[email-masked]>
Subject: Path Computation Element (PCE) BOF
Date: Thu, 17 Jun 2004 22:01:25 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_01D7_01C454B6.A251D6F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

We will be holding a BOF in San Diego under the care of the Routing =
Area.

Please see the description, a draft agenda, and proposed charter below.

We'd welcome any thoughts for additions to the agenda, and any pointers =
to existing drafts that you consider already fit within this scope.

If you have views for or against, please bring them to the BOF where we =
will hopefully have time to air them fully.

Thanks,
Adrian and JP

=3D=3D=3D=3D
 Path Computation Element BOF (PCE BOF) Agenda
60th IETF, San Diego, August 2004
=20
 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=20
computation performed by a distinct node (termed the Path Computation=20
Element  PCE) that is not the LSR that needs to know the path. This BOF=20
examines the scope of such function, what extensions to existing =
protocols=20
might required, what additional protocols may need to be developed, and=20
whether there is cuase and support for this work within the IETF.

---
=20
Proposed BOF agenda
1) Introduction, admin, statement of objectives of the BOF (10 minutes)
2) Overview of PCE-based LSP Path computation (10 minutes)
         - terminology
         - dichotomy (centralized versus distributed, statefull versus=20
           stateless, ...)
3) Requirements for PCE-based path computation (5 minutes)
         - for intra-area TE LSP (packet and non packet LSP, multiple=20
           criteria optimization techniques, online/offline)
         - for inter-area and inter-AS TE (shared information or=20
           collaborative computation)
4) Functional requirements of a PCE-based path computation system  (10 =
minutes)
         - Framework,
         - Path computation model
         - discovery of PCEs within a network
         - distribution of TE information to PCEs
         - LSR-PCE communication
         - Monitoring and Management (MIBs)
         - Policy/Security/Confidentiality in the context of =
inter-providers
5) Current status of drafts and early implementations (10 minutes)
6) Why should this be IETF work? (5 minutes)
         - CCAMP or new Working Group?
         - Is this work limited to MPLS-TE? What about BGP route =
servers?
7) Proposed charter (see below) (10 minutes)
8) Open discussion (50 minutes)
9) Summary and conclusions (10 minutes)

---
=20
Proposed WG Charter
=20
Organizational Overview
The PCE working group coordinates the work within the IETF of defining =
the=20
 operation of path computation elements within the Internet. Path=20
computation elements are responsible for computing paths through IP=20
networks for uses such as traffic engineering so that a prime consumer =
of=20
such paths might be an MPLS-TE LSR. Areas of responsibility will include =

the collection of attributes relevant to the computation of paths, the=20
discovery by LSRs of available path computation elements, the =
communication=20
with LSRs for the request of path computation, the collaboration between =

path computation elements within the network, and analysis of path=20
computation algorithms with a view to ensuring consistency between =
computed=20
paths. The working group will work closely with many working groups in =
the=20
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=20
  techniques involving Path Computation Element(s). This includes the =
intra=20
  IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path=20
  computation for Point-to-Point, Point-to-Multipoint and=20
  Multipoint-to-Multipoint TE LSPs.
- Definition of protocol-independent metrics and constraints defining =
path=20
  quality measurement criteria, algorithm complexity and scalability =
criteria=20
  related to path computation techniques.
- Definition of requirements for communication between LSRs and PCEs=20
  including routing extensions in support of PCE discovery techniques =
within=20
  an IGP area and across multiple IGP areas, ASes and Provider networks, =
and=20
  including the development of new protocols or protocol extensions for=20
  requesting path computation and supplying responses. Any protocol=20
  extensions will developed in conjunction with the working groups in =
charge=20
  of the specific protocols.
- Specification of routing (OSPF, ISIS, BGP) and signalling extensions=20
  (RSVP-TE) required by PCE-based path computation techniques. The =
extensions=20
  will developed in conjunction with the working groups in charge of the =

  specific protocols.
- Specification of requirements and protocol extensions related to the=20
  policy, security and confidentiality aspects of PCE-based path =
computation=20
  techniques involving PCEs of multiple Providers.
- Definition of MIBs, management procedures related to the protocol=20
  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=20
  PCE model.

  Select a single candidate protocol from communication between LSRs=20
  and PCEs.

  Submit document(s) that define various path computation models
=20
  Submit an analysis document examining the requirements for coherent
  computation techniques and the implication of cooperation between=20
  PCEs.

  Submit a document defining the protocol for communication between=20
  LSRs and PCEs.

  Submit document(s) defining extensions to routing and signalling=20
  protocols necessary to support the use of a PCE model within MPLS
  networks.
=20
  Submit a document defining MIB modules for modeling and management=20
  of PCE systems.

------=_NextPart_000_01D7_01C454B6.A251D6F0
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>We will be holding a BOF in San Diego =
under the=20
care of the Routing Area.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Please see the description, a draft =
agenda, and=20
proposed charter below.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>We'd welcome any thoughts for =
additions to the=20
agenda, and any pointers to existing drafts that you consider already =
fit within=20
this scope.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>If you have views for or against, =
please bring=20
them to the BOF where we will hopefully have time to air them=20
fully.</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 and JP</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2> Path Computation Element BOF (PCE =
BOF)=20
Agenda<BR>60th IETF, San Diego, August 2004<BR>&nbsp;<BR> Routing Area =
Ads: Alex=20
Zinin (</FONT><A href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>),</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;Bill Fenner&nbsp;(</FONT><A =
href=3D"mailto:[email-masked]"><FONT=20
face=3DCourier size=3D2>[email-masked]</FONT></A><FONT =
face=3DCourier=20
size=3D2>)<BR><BR>BOF Chairs: JP Vasseur (</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>),</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;Adrian=20
Farrel&nbsp;(</FONT><A href=3D"mailto:[email-masked]"><FONT =
face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier=20
size=3D2>)<BR><BR>Description:<BR>In certain MPLS TE networks it may be =
beneficial=20
or desirable to have path&nbsp;<BR>computation performed by a distinct =
node=20
(termed the Path Computation&nbsp;<BR>Element&nbsp; PCE) that is not the =
LSR=20
that needs to know the path. This BOF&nbsp;<BR>examines the scope of =
such=20
function, what extensions to existing protocols&nbsp;<BR>might required, =
what=20
additional protocols may need to be developed, and&nbsp;<BR>whether =
there is=20
cuase and support for this work within the IETF.<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>---</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;<BR>Proposed BOF agenda<BR>1) =
Introduction,=20
admin, statement of objectives of the BOF (10 minutes)<BR>2) Overview of =

PCE-based LSP Path computation (10=20
minutes)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
terminology<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
dichotomy=20
(centralized versus distributed, statefull=20
versus&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;stateless,=20
...)<BR>3) Requirements for PCE-based path computation (5=20
minutes)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - for =
intra-area TE=20
LSP (packet and non packet LSP,=20
multiple&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;criteria=20
optimization techniques,=20
online/offline)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
for=20
inter-area and inter-AS TE (shared information=20
or&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;collaborative computation)<BR>4) Functional requirements of a =
PCE-based=20
path computation system&nbsp; (10=20
minutes)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
Framework,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Path=20
computation model<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
discovery of PCEs within a=20
network<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
distribution of TE=20
information to PCEs<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-=20
LSR-PCE =
communication<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
Monitoring and Management=20
(MIBs)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
Policy/Security/Confidentiality in the context of inter-providers<BR>5) =
Current=20
status of drafts and early implementations (10 minutes)<BR>6) Why should =
this be=20
IETF work? (5 =
minutes)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=20
CCAMP or new Working =
Group?<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
- Is this work limited to MPLS-TE? What about BGP route servers?<BR>7) =
Proposed=20
charter (see below) (10 minutes)<BR>8) Open discussion (50 =
minutes)<BR>9)=20
Summary and conclusions (10 minutes)<BR></DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>---</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;<BR>Proposed WG=20
Charter<BR>&nbsp;<BR>Organizational Overview<BR>The PCE working group=20
coordinates the work within the IETF of defining the&nbsp;<BR> operation =
of path=20
computation elements within the Internet. Path&nbsp;<BR>computation =
elements are=20
responsible for computing paths through IP&nbsp;<BR>networks for uses =
such as=20
traffic engineering so that a prime consumer of&nbsp;<BR>such paths =
might be an=20
MPLS-TE LSR. Areas of responsibility will include&nbsp;<BR>the =
collection of=20
attributes relevant to the computation of paths, the&nbsp;<BR>discovery =
by LSRs=20
of available path computation elements, the communication&nbsp;<BR>with =
LSRs for=20
the request of path computation, the collaboration between&nbsp;<BR>path =

computation elements within the network, and analysis of=20
path&nbsp;<BR>computation algorithms with a view to ensuring consistency =
between=20
computed&nbsp;<BR>paths. The working group will work closely with many =
working=20
groups in the&nbsp;<BR>Routing Area including the OSPF, IS-IS, IDR, MPLS =
and=20
CCAMP working groups.<BR><BR>Working Group Scope<BR>The PCE working =
group scope=20
includes:<BR>- Definition&nbsp; of Generalized Traffic Engineered LSP =
paths=20
computation&nbsp;<BR>&nbsp; techniques involving Path Computation =
Element(s).=20
This includes the intra&nbsp;<BR>&nbsp; IGP area, inter IGP area, =
inter-AS and=20
inter-provider TE LSPs path&nbsp;<BR>&nbsp; computation for =
Point-to-Point,=20
Point-to-Multipoint and&nbsp;<BR>&nbsp; Multipoint-to-Multipoint TE =
LSPs.<BR>-=20
Definition of protocol-independent metrics and constraints defining=20
path&nbsp;<BR>&nbsp; quality measurement criteria, algorithm complexity =
and=20
scalability criteria&nbsp;<BR>&nbsp; related to path computation=20
techniques.<BR>- Definition of requirements for communication between =
LSRs and=20
PCEs&nbsp;<BR>&nbsp; including routing extensions in support of PCE =
discovery=20
techniques within&nbsp;<BR>&nbsp; an IGP area and across multiple IGP =
areas,=20
ASes and Provider networks, and&nbsp;<BR>&nbsp; including the =
development of new=20
protocols or protocol extensions for&nbsp;<BR>&nbsp; requesting path =
computation=20
and supplying responses. Any protocol&nbsp;<BR>&nbsp; extensions will =
developed=20
in conjunction with the working groups in charge <BR>&nbsp; of the =
specific=20
protocols.<BR>- Specification of routing (OSPF, ISIS, BGP) and =
signalling=20
extensions&nbsp;<BR>&nbsp; (RSVP-TE) required by PCE-based path =
computation=20
techniques. The extensions <BR>&nbsp; will developed in conjunction with =
the=20
working groups in charge of the <BR>&nbsp; specific protocols.<BR>-=20
Specification of requirements and protocol extensions related to=20
the&nbsp;<BR>&nbsp; policy, security and confidentiality aspects of =
PCE-based=20
path computation <BR>&nbsp; techniques involving PCEs of multiple=20
Providers.<BR>- Definition of MIBs, management procedures related to the =

protocol&nbsp;<BR>&nbsp; extensions defined by the WG<BR><BR>In doing =
this work,=20
the WG will closely work with at least the following&nbsp;<BR>other WGs: =
CCAMP,=20
MPLS, ISIS, OSPF, IDR. The WG will also cooperate with&nbsp;<BR>the=20
ITU-T&nbsp;and OIF.<BR><BR>Goals and Milestones<BR><BR>Dates for =
milestones to=20
be decided later.<BR><BR>&nbsp; Post strawman WG goals and=20
charter.<BR><BR>&nbsp; Submit WG document defining the framework and=20
applicability of the&nbsp;<BR>&nbsp; PCE&nbsp;model.<BR><BR>&nbsp; =
Select a=20
single candidate protocol from communication between =
LSRs&nbsp;<BR>&nbsp; and=20
PCEs.<BR><BR>&nbsp; Submit document(s) that define various path =
computation=20
models<BR>&nbsp;<BR>&nbsp; Submit an analysis document examining the=20
requirements for coherent<BR>&nbsp; computation techniques and the =
implication=20
of cooperation between&nbsp;<BR>&nbsp; PCEs.<BR><BR>&nbsp; Submit a =
document=20
defining the protocol for communication between&nbsp;<BR>&nbsp; LSRs=20
and&nbsp;PCEs.<BR><BR>&nbsp; Submit document(s) defining extensions to =
routing=20
and signalling&nbsp;<BR>&nbsp; protocols&nbsp;necessary to support the =
use of a=20
PCE model within MPLS</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;networks.<BR>&nbsp;<BR>&nbsp; Submit=20
a document defining MIB modules for modeling and =
management&nbsp;<BR>&nbsp; of=20
PCE systems.<BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_01D7_01C454B6.A251D6F0--

Delivery-date: Thu, 17 Jun 2004 19:46:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Steve Joiner" <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, "Kimberly Chiu" <[email-masked]>, <[email-masked]>, "Jim Jones" <[email-masked]>, <[email-masked]>
Subject: Response to OIF communication of June 4th
Date: Thu, 17 Jun 2004 20:41:44 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_01B6_01C454AB.803E8BE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

To        OIF, Technical Committee Chair, Steve Joiner, =
[email-masked]
Cc        [email-masked]
            [email-masked]
            A. Zinin, B. Fenner (IETF Routing ADs)
            K. Kompella, A. Farrel (CCAMP WG chairs)
            CCAMP WG

Dear Mr. Joiner,

Thank you for your response of June 4th, it is good to have opened
up some communication channels between the OIF and CCAMP. We will
investigate what is necessary to establish a more formal
relationship between the two bodies.

We are happy to note the importance that you put on the feedback
process from the OIF to the IETF with respect to GMPLS
standardisation, and in view of this we are pleased to inform the
OIF that IETF CCAMP WG has initiated a Design Team on GMPLS ASON
Routing Solutions.  The GMPLS ASON Routing Solutions Design Team's
Charter is as below. Initially the output will be in the form of
IETF drafts. We will send you the output of the DT over the next
months.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

=3D=3D=3D=3D=3D

ASON Routing Solutions Design Team
----------------------------------

Members (alphabetical order):

       Chris Hopps <[email-masked]>
       Lyndon Ong <[email-masked]>
       Dimitri Papadimitriou <[email-masked]>
       Jonathan Sadler <[email-masked]>
       Stephen Shew <[email-masked]>
       Dave Ward <[email-masked]>

Charter:
-------
To evaluate existing IETF routing protocols against the ASON routing
requirements that were documented in
<draft-ietf-ccamp-gmpls-ason-routing-reqts> as a joint effort of the
IETF CCAMP Working Group and ITU-T SG15.

This evaluation is to be produced by a close examination of
applicability scenarios.  The result of the evaluation of these
scenarios is an integral part of the output of this design team.

The design team will then move on to the design of extensions to
the IETF routing protocols as appropriate in close collaboration
with the corresponding Working Groups (such as the OSPF, IS-IS and
IDR working groups).

Consideration should also be given to the exclusion of protocol
elements or procedures that are not appropriate or relevant in
the ASON routing scenarios that the team describes.

Finally, the design team is responsible for drafting liaison
statements from the CCAMP WG to the ITU-T SG15 and OIF regarding
GMPLS ASON routing solutions, as well as for drafting replies to
liaisons received from the ITU-T SG15 and OIF.  Note that no=20
Liaisons drafted by the design team will be sent or replied to
without approval from the CCAMP WG chairs, ADs and rough=20
consensus of the CCAMP WG.

Standard design team disclaimer: this design team has no special
status in the CCAMP WG.  Any documents they produce are subject to
the usual WG procedures.  Individuals are encouraged to interact
with the design team, to offer suggestions, review the output and,
if they feel so inclined, to submit their own drafts.

Milestones (all on the 15th of the month):
----------

Jun '04: send Liaison to ITU-T SG15 and OIF stating creation of DT
         and charter
Jul '04: first draft of "Evaluation of existing IETF routing=20
         protocols against ASON routing requirements including=20
         evaluation scenarios"
Aug '04: first CCAMP WG document of "Evaluation of existing IETF
         routing protocols against ASON routing requirements=20
         including evaluation scenarios"
Aug '04: send Liaison to ITU-T SG15 and OIF soliciting input on=20
         above WG document
Sep '04: first drafts of protocol-specific "Protocol extensions and
         usage procedures for ASON"
Oct '04: first CCAMP WG protocol-specific documents on "Protocol
         extensions and usage procedures for ASON"
Oct '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
         WG documents
Dec '04: CCAMP WG Last Call (including appropriate Routing WG Last=20
         Call)
Jan '05: hand off documents to IESG

Interactions with other WGs:
------------------------------
The design team is expected to interact with other IETF working groups
as appropriate.  Protocol extensions are not to be developed without
full consultation with the "owning" working group.  That is, while the
protocol extensions are developed within CCAMP, they must be presented
to and discussed with the owning working group which must be given the
opportunity to comment and suggest alternate solutions.  This may
include the IS-IS, OSPF and IDR working groups.

Relevant meetings:
------------------
It is suggested that the design team take full advantage of the
following meetings to advance their discussions face-to-face.  The
team may wish to hold "open" meetings on these occasions to solicit
wider input.

60th IETF San Diego, California, August 1st-6th 2004
ITU-T SG15 Inter-regnum meeting on ASON routing, Berlin, Germany,
   November 1st-5th 2004
61st IETF Washington, DC, November 7th-12th 2004

------=_NextPart_000_01B6_01C454AB.803E8BE0
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>To&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OIF,=20
Technical Committee Chair, Steve Joiner, </FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier=20
size=3D2>Cc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
</FONT><A href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A. Zinin, B. =
Fenner (IETF=20
Routing=20
ADs)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; K.=20
Kompella, A. Farrel (CCAMP WG=20
chairs)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
CCAMP WG<BR><BR>Dear Mr. Joiner,<BR><BR>Thank you for your response of =
June 4th,=20
it is good to have opened<BR>up some communication channels between the =
OIF and=20
CCAMP. We will<BR>investigate what is necessary to establish a more=20
formal</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>relationship&nbsp;</FONT><FONT =
face=3DCourier=20
size=3D2>between the two bodies.<BR><BR>We are happy to note the =
importance that=20
you put on the feedback<BR>process from the OIF to the IETF with respect =
to=20
GMPLS<BR>standardisation, and in view of this we are pleased to inform=20
the<BR>OIF that IETF CCAMP WG has initiated a Design Team on GMPLS=20
ASON<BR>Routing Solutions.&nbsp; The GMPLS ASON Routing Solutions Design =

Team's<BR>Charter is as below.&nbsp;Initially the output will be in the =
form=20
of</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>IETF drafts. We will send you the =
output of=20
the&nbsp;DT over the next</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>months.<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Sincerely,<BR>Kireeti Kompella &amp; =
Adrian=20
Farrel, CCAMP WG chairs<BR><BR>=3D=3D=3D=3D=3D<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>ASON Routing Solutions Design=20
Team<BR>----------------------------------<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Members (alphabetical=20
order):<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chris Hopps =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lyndon Ong =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dimitri =
Papadimitriou=20
&lt;</FONT><A href=3D"mailto:[email-masked]"><FONT =
face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =

size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jonathan Sadler=20
&lt;</FONT><A href=3D"mailto:[email-masked]"><FONT =
face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stephen Shew =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dave Ward =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;<BR><BR>Charter:<BR>-------<BR>To evaluate existing IETF =
routing=20
protocols against the ASON routing<BR>requirements that were documented=20
in<BR>&lt;draft-ietf-ccamp-gmpls-ason-routing-reqts&gt; as a joint =
effort of=20
the<BR>IETF CCAMP Working Group and ITU-T SG15.<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This evaluation is to be produced by =
a close=20
examination of<BR>applicability scenarios.&nbsp; The result of the =
evaluation of=20
these<BR>scenarios is an integral part of the output of this design=20
team.<BR><BR>The design team will then move on to the design of =
extensions=20
to<BR>the IETF routing protocols as appropriate in close =
collaboration<BR>with=20
the corresponding Working Groups (such as the OSPF, IS-IS and<BR>IDR =
working=20
groups).<BR><BR>Consideration should also be given to the exclusion of=20
protocol<BR>elements or procedures that are not appropriate or relevant=20
in<BR>the ASON routing scenarios that the team =
describes.<BR><BR>Finally, the=20
design team is responsible for drafting liaison<BR>statements from the =
CCAMP WG=20
to the ITU-T SG15 and OIF regarding<BR>GMPLS ASON routing solutions, as =
well as=20
for drafting replies to<BR>liaisons received from the ITU-T SG15 and =
OIF.&nbsp;=20
Note that no </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Liaisons drafted by the design team =
will be sent=20
or replied to</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>without approval from the CCAMP WG =
chairs, ADs=20
and rough </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>consensus of the CCAMP =
WG.<BR><BR>Standard design=20
team disclaimer: this design team has no special<BR>status in the CCAMP=20
WG.&nbsp; Any documents they produce are subject to<BR>the usual WG=20
procedures.&nbsp; Individuals are encouraged to interact<BR>with the =
design=20
team, to offer suggestions, review the output and,<BR>if they feel so =
inclined,=20
to submit their own drafts.<BR><BR>Milestones (all on the 15th of the=20
month):<BR>----------<BR><BR>Jun '04: send Liaison to ITU-T SG15 and OIF =
stating=20
creation of DT<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and=20
charter<BR>Jul '04: first draft of "Evaluation of existing IETF routing=20
</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
protocols&nbsp;against ASON routing requirements including </FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
evaluation&nbsp;scenarios"<BR>Aug '04: first CCAMP WG document of =
"Evaluation of=20
existing IETF<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
routing=20
protocols against ASON routing requirements </FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
including evaluation scenarios"<BR>Aug '04: send Liaison to ITU-T SG15 =
and OIF=20
soliciting input on </FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
above&nbsp;WG document<BR>Sep '04: first drafts of protocol-specific =
"Protocol=20
extensions and</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;usage procedures for ASON"<BR>Oct '04: first CCAMP WG =
protocol-specific=20
documents on =
"Protocol<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
extensions and usage procedures for ASON"<BR>Oct '04: send Liaison to =
ITU-T SG15=20
and OIF soliciting input on=20
above<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WG =
documents<BR>Dec=20
'04: CCAMP WG Last Call (including appropriate Routing WG Last =
</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Call)<BR>J=
an '05:=20
hand off documents to IESG<BR><BR>Interactions with other=20
WGs:<BR>------------------------------<BR>The design team is expected to =

interact with other IETF working groups<BR>as appropriate.&nbsp; =
Protocol=20
extensions are not to be developed without<BR>full consultation with the =

"owning" working group.&nbsp; That is, while the<BR>protocol extensions =
are=20
developed within CCAMP, they must be presented<BR>to and discussed with =
the=20
owning working group which must be given the<BR>opportunity to comment =
and=20
suggest alternate solutions.&nbsp; This may<BR>include the IS-IS, OSPF =
and IDR=20
working groups.<BR><BR>Relevant meetings:<BR>------------------<BR>It is =

suggested that the design team take full advantage of the<BR>following =
meetings=20
to advance their discussions face-to-face.&nbsp; The<BR>team may wish to =
hold=20
"open" meetings on these occasions to solicit<BR>wider =
input.<BR><BR>60th IETF=20
San Diego, California, August 1st-6th 2004<BR>ITU-T SG15 Inter-regnum =
meeting on=20
ASON routing, Berlin, Germany,<BR>&nbsp;&nbsp; November 1st-5th =
2004<BR>61st=20
IETF Washington, DC, November 7th-12th =
2004<BR><BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_01B6_01C454AB.803E8BE0--

Delivery-date: Thu, 17 Jun 2004 16:06:29 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Scott W Brim" <[email-masked]>, "dimitri papadimitriou" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: RE: Draft of a liaison to ITU-T Study Group 13 about L1VPN
Date: Thu, 17 Jun 2004 09:05:07 -0700

Adrian,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Scott W Brim
> Sent: Wednesday, June 16, 2004 11:31 PM
> To: dimitri papadimitriou
> Cc: Adrian Farrel; [email-masked]; 'Kireeti Kompella';
> [email-masked]; Bill Fenner
> Subject: Re: Draft of a liaison to ITU-T Study Group 13 about L1VPN
> 
> 
> On Thu, Jun 17, 2004 12:50:50AM +0200, dimitri papadimitriou 
> allegedly wrote:
> > hi adrian, what do you mean by "to separate the work from the 
> noise that 
> > happens on the CCAMP mailing list" 
> 
> Right.  Adrian, just delete the first part of that sentence and start
> with "We have started a new mailing list".  
> 
> > and "In keeping with all IETF mailing 
> > lists,.."
> 
> I have no problem with this.
> 
> swb

Ditto.

-Vishal

Delivery-date: Thu, 17 Jun 2004 08:20:40 +0000
Content-class: urn:content-classes:message
Subject: RE : RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Thu, 17 Jun 2004 10:19:35 +0200
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>

Hi Vishal

Sorry for this delayed answer

See some additionnal comments inline

Regards,

JL

>-----Message d'origine-----
>De : [email-masked]=20
>[mailto:[email-masked]] De la part de Vishal Sharma
>Envoy=E9 : vendredi 11 juin 2004 23:35
>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN; TE; CCAMP
>Objet : RE: RE : Last call comments:=20
>draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
>Hi JL,
>
>Thanks for the clarifications. A few follow-up thoughts in-line.
>
>Regards,
>-Vishal
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On
>> Behalf Of LE ROUX Jean-Louis FTRD/DAC/LAN
>> Sent: Friday, June 11, 2004 9:30 AM
>> To: [email-masked]; TE; CCAMP
>> Subject: RE : Last call comments:=20
>> draft-ietf-tewg-interarea-mpls-te-req-01.txt
>>
>>
>> Hi Vishal,
>>
>> Thanks a lot for these highly useful comments.
>>
>> Please see inline for some answers.
>>
>> Regards,
>>
>> JL
>>
>
><snip>
>
>> >7. Sec. 7.2, I tend to agree with Adrian that (ideally) it=20
>would seem=20
>> >it should be enough for the head-end to signal the function/service=20
>> >it wants and not the underlying method used by nodes=20
>further in path=20
>> >to provide that service. If, as you mention, this is a requirement=20
>> >expressed by many SPs, it would be good to understand why it is so,=20
>> >and for the document to explain a bit about it.
>>
>> Actually I don't really understand the objection on that point. The=20
>> requirement seems clear for me. If there are several methods=20
>supported=20
>> in my network, I want to select the method on a per LSP=20
>basis in order=20
>> to have entire control on how the LSP is signaled. This will=20
>ease LSP=20
>> management. Basically there won't be hundreds of methods but=20
>just two=20
>> or three (contiguous, stiching, nesting..)
>> So it seems quite relevant to have the ability to signal the
>> desired method.
>
>As I explained in my email to JP, it is still somewhat unclear=20
>as to what the ability to signal the desired method buys the=20
>provider, and exactly why or how that simplifies LSP management.

Basically, as mentionned by JP, the signaling method used will have a =
non negligeable impact
on important features (Reoptimization, FRR, rerouting). For instance, if =
you use sitching or nesting, you will face FRR issues as regards ABR =
protection.

I agree that we could just signal the function/service
 "FRR protection of ABRs", "Head-end Control of reoptimization"...
This would clearly require the "contiguous" signaling mode

IMHO, this is simpler to directly signal the signaling mode.
I don't really see any interop issue here. Basically if an ABR does not =
support the signaling mode, it simply rejects the LSP setup.

>
>
>> Let's have a look at the FRR draft: There are two modes defined, and=20
>> the desired mode (one-to-one or bypass) is signaled on a=20
>per-LSP basis=20
>> (within the FRR object). I did not see any objection on that.
>
>I think the FRR draft is really a solutions draft, and it=20
>presents two solutions which offer somewhat different=20
>services, in my view. The detour provides the ability to=20
>protect segments of a _given_ LSP, while the bypass tunnel=20
>provides the ability to simultaneously protect _multiple_ LSPs=20
>sharing a given resource (node(s) or link).
>
>Also, as Adrian mentioned, it has lead to interop issues.

FRR interop issues was IMHO not related to this flag in the FRR object.=20

>
>> >
>> >8. Sec. 7.3 on path optimality talks only of the optimality of a=20
>> >single path computed in isolation. What is the definition of=20
>> >optimality to be applied for computing diverse paths? (Sec.=20
>7.7 later=20
>> >does not specifically discuss this aspect either.) If one used CSPF=20
>> >in sequence to compute two diverse paths (as this section would=20
>> >imply) then the computation may fail, even though a set of optimal=20
>> >diverse paths exists (as acknowledged in Sec. 7.7 ahead).
>>
>> Agree, we should add a definition of optimality to be applied when=20
>> computing diverse path This maybe: A placement of two=20
>diverse paths is=20
>> optimal if their cumulative cost is minimal.
>
>Yes, this is one definition. I think in  some previous email=20
>exchanges, Fabio had provided a good definition of optimality=20
>for diverse path routing. (I'll try to dig it up in the=20
>archives, and post a note separately on it.)

Thanks=20

>
>
>> >9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to underscore=20
>> >Adrian's point on specifying the scaling requirements themselves=20
>> >(with respect to areas, amount of flooded info. etc.)=20
>rather than the=20
>> >realization of those requirements (by not adding any info. to the=20
>> >LSAs, for example).
>>
>>
>> It seems that you are OK with 5.3 (no comments)
>> "Containment of routing information MUST not be compromised to allow=20
>> inter-area traffic
>>    engineering. Information propagation for path-selection=20
>MUST continue
>>    to be localized.".
>> Thus you should also be OK with 7.4
>
>Actually, 5.3 imposes a requirement to preserve IGP hierarchy=20
>and scalability, but at least leaves open the possibility for=20
>the IGP to carry extra information as long as it is not an=20
>"unreasonable amount of extra information" that does not=20
>"unreasonably increase IGP flooding frequency".

Basically 5.3 points out that information propagation for PATH-SELECTION =

MUST continue to be localized.=20
It also means that we allow for the IGP to carry extra information =
provided that it is NOT topology related...

>
>I thought 7.4 should probably provide some specifics on what=20
>unreasonable is, and leave it to the protocol designers to=20
>devise protocols that keep within those limits. Instead it=20
>seems to prescribe a realization -- one where no topology=20
>related info. of any sort should be added to the IGP LSAs.
>
>> Basically we want to preserve IGP hierachy concept, are there=20
>> objections to that point ?
>
>Depends on whether you want to preserve it in spirit or to the=20
>letter :-). I think it may be useful to give protocol=20
>designers some wiggle room.

IMHO it is also useful to tell protocol designers what we don't want in =
our networks...

>
>> This means, for ISPs contributing to this draft, "no leaking of any=20
>> topology related info accross areas". Of course, this does not=20
>> preclude the addition of info to the LSA, provided that it is not=20
>> topology related.
>>
>> >
>> >If solutions can meet the scaling requirements by adding a bit of=20
>> >info. to the IGP, I think this should be allowed, otherwise=20
>there is=20
>> >really not much that could be achieved using current mechanisms=20
>> >(since no modifications to them seem permissible, and we already=20
>> >established that these, as they exist, do not provide for adequate=20
>> >inter-area MPLS TE).
>> >
>> >BTW, one of the points made in this regard in these
>> >email thread was about the use of path computation servers,=20
>which can=20
>> >supposedly compute optimal paths without any impact on the IGP.
>> >
>> >I think this argument isn't quite complete, since it hides the=20
>> >signaling extensions required for these as well as the scalability=20
>> >impact of recursive PCE-type schemes (btw, this was a question that=20
>> >came up in independent discussions with JP in the context=20
>of the ARO=20
>> >and PCE schemes, and is still under discussion).
>>
>> Let's continue this discussion in another thread addressing solutions
>
>Ok, sure.
>
>
>> >10. Sec. 7.6, the figure O(N^2) makes the assumption that=20
>each of the=20
>> >N ARBs at the border of the neighboring areas is connected to each=20
>> >other ABR. No? In reality, the number of crankback's may be=20
>> >significantly less therefore.
>>
>> No, basically if you have X1 ABRs in head-end area and X2 ABRs in=20
>> tail-end area you may have up to X1*X2 crankbacks, provided=20
>that there=20
>> is a path between all ABRs. This does not assume direct connectivity=20
>> between ABRs.
>
>
>Ok, thanks. I see now what you are saying.
>
>> >11. Sec. 7.7, I guess it would be useful to qualify what is=20
>> >considered "extra-load" in signaling and routing here. Is=20
>that to be=20
>> >interpreted as _absolutely no change_ to current signaling and=20
>> >routing protocol objects?
>>
>> No, this should not be interpreted as "absolutely no change".=20
>> Basically the solution must respect scalability requirements=20
>spelt out=20
>> in 5.2 Will clarify in next revision.
>>
>>
>> >seem feasible, if inter-area routing/TE is to be achieved, so=20
>> >something more specific is implied, which would be good to=20
>spell out.
>> >
>> >BTW, also tend to agree with Adrian's point that this section seems=20
>> >to be describing the computation of diverse paths rather than the=20
>> >establishment of diverse paths, which would seem to be the=20
>> >requirement.
>>
>> Yes this is basically a requirement on computation, but in this=20
>> inter-domain context Path computation and Path establishment are no=20
>> longer necessarily independant (see your ARO proposal)
>>
>>
>> >
>> >12. Sec. 7.9, what is meant by "inter-area head end LSR"?
>> >An LSR that is the head-end of an inter-area LSP (that is, an LSP=20
>> >traversing multiple areas)?
>>
>> Yes, will reword
>>
>> >
>> >13. Sec. 8.2, not sure that is providing a real measurable=20
>evaluation=20
>> >criterion. If it is to be kept, some specifics should probably be=20
>> >given.
>
>JL, sure. The perf. requirements are given in Sec. 8.1, but I=20
>was looking at Sec. 8.2.

OK, in 8.2 the criteria is more qualitative than quantitative

>
>Also, even for 8.1, it may be good to add the =3D to explanation=20
>for (1) and (2) that you've given below.

OK=20

>
>> IMHO what we list is clearly measurable
>>    (1) Optimality of the computed inter-area TE LSP path.
>> =3D Computed cost - Shortest cost
>>    (2) Optimality of the computed backup tunnel path=20
>protecting against
>>        the failure of an ABR, capability to share bandwidth=20
>among backup
>>        tunnels protecting independent facilities
>> =3D Total backup bandwidth consumption
>>    (3) Inter-area TE LSP set up time.
>>  =3D clearly measurable
>>    (4) RSVP-TE and IGP scalability (state impact, number of messages,
>>        message size)
>>  =3D Memory footprint increase, CPU load increase, Message size=20
>> Increase...This is also definitely measurable.
>>

Thanks again for these comments. We will post, on Monday, a new revision =
incorporating received comments.

Regards,

JL

Delivery-date: Thu, 17 Jun 2004 06:46:48 +0000
Date: Thu, 17 Jun 2004 08:31:06 +0200
From: Scott W Brim <[email-masked]>
To: dimitri papadimitriou <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>, [email-masked], Bill Fenner <[email-masked]>
Subject: Re: Draft of a liaison to ITU-T Study Group 13 about L1VPN
Mail-Followup-To: Scott W Brim <[email-masked]>, dimitri papadimitriou <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], 'Kireeti Kompella' <[email-masked]>, [email-masked], Bill Fenner <[email-masked]>

On Thu, Jun 17, 2004 12:50:50AM +0200, dimitri papadimitriou allegedly wrote:
> hi adrian, what do you mean by "to separate the work from the noise that 
> happens on the CCAMP mailing list" 

Right.  Adrian, just delete the first part of that sentence and start
with "We have started a new mailing list".  

> and "In keeping with all IETF mailing 
> lists,.."

I have no problem with this.

swb

Delivery-date: Wed, 16 Jun 2004 22:53:27 +0000
Date: Thu, 17 Jun 2004 00:50:50 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC: [email-masked], 'Kireeti Kompella' <[email-masked]>,  [email-masked], Bill Fenner <[email-masked]>
Subject: Re: Draft of a liaison to ITU-T Study Group 13 about L1VPN

hi adrian, what do you mean by "to separate the work from the noise that happens 
on the CCAMP mailing list" and "In keeping with all IETF mailing lists,.."

except from these expected clarifications, the proposal looks fine to me

thanks,
- dimitri.

Adrian Farrel wrote:

> Comments on this proposed liaison to ITU-T SG13 would be very welcome.
> Thanks,
> Adrian
> 
> ====
> 
> To:          Mr. Marco Carugi, Rapporteur for Question 11 of ITU-T Study Group 13.
> From:      Adrian Farrel and Kireeti Kompella, Co-chairs of the CCAMP Working Group of the
> IETF
> Cc:          Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
> For:         Information
> Deadline: None
> Subject:   Reply to Liaison Statement on L1VPNs
> 
> Dear Mr. Carugi,
> 
> Thank you for your liaison statement COM13-LS23 dated 3-12 February 2004 on the subject of
> Layer One VPNs and related work within Study Group 13.
> 
> Thanks also to the members of Study Group 13 Question 11 for their work on
> draft-takeda-l1vpn-framework-00.txt which represents so clearly the motivations for
> L1VPNs, the  high level (service level) requirements, and the architectural models
> that might be used to build L1VPNs.
> 
> Members of the CCAMP working group have expressed a considerable interest in this work and
> we are keen to pursue a working relationship with SG13 to advance the description of the
> functional requirements, assess current protocols for suitability, and develop any
> protocol extensions that may be necessary.
> 
> Some feedback on draft-takeda-l1vpn-framework-00.txt has already been made on the CCAMP
> mailing list and we know that the authors of the draft are aware of the comments.
> Hopefully this is valuable input and will be taken back for discussion in Q.11 where
> appropriate.
> 
> In order to further facilitate the discussion of L1VPN within the IETF and to separate the
> work from the noise that happens on the CCAMP mailing list, we have started a new mailing
> list designated for L1VPN emails only. In keeping with all IETF mailing lists, this list
> is open to all and we would welcome active participation from SG13 delegates and
> attendees, and from anyone else who can contribute in this area.
> 
> We anticipate that initial discussions will focus on draft-takeda-l1vpn-framework-00.txt,
> but that we will move on to an analysis of the short-comings of existing IETF protocols in
> the delivery of L1VPNs.
> 
> To join the mailing list please visit https://www1.ietf.org/mailman/listinfo/l1vpn.
> The mailing list will also be archived and can be read on the Web at
> ftp://ftp.ietf.org/ietf-mail-archive/l1vpn/
> 
> Sincerely,
> Kireeti Kompella & Adrian Farrel, CCAMP WG chairs
> 
> 
> 
> .
> 

Delivery-date: Wed, 16 Jun 2004 16:34:42 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Draft of a liaison to ITU-T Study Group 13 about L1VPN
Date: Wed, 16 Jun 2004 17:21:49 +0100

Comments on this proposed liaison to ITU-T SG13 would be very welcome.
Thanks,
Adrian

====

To:          Mr. Marco Carugi, Rapporteur for Question 11 of ITU-T Study Group 13.
From:      Adrian Farrel and Kireeti Kompella, Co-chairs of the CCAMP Working Group of the
IETF
Cc:          Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
For:         Information
Deadline: None
Subject:   Reply to Liaison Statement on L1VPNs

Dear Mr. Carugi,

Thank you for your liaison statement COM13-LS23 dated 3-12 February 2004 on the subject of
Layer One VPNs and related work within Study Group 13.

Thanks also to the members of Study Group 13 Question 11 for their work on
draft-takeda-l1vpn-framework-00.txt which represents so clearly the motivations for
L1VPNs, the  high level (service level) requirements, and the architectural models
that might be used to build L1VPNs.

Members of the CCAMP working group have expressed a considerable interest in this work and
we are keen to pursue a working relationship with SG13 to advance the description of the
functional requirements, assess current protocols for suitability, and develop any
protocol extensions that may be necessary.

Some feedback on draft-takeda-l1vpn-framework-00.txt has already been made on the CCAMP
mailing list and we know that the authors of the draft are aware of the comments.
Hopefully this is valuable input and will be taken back for discussion in Q.11 where
appropriate.

In order to further facilitate the discussion of L1VPN within the IETF and to separate the
work from the noise that happens on the CCAMP mailing list, we have started a new mailing
list designated for L1VPN emails only. In keeping with all IETF mailing lists, this list
is open to all and we would welcome active participation from SG13 delegates and
attendees, and from anyone else who can contribute in this area.

We anticipate that initial discussions will focus on draft-takeda-l1vpn-framework-00.txt,
but that we will move on to an analysis of the short-comings of existing IETF protocols in
the delivery of L1VPNs.

To join the mailing list please visit https://www1.ietf.org/mailman/listinfo/l1vpn.
The mailing list will also be archived and can be read on the Web at
ftp://ftp.ietf.org/ietf-mail-archive/l1vpn/

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Delivery-date: Wed, 16 Jun 2004 16:22:36 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "L1VPN List" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Layer One VPNs
Date: Wed, 16 Jun 2004 17:21:21 +0100

Hi,

This is just to let you know that a new mail list has been set up for the discussion of
Layer One VPNs. Subscription can be managed through
https://www1.ietf.org/mailman/listinfo/l1vpn. You are all very welcome to join.

This list is currently "under the care" of the CCAMP co-chairs while we evaluate the
interest and relevance to the IETF.

Much of the initial work for developing service level requirements and an architecture has
come from the ITU-T SG13 and we will advance the discussions in a cooperative
relationship.

At the moment there are three drafts that are of particular interest.

http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt
This provides a good background to what L1VPNs are trying to achieve and summarizes the
architectures that may be used.

http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt
Describes a BGP-based solution to "Generalized VPNs". This fits into one of the
architectural models for L1VPNs.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt
Satisfies another of the L1VPN architectural models.

We hope that the next work will be:
- review and refinement of the framework draft
- tightening and further detail for functional requirements
- applicability of the existing GMPLS protocols to the architectures in the
   framework
- identification of any protocol extensions that may be needed.

All of this is done under the following provisos:
- there continues to be interest within the IETF
- it continues to be judged appropriate for the IETF
- no better place for the discussions is identified.

Comments on these points as well as the drafts and the work itself are welcomed on the
list.

Please note that at the moment the automatic archiving of the list is broken, but that
this will be fixed very soon.

Thanks,
Adrian

Delivery-date: Wed, 16 Jun 2004 10:47:46 +0000
Date: Wed, 16 Jun 2004 11:51:08 +0000
To: "Ccamp" <[email-masked]>
From: "Adrian" <[email-masked]>
Subject: RE: Message Notify

----------fotdgildgkivtidrcwev
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<img src="cid:nopujwwhfs.bmp"><br>
</body></html>

----------fotdgildgkivtidrcwev
Content-Type: image/bmp; name="nopujwwhfs.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="nopujwwhfs.bmp"
Content-ID: 

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

----------fotdgildgkivtidrcwev--

Delivery-date: Tue, 15 Jun 2004 23:06:40 +0000
Date: Tue, 15 Jun 2004 15:58:01 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: CCAMP WG Liaison: Creation of a new Design Team for ASON Routing (fwd)

FYI

---------- Forwarded message ----------
Date: Tue, 15 Jun 2004 15:56:16 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Malcolm Betts <[email-masked]>, Hing-Kam Lam <[email-masked]>
Cc: Scott Bradner <[email-masked]>, Alex Zinin <[email-masked]>,
     Bill Fenner <[email-masked]>, Adrian Farrel <[email-masked]>,
     Kireeti Kompella <[email-masked]>,
     IESG Secretary <[email-masked]>
Subject: CCAMP WG Liaison: Creation of a new Design Team for ASON Routing

To        Q12/15 Rapporteur, Malcolm Betts, [email-masked]
          Q14/15 Rapporteur, Hing Kam Lam, [email-masked]
Cc        S. Bradner (IETF-ITU Liaison Coordinator)
          A. Zinin, B. Fenner (IETF Routing ADs)
          K. Kompella, A. Farrel (CCAMP WG chairs)
          CCAMP WG
For       Information
Deadline: None

--------

We would like to inform ITU-T Q12/15 and Q14/15 that IETF CCAMP WG
has initiated a Design Team on GMPLS ASON Routing Solutions.  The
GMPLS ASON Routing Solutions Design Team's Charter is as below.

We expect to liaise with you on the output of the DT over the next
months.  Initially the output will be in the form of IETF drafts.
We wish to work with you cooperatively on these documents and we
would appreciate your assistance in reviewing them.

=====

ASON Routing Solutions Design Team
----------------------------------

Members (alphabetical order):

      Chris Hopps <[email-masked]>
      Lyndon Ong <[email-masked]>
      Dimitri Papadimitriou <[email-masked]>
      Jonathan Sadler <[email-masked]>
      Stephen Shew <[email-masked]>
      Dave Ward <[email-masked]>

Charter:
-------

To evaluate existing IETF routing protocols against the ASON routing
requirements that were documented in
<draft-ietf-ccamp-gmpls-ason-routing-reqts> as a joint effort of the
IETF CCAMP Working Group and ITU-T SG15.

This evaluation is to be produced by a close examination of
applicability scenarios.  The result of the evaluation of these
scenarios is an integral part of the output of this design team.

The design team will then move on to the design of extensions to
the IETF routing protocols as appropriate in close collaboration
with the corresponding Working Groups (such as the OSPF, IS-IS and
IDR working groups).

Consideration should also be given to the exclusion of protocol
elements or procedures that are not appropriate or relevant in
the ASON routing scenarios that the team describes.

Finally, the design team is responsible for drafting liaison
statements from the CCAMP WG to the ITU-T SG15 and OIF regarding
GMPLS ASON routing solutions, as well as for drafting replies to
liaisons received from the ITU-T SG15 and OIF.  Note that no Liaisons
drafted by the design team will be sent or replied to without
approval from the CCAMP WG chairs, ADs and rough consensus of the
CCAMP WG.

Standard design team disclaimer: this design team has no special
status in the CCAMP WG.  Any documents they produce are subject to
the usual WG procedures.  Individuals are encouraged to interact
with the design team, to offer suggestions, review the output and,
if they feel so inclined, to submit their own drafts.

Milestones (all on the 15th of the month):
----------

Jun '04: send Liaison to ITU-T SG15 and OIF stating creation of DT
           and charter
Jul '04: first draft of "Evaluation of existing IETF routing protocols
           against ASON routing requirements including evaluation
           scenarios"
Aug '04: first CCAMP WG document of "Evaluation of existing IETF
           routing protocols against ASON routing requirements including
           evaluation scenarios"
Aug '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
           WG document
Sep '04: first drafts of protocol-specific "Protocol extensions and usage
           procedures for ASON"
Oct '04: first CCAMP WG protocol-specific documents on "Protocol
           extensions and usage procedures for ASON"
Oct '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
           WG documents
Dec '04: CCAMP WG Last Call (including appropriate Routing WG Last Call)
Jan '05: hand off documents to IESG

Interactions with other WGs:
------------------------------
The design team is expected to interact with other IETF working groups
as appropriate.  Protocol extensions are not to be developed without
full consultation with the "owning" working group.  That is, while the
protocol extensions are developed within CCAMP, they must be presented
to and discussed with the owning working group which must be given the
opportunity to comment and suggest alternate solutions.  This may
include the IS-IS, OSPF and IDR working groups.

Relevant meetings:
------------------
It is suggested that the design team take full advantage of the
following meetings to advance their discussions face-to-face.  The
team may wish to hold "open" meetings on these occasions to solicit
wider input.

60th IETF San Diego, California, August 1st-6th 2004
ITU-T SG15 Inter-regnum meeting on ASON routing, Berlin, Germany,
	November 1st-5th 2004
61st IETF Washington, DC, November 7th-12th 2004

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Delivery-date: Mon, 14 Jun 2004 16:58:29 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Jean Philippe Vasseur" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>, <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>
Subject: Re: Last call comments:   draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Mon, 14 Jun 2004 17:53:59 +0100

Hi again,
At the risk of flogging this one further than is reasonable...

> >3. Is there a reason to require contiguous signaling rather than some
> >other form?
> >
> >I still don't see one.
>
> Well, you may not want a downstream SP to use stitching and potentially
> "hide" what happens downstream in term of reroute, failure, reoptimization,

Of the things you list, only reoptimization is specially hidden by stitching.

Repair/recovery mechanisms are already "hidden", or can be.

Perhaps something that you want here is some statement on inherritance rules. That is, the
relationship between the parameters of the end-to-end LSP and the stitched or tunnel LSP
that supports it.

That would be reasonable to define (see the inter-domain framework draft that tries to
point this out).

But so far you are repeatedly saying that there are functions that the ingress has a right
to control (which is fine) and that the way it should do this is by limiting how the
network provides signaling (which is not fine). Why is it not acceptable to you to specify
the functions that the LSP must support?

> ...
>
> >Please understand that I am *NOT* saying that SPs have a perfect right to
> >control what signaling is used within their network. This is usually achieved
> >through the joint measures of procurement and configuration. An SP would
> >be justifiably vexed to discover that a cluster of LSRs within their network
> >had autonomously switched LSP setup requests to operate in CR-LDP.
> >However, it is not true to say that when an ingress LSR sends an RSVP-TE
> >Path message it is requiring that that signaling technique be used all the way
> >to the egress.
> >
> >The issue clearly gets fuzzy when the LSP traverses part of the network
> >that is out of the originating SP's direct control (i.e. another AS). But here
> >we are talking only about areas.
>
> But as you know the solutions will apply to both inter-area and inter-AS.

Well, I venture to suggest that areas all belong to the same administrative domain and so
are under the administrative control of the initiating SP.

Adrian

Delivery-date: Mon, 14 Jun 2004 15:56:21 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Jean Philippe Vasseur" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>
Subject: RE: Last call comments:   draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Mon, 14 Jun 2004 08:55:37 -0700

Folks,

Please ignore my previous question. I had read JP and Raymond's draft
a while ago, but completely forgot that it is the WG document addressing
inter-AS requirements!

-Vishal

> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Monday, June 14, 2004 8:48 AM
> To: Jean Philippe Vasseur; Adrian Farrel
> Cc: [email-masked]; [email-masked]; Arthi
> Ayyangar; LE ROUX Jean-Louis FTRD/DAC/LAN; TE; CCAMP
> Subject: RE: Last call comments:
> draft-ietf-tewg-interarea-mpls-te-req-01.txt
> 
> 
> JP, Adrian, et al,
> 
> Quick question in-line.
> 
> -Vishal
> 
> > -----Original Message-----
> > From: Jean Philippe Vasseur [mailto:[email-masked]]
> > Sent: Monday, June 14, 2004 8:41 AM
> > To: Adrian Farrel
> > Cc: [email-masked]; [email-masked]; Arthi
> > Ayyangar; LE ROUX Jean-Louis FTRD/DAC/LAN; [email-masked]; TE; CCAMP
> > Subject: Re: Last call comments:
> > draft-ietf-tewg-interarea-mpls-te-req-01.txt
> > 
> > 
> <<snip>>
> 
> > >The issue clearly gets fuzzy when the LSP traverses part of 
> the network 
> > >that is out of the
> > >originating SP's direct control (i.e. another AS). But here we 
> > are talking 
> > >only about
> > >areas.
> > 
> > But as you know the solutions will apply to both inter-area and 
> inter-AS.
> > 
> 
> Actually, this is something that I've been wondering about as the
> discussion on inter-area has progressed. Is there expected to be a 
> separate document detailing inter-AS requirements?
> 
> Given that the framework and other related drafts are jointly addressing
> inter-area and inter-AS issues, how come the requirements document(s) is
> not? 
> 
> Perhaps I missed some of this evolution, but if someone could shed some 
> light on this, that would be appreciated.
> 

Delivery-date: Mon, 14 Jun 2004 15:54:43 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Jean Philippe Vasseur" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>
Subject: RE: Last call comments:   draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Mon, 14 Jun 2004 08:47:35 -0700

JP, Adrian, et al,

Quick question in-line.

-Vishal

> -----Original Message-----
> From: Jean Philippe Vasseur [mailto:[email-masked]]
> Sent: Monday, June 14, 2004 8:41 AM
> To: Adrian Farrel
> Cc: [email-masked]; [email-masked]; Arthi
> Ayyangar; LE ROUX Jean-Louis FTRD/DAC/LAN; [email-masked]; TE; CCAMP
> Subject: Re: Last call comments:
> draft-ietf-tewg-interarea-mpls-te-req-01.txt
> 
> 
<<snip>>

> >The issue clearly gets fuzzy when the LSP traverses part of the network 
> >that is out of the
> >originating SP's direct control (i.e. another AS). But here we 
> are talking 
> >only about
> >areas.
> 
> But as you know the solutions will apply to both inter-area and inter-AS.
> 

Actually, this is something that I've been wondering about as the
discussion on inter-area has progressed. Is there expected to be a 
separate document detailing inter-AS requirements?

Given that the framework and other related drafts are jointly addressing
inter-area and inter-AS issues, how come the requirements document(s) is
not? 

Perhaps I missed some of this evolution, but if someone could shed some 
light on this, that would be appreciated.

Delivery-date: Mon, 14 Jun 2004 15:42:22 +0000
Date: Mon, 14 Jun 2004 11:41:24 -0400
To: "Adrian Farrel" <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Last call comments:  draft-ietf-tewg-interarea-mpls-te-req-01.txt
Cc: <[email-masked]>, <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>, <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>

Hi,

At 09:21 PM 6/13/2004 +0100, Adrian Farrel wrote:
>Hi,
>
>Contrary to appearances, this discussion may be making progress.
>
>JP said,
>
> > > And I do not see why specifying the signalling method would be a problem
> > > at all. If a SP requires a contiguous LSP to avoid its LSP to be
> > > stitched along its path and potentially reoptimized without any HE
> > > control, specifying that the LSP must be contiguous (or not) is indeed
> > > the right method.
>
>There are three issues there.
>
>1. Is it a problem to specify the desired/required signaling method?
>
>There are two answers.
>a. There is no technical problem with providing this function.
>b. There are plenty of fears about the consequences of providing
>     this function. Dimitri and Vishal have listed some.
>
>2. Can a HE reasonably require control of functions such as
>     re-optimization?
>
>The answer to this would appear to be "yes". But note that this 
>requirement surely applies
>to all signaling methods. It happens to be the case that the option is 
>meaningless in
>contiguous signaling because the LSP cannot be optimized downstream of the 
>HE (using
>existing make-before-break techniques - but who knows what the future holds?).
>
>So here is a good example of a functional requirement ("re-optimization 
>only under
>head-end control") that the head-end should be able to signal. You should 
>make sure this
>is clear in section 7.9.
>
>3. Is there a reason to require contiguous signaling rather than some 
>other form?
>
>I still don't see one.

Well, you may not want a downstream SP to use stitching and potentially 
"hide" what happens downstream in term of reroute, failure, reoptimization, 
...

>Please understand that I am *NOT* saying that SPs have a perfect right to 
>control what
>signaling is used within their network. This is usually achieved through 
>the joint
>measures of procurement and configuration. An SP would be justifiably 
>vexed to discover
>that a cluster of LSRs within their network had autonomously switched LSP 
>setup requests
>to operate in CR-LDP.
>However, it is not true to say that when an ingress LSR sends an RSVP-TE 
>Path message it
>is requiring that that signaling technique be used all the way to the egress.
>
>The issue clearly gets fuzzy when the LSP traverses part of the network 
>that is out of the
>originating SP's direct control (i.e. another AS). But here we are talking 
>only about
>areas.

But as you know the solutions will apply to both inter-area and inter-AS.

Cheers

JP.

>Cheers,
>Adrian

Delivery-date: Mon, 14 Jun 2004 13:47:58 +0000
Date: Mon, 14 Jun 2004 14:52:23 +0000
To: "Ccamp" <[email-masked]>
From: "Adrian" <[email-masked]>
Subject: Forum notify

----------jppeaascbbomqoewvobl
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>Password - <img src="cid:ldbdhrmpoz.bmp"><br>
<br>
</body></html>

----------jppeaascbbomqoewvobl
Content-Type: image/bmp; name="ldbdhrmpoz.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ldbdhrmpoz.bmp"
Content-ID: 

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

----------jppeaascbbomqoewvobl--

Delivery-date: Sun, 13 Jun 2004 20:57:47 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Jean Philippe Vasseur" <[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>, "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>, <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>
Subject: Re: Last call comments:  draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Sun, 13 Jun 2004 21:21:25 +0100

Hi,

Contrary to appearances, this discussion may be making progress.

JP said,

> > And I do not see why specifying the signalling method would be a problem
> > at all. If a SP requires a contiguous LSP to avoid its LSP to be
> > stitched along its path and potentially reoptimized without any HE
> > control, specifying that the LSP must be contiguous (or not) is indeed
> > the right method.

There are three issues there.

1. Is it a problem to specify the desired/required signaling method?

There are two answers.
a. There is no technical problem with providing this function.
b. There are plenty of fears about the consequences of providing
    this function. Dimitri and Vishal have listed some.

2. Can a HE reasonably require control of functions such as
    re-optimization?

The answer to this would appear to be "yes". But note that this requirement surely applies
to all signaling methods. It happens to be the case that the option is meaningless in
contiguous signaling because the LSP cannot be optimized downstream of the HE (using
existing make-before-break techniques - but who knows what the future holds?).

So here is a good example of a functional requirement ("re-optimization only under
head-end control") that the head-end should be able to signal. You should make sure this
is clear in section 7.9.

3. Is there a reason to require contiguous signaling rather than some other form?

I still don't see one.

Please understand that I am *NOT* saying that SPs have a perfect right to control what
signaling is used within their network. This is usually achieved through the joint
measures of procurement and configuration. An SP would be justifiably vexed to discover
that a cluster of LSRs within their network had autonomously switched LSP setup requests
to operate in CR-LDP.
However, it is not true to say that when an ingress LSR sends an RSVP-TE Path message it
is requiring that that signaling technique be used all the way to the egress.

The issue clearly gets fuzzy when the LSP traverses part of the network that is out of the
originating SP's direct control (i.e. another AS). But here we are talking only about
areas.

Cheers,
Adrian

Delivery-date: Sun, 13 Jun 2004 17:28:39 +0000
Date: Sun, 13 Jun 2004 19:26:22 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked]
Subject: MPLS2004 Conference Call for Presentations

The MPLS2004 Conference will be held in Washington DC, from October 17
to October 19, 2004. This year's conference will include, but will not
be limited, to the following topics:

- Network Consolidation and Service Convergence
- Traffic engineering and QoS
- MPLS network operation, administration, and maintenance
- OSS Systems for MPLS-based networks
- MPLS Multicast
- Service Provisioning
- MPLS in multi-AS networks
- L2VPNs (pseudo-wire emulation, VPWS, VPLS, and others)
- L3VPNs (BGP/MPLS, IPSec interworking, virtual routers, and others)
- Voice, video, and real-time services over MPLS networks
- Scalability and performance of MPLS protocols and networks
- Network processor architectures for next generation MPLS networks
- MPLS certification, verification, and conformance testing
- MPLS network security
- MPLS reliability and survivability (fast reroute, graceful restart,
   and restoration techniques)
- IP Optical Integration
- Multilayer control, management, and optimization
- MPLS deployment case studies: Service Provider operational experience

The Program Committee for MPLS2004 is soliciting presentation proposals
for this conference. If you wish to propose a particular topic for
consideration, please send a one page summary, including speaker's name,
affiliation, and contact information to the Technical Program
Committee at: [email-masked]

All proposals must be received by June 18, 2004. See
http://www.mpls2004.com for more details.

The program committee is looking for original and unpublished work to
continue the tradition of addressing cutting-edge topics that was
initiated by this conference in 1998. Presentations from the vendor,
service provider, research, and user communities covering technology
evolution and operational experience are solicited.
-- 

Loa Andersson

mobile +46 739 81 21 64

Delivery-date: Sun, 13 Jun 2004 08:11:27 +0000
From: [email-masked]
Date: Sun, 13 Jun 2004 07:47:51 GMT
Subject: EU Beitritt der Tuerkei ? [1477]

Aufnahme der Beitrittsverhandlungen mit der Tuerkei oder nicht - eine Entscheidung, die 'das Ende Europas' bedeuten koennte. Dieses Wort stammt vom frueheren franzoesischen Praesidenten Giscard d'Estaing.
Schon 2002 hatte er davor gewarnt, dass ein Beitritt der Tuerkei zur EU dem 'Ende Europas' gleichkaeme. Die bundesdeutschen Beitrittsbefuerworter verdraengen und verschweigen die unabsehbaren Folgen dieser Entscheidung:

(1) Die Tuerkei hat schon jetzt 70 Millionen Einwohner. Sie wird bis zu ihrem EU-Beitritt die BRD in der Bevoelkerungszahl ueberholt haben und in den EU-Institutionen das entsprechende Stimmengewicht erhalten.
(2) Die Tuerkei passt wirtschaftlich nicht in die EU. Das Land ist hoffnungslos ueberschuldet und waere ohne staendige internationalen Kredite laengst bankrott. Das Pro-Kopf-Einkommen betraegt nur 23% des EU-Durchschnitts. Die EU-Subventionen, auf die die Tuerkei Anspruch haette, wuerden nicht nur den Bruesseler Haushalt sprengen, sondern auch die heute schon ueberschuldeten 'Geberlaender' wie die BRD gaenzlich ruinieren.
(3) Mit der Aufnahme eines asiatischen Landes und dem Verzicht auf vernuenftige Aussengrenzen verliert die EU ihre Identitaet.

Trotz dieser unbestreitbaren Sprengsaetze rollt die Kampagne fuer den tuerkischen Beitritt immer schneller und unaufhaltsamer voran: Der tuerkische Regierungschef Erdogan nimmt bereits an den Konferenzen der EU-Regierungschefs teil, freilich noch ohne Stimmrecht und die Tuerkei erhaelt jetzt schon EU-Gelder zur 'Beitrittsvorbereitung'.
Es ist alles wie bei der Euro-Einfuehrung: Erst erscheint der ganze Plan unrealistisch und wird von vielen fuer undurchfuehrbar gehalten; dann wird eine offene Diskussion ueber Pro und Contra als 'europa- oder fremdenfeindlich' kriminalisiert, und schliesslich wird die Entscheidung hinter verschlossenen Tueren, ohne Beteiligung des demokratischen Souveraens und ohne Volksabstimmung gefaellt und fuer unumkehrbar erklaert.
Dasselbe Spiel mit den Vorbedingungen: Beim Euro waren es die Maastrichter Kriterien, die schon vor 1999 nicht erfuellt wurden und inzwischen offen missachtet werden. Die Tuerkei-Kriterien heissen: Wiedervereinigung Zyperns (als ob das so wichtig waere), Menschenrechte, Demokratisierung. Nichts hindert Ankara daran, diese Bedingungen pro forma zu erfuellen. Selbst wenn sie erfuellt wuerden, waeren damit die oben angefuehrten grundlegenden Argumente gegen den Tuerkei-Beitritt nicht im geringsten widerlegt.
Ein uebles Spiel, das den Verdacht naehrt, hier werde eine Verschwoerung gegen Deutschland und Europa angezettelt. Berlin hat sich ohne jedes Waehlermandat bereits festgelegt. Sollte der Beitritt scheitern, sagte Aussenminister Fischer laut 'WamS' vom 8. 2. 2004, wuerde man dafuer 'einen sehr hohen Preis zahlen'.

Ein Satz, den man zweimal lesen muss. Fischer droht dem deutschen Volk. Worin der hohe Preis bestehen wuerde, verschweigt er. Vielleicht meint er, dass die in Deutschland lebenden Tuerken auf die Strasse gehen koennten. Oder er fuerchtet den Zorn der USA, die den Beitritt seit Jahren verlangen. Washington weiss genau, dass die Aufnahme Kleinasiens zu einem 'bankrotten Halt' der gesamten EU (so die 'Financial Times' vom 15.1.2004) fuehren koennte. Ganz nuechtern urteilt die 'International Herald Tribune' am 24.11.2003:

'Dass die Bevoelkerung in ganz Europa schrumpft, bedeutet, dass noch mehr Einwanderung bevorsteht. Die Aufnahme der Tuerkei als EU-Mitglied wuerde diesen Trend beschleunigen und die Definition Europas unwiderruflich aendern … Viele Europaeer muessen erst noch akzeptieren, dass die traditionell weisse, christliche Kultur ihrer Vorfahren abgeloest wird von einem multikulturellen Mix mit einem starken islamischen Gewicht.'

Delivery-date: Sat, 12 Jun 2004 15:45:56 +0000
Date: Sat, 12 Jun 2004 17:47:01 +0200
From: [email-masked]
Reply-To: [email-masked], [email-masked]
To: Jean Philippe Vasseur <[email-masked]>
Cc: Arthi Ayyangar <[email-masked]>, Adrian Farrel <[email-masked]>, LE ROUX Jean-Louis FTRD/DAC/LAN <[email-masked]>, [email-masked], TE <[email-masked]>, CCAMP <[email-masked]>
Subject: Re: Last call comments:  draft-ietf-tewg-interarea-mpls-te-req-01.txt

hi jp,

Jean Philippe Vasseur wrote:

> Hi,
> 
> At 04:08 PM 6/11/2004 -0700, Arthi Ayyangar wrote:
> 
>> Hi,
>>
>> IMO it should suffice to request the service instead of specifying which
>> signaling method to use to deliver that service. As Vishal mentioned,
>> different networks may use different methods to deliver the same service.
>> In fact, each network may have its own motivations to choose one method
>> over the other, for whatever reasons, and that should be fine.
>>
>> I don't see how a HE equipment can grasp the various considerations and
>> limitations of some other network. I understand that there is need to
>> request a service per LSP, but I don't see how equating a type of
>> service to a signaling method buys us anything.
>>
>> Instead, if we invest some effort into making sure that the requested
>> service is understood and first identify what parameters constitute this
>> service and put in processing rules or ways for the downstream node to 
>> map the
>> incoming request to a service definition, it may help.
> 
> And I do not see why specifying the signalling method would be a problem 
> at all. If a SP requires a contiguous LSP to avoid its LSP to be 
> stitched along its path and potentially reoptimized without any HE 
> control, specifying that the LSP must be contiguous (or not) is indeed 
> the right method. 

as already mentioned just provide an indication to maintain the "head- 
end control for re-optimization" letting to the head end the control of 
this operation but this is orthogonal to the signaling method

i think the issue you're looking at can be sum'ed up as is there a case 
where you are not able to control the signaling method would preclude 
the ability to provide the required service (adrian had the same remark 
here and i want to underline that this issue is going now since the 
first time this document has been issued)

> There could be many potential implication of the 
> signalling method and trying to specify an SLA covering all of them 
> would not quite hard to achieve.

while for the time being there is some questioning about above mentioned 
  condition, i definitely see lot's of drawbacks in signaling 
(controling) the signaling method - example is that for instance leaving 
the control to the head-end for re-optimization (contiguous) precludes 
optimization in terms of number of LSPs to be maintained at each 
intermediate node (no nesting) so in brief you'd be optimizing only one 
dimension in the detriment of others

thanks,
- dimitri.

> Thanks
> 
> JP.
> 
>> thanks,
>> -arthi
>>
>> > >>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
>> > >>would seem it should be enough for the head-end to signal the
>> > >>function/service it wants and not the underlying method used
>> > >>by nodes further in path to provide that service. If, as you
>> > >>mention, this is a requirement expressed by many SPs, it would
>> > >>be good to understand why it is so, and for the document to
>> > >>explain a bit about it.
>> > >
>> > >Actually I don't really understand the objection on that point.
>> > >The requirement seems clear for me. If there are several methods
>> > >supported in my network, I want to select the method on a per
>> > >LSP basis in order to have entire control on how the LSP is
>> > >signaled. This will ease LSP management.
>> >
>> > But WHY do you want to control the method?
>> >
>> > Is it because you believe one of the methods is (may be) 
>> sub-functional? If that is the
>> > case, why do we standardise it?
>> >
>> > Is it because the methods have different applicability? That is, the 
>> methods are suitable
>> > to different functional service requests? If so, why don't you 
>> specify the service request
>> > and leave the network to provide the service.
>> >
>> > > Basically there won't be hundreds of methods but just two or three
>> > > (contiguous, stiching, nesting..).
>> >
>> > Yes. Hopefully :-)
>> >
>> > > So it seems quite relevant to have the ability to signal the 
>> desired method.
>> >
>> > It would really help  to give an example where not being able to 
>> control the method would
>> > break the ability to provide the requested service.
>> > (Hint: I think I found one while looking at inter-domain protection 
>> paths. But that is a
>> > fairly extreme situation.)
>> >
>> > I have serious concerns that allowing this approach means that we 
>> risk inter-operability
>> > disconnects.
>> >
>> > > Let's have a look at the FRR draft: There are two modes defined, 
>> and the
>> > > desired mode (one-to-one or bypass) is signaled on a per-LSP basis 
>> (within
>> > > the FRR object). I did not see any objection on that.
>> >
>> > I don't think holding the FRR draft up as a shining example is 
>> particularly wise.
>> >
>> > Given that two solutions were included in the document (because the 
>> authors/WG could not
>> > agree on a single solution?) and given that those solutions impacted 
>> the service provided
>> > to the service requester it was necessary to allow the requester to 
>> control the solution.
>> > In this case, controling the solution is equivalent to controling 
>> the service.
>> >
>> > Note that this feature raises interoperability questions for 
>> FRR-enabled networks.
>> >
>> > If, as I say, you are able to demonstrate that the inter-domain 
>> solutions impact the
>> > service, then you may be on to something.
>> >
>> > >>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
>> > >>underscore Adrian's point on specifying the scaling
>> > >>requirements themselves (with respect to areas, amount of
>> > >>flooded info. etc.) rather than the realization of those
>> > >>requirements (by not adding any info. to the LSAs, for example).
>> > >
>> > >It seems that you are OK with 5.3 (no comments)
>> > >"Containment of routing information MUST not be compromised to 
>> allow inter-area traffic
>> > >   engineering. Information propagation for path-selection MUST 
>> continue
>> > >   to be localized.".
>> > >Thus you should also be OK with 7.4
>> >
>> > Or conversely? :-)
>> >
>> > > Basically we want to preserve IGP hierachy concept, are there
>> > > objections to that point ?
>> >
>> > None has been vocalised.
>> >
>> > > This means, for ISPs contributing to this draft, "no leaking of any
>> > > topology related info accross areas".
>> > > Of course, this does not preclude the addition of info to the LSA,
>> > > provided that it is not topology related.
>> >
>> > So, for example, you would not be opposed to an LSA that described 
>> "aggregated TE
>> > reachability information"?
>> >
>> > Enjoy,
>> > Adrian
>> >
>> >
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Sat, 12 Jun 2004 14:51:34 +0000
Date: Sat, 12 Jun 2004 10:48:39 -0400
To: Arthi Ayyangar <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Cc: Adrian Farrel <[email-masked]>, LE ROUX Jean-Louis FTRD/DAC/LAN <[email-masked]>, [email-masked], TE <[email-masked]>, CCAMP <[email-masked]>

Hi,

At 04:08 PM 6/11/2004 -0700, Arthi Ayyangar wrote:
>Hi,
>
>IMO it should suffice to request the service instead of specifying which
>signaling method to use to deliver that service. As Vishal mentioned,
>different networks may use different methods to deliver the same service.
>In fact, each network may have its own motivations to choose one method
>over the other, for whatever reasons, and that should be fine.
>
>I don't see how a HE equipment can grasp the various considerations and
>limitations of some other network. I understand that there is need to
>request a service per LSP, but I don't see how equating a type of
>service to a signaling method buys us anything.
>
>Instead, if we invest some effort into making sure that the requested
>service is understood and first identify what parameters constitute this
>service and put in processing rules or ways for the downstream node to map the
>incoming request to a service definition, it may help.

And I do not see why specifying the signalling method would be a problem at 
all. If a SP requires a contiguous LSP to avoid its LSP to be stitched 
along its path and potentially reoptimized without any HE control, 
specifying that the LSP must be contiguous (or not) is indeed the right 
method. There could be many potential implication of the signalling method 
and trying to specify an SLA covering all of them would not quite hard to 
achieve.

Thanks

JP.

>thanks,
>-arthi
>
> > >>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
> > >>would seem it should be enough for the head-end to signal the
> > >>function/service it wants and not the underlying method used
> > >>by nodes further in path to provide that service. If, as you
> > >>mention, this is a requirement expressed by many SPs, it would
> > >>be good to understand why it is so, and for the document to
> > >>explain a bit about it.
> > >
> > >Actually I don't really understand the objection on that point.
> > >The requirement seems clear for me. If there are several methods
> > >supported in my network, I want to select the method on a per
> > >LSP basis in order to have entire control on how the LSP is
> > >signaled. This will ease LSP management.
> >
> > But WHY do you want to control the method?
> >
> > Is it because you believe one of the methods is (may be) 
> sub-functional? If that is the
> > case, why do we standardise it?
> >
> > Is it because the methods have different applicability? That is, the 
> methods are suitable
> > to different functional service requests? If so, why don't you specify 
> the service request
> > and leave the network to provide the service.
> >
> > > Basically there won't be hundreds of methods but just two or three
> > > (contiguous, stiching, nesting..).
> >
> > Yes. Hopefully :-)
> >
> > > So it seems quite relevant to have the ability to signal the desired 
> method.
> >
> > It would really help  to give an example where not being able to 
> control the method would
> > break the ability to provide the requested service.
> > (Hint: I think I found one while looking at inter-domain protection 
> paths. But that is a
> > fairly extreme situation.)
> >
> > I have serious concerns that allowing this approach means that we risk 
> inter-operability
> > disconnects.
> >
> > > Let's have a look at the FRR draft: There are two modes defined, and the
> > > desired mode (one-to-one or bypass) is signaled on a per-LSP basis 
> (within
> > > the FRR object). I did not see any objection on that.
> >
> > I don't think holding the FRR draft up as a shining example is 
> particularly wise.
> >
> > Given that two solutions were included in the document (because the 
> authors/WG could not
> > agree on a single solution?) and given that those solutions impacted 
> the service provided
> > to the service requester it was necessary to allow the requester to 
> control the solution.
> > In this case, controling the solution is equivalent to controling the 
> service.
> >
> > Note that this feature raises interoperability questions for 
> FRR-enabled networks.
> >
> > If, as I say, you are able to demonstrate that the inter-domain 
> solutions impact the
> > service, then you may be on to something.
> >
> > >>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
> > >>underscore Adrian's point on specifying the scaling
> > >>requirements themselves (with respect to areas, amount of
> > >>flooded info. etc.) rather than the realization of those
> > >>requirements (by not adding any info. to the LSAs, for example).
> > >
> > >It seems that you are OK with 5.3 (no comments)
> > >"Containment of routing information MUST not be compromised to allow 
> inter-area traffic
> > >   engineering. Information propagation for path-selection MUST continue
> > >   to be localized.".
> > >Thus you should also be OK with 7.4
> >
> > Or conversely? :-)
> >
> > > Basically we want to preserve IGP hierachy concept, are there
> > > objections to that point ?
> >
> > None has been vocalised.
> >
> > > This means, for ISPs contributing to this draft, "no leaking of any
> > > topology related info accross areas".
> > > Of course, this does not preclude the addition of info to the LSA,
> > > provided that it is not topology related.
> >
> > So, for example, you would not be opposed to an LSA that described 
> "aggregated TE
> > reachability information"?
> >
> > Enjoy,
> > Adrian
> >
> >

Delivery-date: Fri, 11 Jun 2004 23:09:30 +0000
Date: Fri, 11 Jun 2004 16:08:04 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: LE ROUX Jean-Louis FTRD/DAC/LAN <[email-masked]>, [email-masked], TE <[email-masked]>, CCAMP <[email-masked]>
Subject: Re: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt

Hi,

IMO it should suffice to request the service instead of specifying which
signaling method to use to deliver that service. As Vishal mentioned,
different networks may use different methods to deliver the same service.
In fact, each network may have its own motivations to choose one method
over the other, for whatever reasons, and that should be fine.

I don't see how a HE equipment can grasp the various considerations and
limitations of some other network. I understand that there is need to
request a service per LSP, but I don't see how equating a type of
service to a signaling method buys us anything.

Instead, if we invest some effort into making sure that the requested
service is understood and first identify what parameters constitute this
service and put in processing rules or ways for the downstream node to map the
incoming request to a service definition, it may help.

thanks,
-arthi

> >>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
> >>would seem it should be enough for the head-end to signal the
> >>function/service it wants and not the underlying method used
> >>by nodes further in path to provide that service. If, as you
> >>mention, this is a requirement expressed by many SPs, it would
> >>be good to understand why it is so, and for the document to
> >>explain a bit about it.
> >
> >Actually I don't really understand the objection on that point.
> >The requirement seems clear for me. If there are several methods
> >supported in my network, I want to select the method on a per
> >LSP basis in order to have entire control on how the LSP is
> >signaled. This will ease LSP management.
>
> But WHY do you want to control the method?
>
> Is it because you believe one of the methods is (may be) sub-functional? If that is the
> case, why do we standardise it?
>
> Is it because the methods have different applicability? That is, the methods are suitable
> to different functional service requests? If so, why don't you specify the service request
> and leave the network to provide the service.
>
> > Basically there won't be hundreds of methods but just two or three
> > (contiguous, stiching, nesting..).
>
> Yes. Hopefully :-)
>
> > So it seems quite relevant to have the ability to signal the desired method.
>
> It would really help  to give an example where not being able to control the method would
> break the ability to provide the requested service.
> (Hint: I think I found one while looking at inter-domain protection paths. But that is a
> fairly extreme situation.)
>
> I have serious concerns that allowing this approach means that we risk inter-operability
> disconnects.
>
> > Let's have a look at the FRR draft: There are two modes defined, and the
> > desired mode (one-to-one or bypass) is signaled on a per-LSP basis (within
> > the FRR object). I did not see any objection on that.
>
> I don't think holding the FRR draft up as a shining example is particularly wise.
>
> Given that two solutions were included in the document (because the authors/WG could not
> agree on a single solution?) and given that those solutions impacted the service provided
> to the service requester it was necessary to allow the requester to control the solution.
> In this case, controling the solution is equivalent to controling the service.
>
> Note that this feature raises interoperability questions for FRR-enabled networks.
>
> If, as I say, you are able to demonstrate that the inter-domain solutions impact the
> service, then you may be on to something.
>
> >>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
> >>underscore Adrian's point on specifying the scaling
> >>requirements themselves (with respect to areas, amount of
> >>flooded info. etc.) rather than the realization of those
> >>requirements (by not adding any info. to the LSAs, for example).
> >
> >It seems that you are OK with 5.3 (no comments)
> >"Containment of routing information MUST not be compromised to allow inter-area traffic
> >   engineering. Information propagation for path-selection MUST continue
> >   to be localized.".
> >Thus you should also be OK with 7.4
>
> Or conversely? :-)
>
> > Basically we want to preserve IGP hierachy concept, are there
> > objections to that point ?
>
> None has been vocalised.
>
> > This means, for ISPs contributing to this draft, "no leaking of any
> > topology related info accross areas".
> > Of course, this does not preclude the addition of info to the LSA,
> > provided that it is not topology related.
>
> So, for example, you would not be opposed to an LSA that described "aggregated TE
> reachability information"?
>
> Enjoy,
> Adrian
>
>

Delivery-date: Fri, 11 Jun 2004 21:36:55 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>
Subject: RE: RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Fri, 11 Jun 2004 14:35:28 -0700

Hi JL,

Thanks for the clarifications. A few follow-up thoughts in-line.

Regards,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of LE ROUX Jean-Louis FTRD/DAC/LAN
> Sent: Friday, June 11, 2004 9:30 AM
> To: [email-masked]; TE; CCAMP
> Subject: RE : Last call comments:
> draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
> Hi Vishal,
>
> Thanks a lot for these highly useful comments.
>
> Please see inline for some answers.
>
> Regards,
>
> JL
>

<snip>

> >7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
> >would seem it should be enough for the head-end to signal the
> >function/service it wants and not the underlying method used
> >by nodes further in path to provide that service. If, as you
> >mention, this is a requirement expressed by many SPs, it would
> >be good to understand why it is so, and for the document to
> >explain a bit about it.
>
> Actually I don't really understand the objection on that point.
> The requirement seems clear for me. If there are several methods
> supported in my network, I want to select the method on a per LSP
> basis in order to have entire control on how the LSP is signaled.
> This will ease LSP management.
> Basically there won't be hundreds of methods but just two or
> three (contiguous, stiching, nesting..)
> So it seems quite relevant to have the ability to signal the
> desired method.

As I explained in my email to JP, it is still somewhat unclear
as to what the ability to signal the desired method buys the
provider, and exactly why or how that simplifies LSP management.

> Let's have a look at the FRR draft: There are two modes defined,
> and the desired mode (one-to-one or bypass) is signaled on a
> per-LSP basis (within the FRR object). I did not see any
> objection on that.

I think the FRR draft is really a solutions draft, and it presents
two solutions which offer somewhat different services, in my view.
The detour provides the ability to protect segments of a _given_
LSP, while the bypass tunnel provides the ability to simultaneously protect
_multiple_ LSPs sharing a given resource (node(s) or link).

Also, as Adrian mentioned, it has lead to interop issues.

> >
> >8. Sec. 7.3 on path optimality talks only of the optimality
> >of a single path computed in isolation. What is the definition
> >of optimality to be applied for computing diverse paths? (Sec.
> >7.7 later does not specifically discuss this aspect either.)
> >If one used CSPF in sequence to compute two diverse paths (as
> >this section would imply) then the computation may fail, even
> >though a set of optimal diverse paths exists (as acknowledged
> >in Sec. 7.7 ahead).
>
> Agree, we should add a definition of optimality to be applied
> when computing diverse path
> This maybe: A placement of two diverse paths is optimal if their
> cumulative cost is minimal.

Yes, this is one definition. I think in  some previous email
exchanges, Fabio had provided a good definition of optimality
for diverse path routing. (I'll try to dig it up in the
archives, and post a note separately on it.)

> >9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
> >underscore Adrian's point on specifying the scaling
> >requirements themselves (with respect to areas, amount of
> >flooded info. etc.) rather than the realization of those
> >requirements (by not adding any info. to the LSAs, for example).
>
>
> It seems that you are OK with 5.3 (no comments)
> "Containment of routing information MUST not be compromised to
> allow inter-area traffic
>    engineering. Information propagation for path-selection MUST continue
>    to be localized.".
> Thus you should also be OK with 7.4

Actually, 5.3 imposes a requirement to preserve IGP hierarchy and
scalability,
but at least leaves open the possibility for the IGP to carry extra
information
as long as it is not an
"unreasonable amount of extra information" that does not "unreasonably
increase
IGP flooding frequency".

I thought 7.4 should probably provide some specifics on what unreasonable
is, and leave it to the protocol designers to devise protocols that keep
within those limits.
Instead it seems to prescribe a realization -- one where no topology
related info. of any sort should be added to the IGP LSAs.

> Basically we want to preserve IGP hierachy concept, are there
> objections to that point ?

Depends on whether you want to preserve it in spirit or to the
letter :-).
I think it may be useful to give protocol designers some
wiggle room.

> This means, for ISPs contributing to this draft, "no leaking of
> any topology related info accross areas".
> Of course, this does not preclude the addition of info to the
> LSA, provided that it is not topology related.
>
> >
> >If solutions can meet the scaling requirements by adding a bit
> >of info. to the IGP, I think this should be allowed, otherwise
> >there is really not much that could be achieved using current
> >mechanisms (since no modifications to them seem permissible,
> >and we already established that these, as they exist, do not
> >provide for adequate inter-area MPLS TE).
> >
> >BTW, one of the points made in this regard in these
> >email thread was about the use of path computation servers,
> >which can supposedly compute optimal paths without any impact
> >on the IGP.
> >
> >I think this argument isn't quite complete, since it hides the
> >signaling extensions required for these as well as the
> >scalability impact of recursive PCE-type schemes (btw, this
> >was a question that came up in independent discussions with JP
> >in the context of the ARO and PCE schemes, and is still under
> >discussion).
>
> Let's continue this discussion in another thread addressing solutions

Ok, sure.

> >10. Sec. 7.6, the figure O(N^2) makes the assumption that
> >each of the N ARBs at the border of the neighboring areas is
> >connected to each other ABR. No? In reality, the number of
> >crankback's may be significantly less therefore.
>
> No, basically if you have X1 ABRs in head-end area and X2 ABRs in
> tail-end area you may
> have up to X1*X2 crankbacks, provided that there is a path between all
> ABRs. This does not assume direct connectivity between ABRs.

Ok, thanks. I see now what you are saying.

> >11. Sec. 7.7, I guess it would be useful to qualify what is
> >considered "extra-load" in signaling and routing here. Is that
> >to be interpreted as _absolutely no change_ to current
> >signaling and routing protocol objects?
>
> No, this should not be interpreted as "absolutely no change".
> Basically the solution must respect scalability requirements
> spelt out in 5.2
> Will clarify in next revision.
>
>
> >seem feasible, if inter-area routing/TE is to be achieved, so
> >something more specific is implied, which would be good to spell out.
> >
> >BTW, also tend to agree with Adrian's point that this section
> >seems to be describing the computation of diverse paths rather
> >than the establishment of diverse paths, which would seem to
> >be the requirement.
>
> Yes this is basically a requirement on computation, but in this
> inter-domain context
> Path computation and Path establishment are no longer necessarily
> independant (see your ARO proposal)
>
>
> >
> >12. Sec. 7.9, what is meant by "inter-area head end LSR"?
> >An LSR that is the head-end of an inter-area LSP (that is, an
> >LSP traversing multiple areas)?
>
> Yes, will reword
>
> >
> >13. Sec. 8.2, not sure that is providing a real measurable
> >evaluation criterion. If it is to be kept, some specifics
> >should probably be given.

JL, sure. The perf. requirements are given in Sec. 8.1, but I was
looking at Sec. 8.2.

Also, even for 8.1, it may be good to add the = to explanation for (1)
and (2) that you've given below.

> IMHO what we list is clearly measurable
>    (1) Optimality of the computed inter-area TE LSP path.
> = Computed cost - Shortest cost
>    (2) Optimality of the computed backup tunnel path protecting against
>        the failure of an ABR, capability to share bandwidth among backup
>        tunnels protecting independent facilities
> = Total backup bandwidth consumption
>    (3) Inter-area TE LSP set up time.
>  = clearly measurable
>    (4) RSVP-TE and IGP scalability (state impact, number of messages,
>        message size)
>  = Memory footprint increase, CPU load increase, Message size
> Increase...This is also definitely measurable.
>

Delivery-date: Fri, 11 Jun 2004 19:36:57 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Jean Philippe Vasseur" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>
Subject: RE: Last call comments:  draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Fri, 11 Jun 2004 12:35:37 -0700

Hi JP at al,

Comments in-line.

-Vishal

> -----Original Message-----
> From: Jean Philippe Vasseur [mailto:[email-masked]]
> Sent: Friday, June 11, 2004 11:19 AM
> To: Adrian Farrel
> Cc: LE ROUX Jean-Louis FTRD/DAC/LAN; [email-masked]; TE; CCAMP
> Subject: Re: Last call comments:
> draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
> Hi Adrian,
>
> At 06:43 PM 6/11/2004 +0100, Adrian Farrel wrote:
> >Hi,
> >
> > >>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
> > >>would seem it should be enough for the head-end to signal the
> > >>function/service it wants and not the underlying method used
> > >>by nodes further in path to provide that service. If, as you
> > >>mention, this is a requirement expressed by many SPs, it would
> > >>be good to understand why it is so, and for the document to
> > >>explain a bit about it.
> > >
> > >Actually I don't really understand the objection on that point.
> > >The requirement seems clear for me. If there are several methods
> > >supported in my network, I want to select the method on a per
> > >LSP basis in order to have entire control on how the LSP is
> > >signaled. This will ease LSP management.
> >
> >But WHY do you want to control the method?
> >
> >Is it because you believe one of the methods is (may be) sub-functional?
> >If that is the
> >case, why do we standardise it?
> >
> >Is it because the methods have different applicability? That is, the
> >methods are suitable
> >to different functional service requests? If so, why don't you
> specify the
> >service request
> >and leave the network to provide the service.
>
> well, you may want different method for different LSPs ! Thus the
> requirement for signalling the required method.
>
> Cheers,
>
> JP.

I think that is the question precisely. Namely, why would a provider
want to control the exact method of how a specified service is provided?

It would seem to me that providers and their customers would agree on
a well-defined service. When signaling a request for the service, the
provider
HE equipment would specify the service (in some agreed upon standard format,
which would be standardized based on requirements in a document such as
the one we are discussing),
and would leave it to the intermediate routers/LSRs to figure out using
which method they can best provide that service.

I am not sure how having complete control over how an LSP is signaled
given the carrier any better ability to provide a given service.

It may be the case, for instance, that the provider chooses a given method
X as the choice to ask for a service A. However, given the network
situation,
it may be that method Y is the one able to provide the specified service,
where as X is not. What happens then? The request fails, and the provider
now has to retry with a different choice of method. By contrast, if the
service was specified, with the intermediate LSRs deciding how to provide
it, the request would be fulfilled in the initial instance.

-Vishal

Delivery-date: Fri, 11 Jun 2004 18:19:01 +0000
Date: Fri, 11 Jun 2004 14:18:30 -0400
To: "Adrian Farrel" <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Cc: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>, <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>

Hi Adrian,

At 06:43 PM 6/11/2004 +0100, Adrian Farrel wrote:
>Hi,
>
> >>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
> >>would seem it should be enough for the head-end to signal the
> >>function/service it wants and not the underlying method used
> >>by nodes further in path to provide that service. If, as you
> >>mention, this is a requirement expressed by many SPs, it would
> >>be good to understand why it is so, and for the document to
> >>explain a bit about it.
> >
> >Actually I don't really understand the objection on that point.
> >The requirement seems clear for me. If there are several methods
> >supported in my network, I want to select the method on a per
> >LSP basis in order to have entire control on how the LSP is
> >signaled. This will ease LSP management.
>
>But WHY do you want to control the method?
>
>Is it because you believe one of the methods is (may be) sub-functional? 
>If that is the
>case, why do we standardise it?
>
>Is it because the methods have different applicability? That is, the 
>methods are suitable
>to different functional service requests? If so, why don't you specify the 
>service request
>and leave the network to provide the service.

well, you may want different method for different LSPs ! Thus the 
requirement for signalling the required method.

Cheers,

JP.

> > Basically there won't be hundreds of methods but just two or three
> > (contiguous, stiching, nesting..).
>
>Yes. Hopefully :-)
>
> > So it seems quite relevant to have the ability to signal the desired 
> method.
>
>It would really help  to give an example where not being able to control 
>the method would
>break the ability to provide the requested service.
>(Hint: I think I found one while looking at inter-domain protection paths. 
>But that is a
>fairly extreme situation.)
>
>I have serious concerns that allowing this approach means that we risk 
>inter-operability
>disconnects.
>
> > Let's have a look at the FRR draft: There are two modes defined, and the
> > desired mode (one-to-one or bypass) is signaled on a per-LSP basis (within
> > the FRR object). I did not see any objection on that.
>
>I don't think holding the FRR draft up as a shining example is 
>particularly wise.
>
>Given that two solutions were included in the document (because the 
>authors/WG could not
>agree on a single solution?) and given that those solutions impacted the 
>service provided
>to the service requester it was necessary to allow the requester to 
>control the solution.
>In this case, controling the solution is equivalent to controling the service.
>
>Note that this feature raises interoperability questions for FRR-enabled 
>networks.
>
>If, as I say, you are able to demonstrate that the inter-domain solutions 
>impact the
>service, then you may be on to something.
>
> >>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
> >>underscore Adrian's point on specifying the scaling
> >>requirements themselves (with respect to areas, amount of
> >>flooded info. etc.) rather than the realization of those
> >>requirements (by not adding any info. to the LSAs, for example).
> >
> >It seems that you are OK with 5.3 (no comments)
> >"Containment of routing information MUST not be compromised to allow 
> inter-area traffic
> >   engineering. Information propagation for path-selection MUST continue
> >   to be localized.".
> >Thus you should also be OK with 7.4
>
>Or conversely? :-)
>
> > Basically we want to preserve IGP hierachy concept, are there
> > objections to that point ?
>
>None has been vocalised.
>
> > This means, for ISPs contributing to this draft, "no leaking of any
> > topology related info accross areas".
> > Of course, this does not preclude the addition of info to the LSA,
> > provided that it is not topology related.
>
>So, for example, you would not be opposed to an LSA that described 
>"aggregated TE
>reachability information"?
>
>Enjoy,
>Adrian

Delivery-date: Fri, 11 Jun 2004 17:44:02 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>, <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>
Subject: Re: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Fri, 11 Jun 2004 18:43:07 +0100

Hi,

>>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
>>would seem it should be enough for the head-end to signal the
>>function/service it wants and not the underlying method used
>>by nodes further in path to provide that service. If, as you
>>mention, this is a requirement expressed by many SPs, it would
>>be good to understand why it is so, and for the document to
>>explain a bit about it.
>
>Actually I don't really understand the objection on that point.
>The requirement seems clear for me. If there are several methods
>supported in my network, I want to select the method on a per
>LSP basis in order to have entire control on how the LSP is
>signaled. This will ease LSP management.

But WHY do you want to control the method?

Is it because you believe one of the methods is (may be) sub-functional? If that is the
case, why do we standardise it?

Is it because the methods have different applicability? That is, the methods are suitable
to different functional service requests? If so, why don't you specify the service request
and leave the network to provide the service.

> Basically there won't be hundreds of methods but just two or three
> (contiguous, stiching, nesting..).

Yes. Hopefully :-)

> So it seems quite relevant to have the ability to signal the desired method.

It would really help  to give an example where not being able to control the method would
break the ability to provide the requested service.
(Hint: I think I found one while looking at inter-domain protection paths. But that is a
fairly extreme situation.)

I have serious concerns that allowing this approach means that we risk inter-operability
disconnects.

> Let's have a look at the FRR draft: There are two modes defined, and the
> desired mode (one-to-one or bypass) is signaled on a per-LSP basis (within
> the FRR object). I did not see any objection on that.

I don't think holding the FRR draft up as a shining example is particularly wise.

Given that two solutions were included in the document (because the authors/WG could not
agree on a single solution?) and given that those solutions impacted the service provided
to the service requester it was necessary to allow the requester to control the solution.
In this case, controling the solution is equivalent to controling the service.

Note that this feature raises interoperability questions for FRR-enabled networks.

If, as I say, you are able to demonstrate that the inter-domain solutions impact the
service, then you may be on to something.

>>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
>>underscore Adrian's point on specifying the scaling
>>requirements themselves (with respect to areas, amount of
>>flooded info. etc.) rather than the realization of those
>>requirements (by not adding any info. to the LSAs, for example).
>
>It seems that you are OK with 5.3 (no comments)
>"Containment of routing information MUST not be compromised to allow inter-area traffic
>   engineering. Information propagation for path-selection MUST continue
>   to be localized.".
>Thus you should also be OK with 7.4

Or conversely? :-)

> Basically we want to preserve IGP hierachy concept, are there
> objections to that point ?

None has been vocalised.

> This means, for ISPs contributing to this draft, "no leaking of any
> topology related info accross areas".
> Of course, this does not preclude the addition of info to the LSA,
> provided that it is not topology related.

So, for example, you would not be opposed to an LSA that described "aggregated TE
reachability information"?

Enjoy,
Adrian

Delivery-date: Fri, 11 Jun 2004 16:33:39 +0000
Content-class: urn:content-classes:message
Subject: RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Fri, 11 Jun 2004 18:30:16 +0200
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>

Hi Vishal,

Thanks a lot for these highly useful comments.

Please see inline for some answers.

Regards,

JL

>-----Message d'origine-----
>De : Vishal Sharma [mailto:[email-masked]]=20
>Envoy=E9 : jeudi 10 juin 2004 03:16
>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN; TE; CCAMP
>Objet : Last call comments:=20
>draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
>Hi Jean-Louis et al,
>
>I have reviewed the above draft quite carefully, and it is
>a very useful document. Nice work!
>
>There are several comments I have as part of last call, I'm=20
>giving these below as technical and editorial, to make=20
>discussion easier.
>
>Thanks,
>-Vishal=20
>********************************************************************8
>
>Technical
>-----------
>
>1. Sec. 1, Introduction.
>"The set of MPLS traffic engineering tools," is probably=20
>better worded as "The set of MPLs traffic engineering=20
>components," as the phrase "MPLS traffic engineering tools" is=20
>liable to be confused with planning and traffic engineering=20
>tools/software (a la Netscope, NPAT, SPGuru, MATE, etc.).

Agree

>
>2. In the same section, how are the components useful for=20
>aggregated traffic measurement? Is it because, OSPF-TE and=20
>IS-IS TE may be used to convey parameters like aggregate link=20
>utilization? What else is included here?

Basically TE-LSPs offer an easy mean to measure the traffic matrix.
By accounting packets forwared into a TE-LSP you can deduce the traffic =
rate=20
between two end-points.
Some ISPs use a mesh of TE-LSP as a simple way to measure trafic matrix

>
>3. It would be good to have terms like "traffic engineering=20
>components", "traffic engineering mechanisms" and "traffic=20
>engineering tools" defined in the terminology section to clear=20
>distinguish between them, and avoid confusion when reading and=20
>interpreting this document.

Agree, will be done in next revision.=20
As suggested by Adrian, we will also add a section summarizing MPLS-TE =
components (routing, path computation, signaling).
This will help explaining current limitations and inter-area =
requirements.

>
>4. Sec. 4.1.3, para 1, not sure what "traffic sensitive=20
>applications" means. It might be better worded as "performance=20
>sensitive applications" or "quality sensitive applications."

Agree, "quality sensitive application" is better

>
>5. Sec. 4.2, option 3, it would be nice to have a phrase=20
>explaining why this is different than LSP hierarchy.
>

OK, will add a phrase to clarify: Basically here there is no FA-LSP =
advertisement

>6. Sec. 6, para 4, "pseudo wire connections" should really be=20
>just "pseudo wires"

OK

>
>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it=20
>would seem it should be enough for the head-end to signal the=20
>function/service it wants and not the underlying method used=20
>by nodes further in path to provide that service. If, as you=20
>mention, this is a requirement expressed by many SPs, it would=20
>be good to understand why it is so, and for the document to=20
>explain a bit about it.

Actually I don't really understand the objection on that point.
The requirement seems clear for me. If there are several methods =
supported in my network, I want to select the method on a per LSP basis =
in order to have entire control on how the LSP is signaled. This will =
ease LSP management.
Basically there won't be hundreds of methods but just two or three =
(contiguous, stiching, nesting..)
So it seems quite relevant to have the ability to signal the desired =
method.

Let's have a look at the FRR draft: There are two modes defined, and the =
desired mode (one-to-one or bypass) is signaled on a per-LSP basis =
(within the FRR object). I did not see any objection on that.

>
>8. Sec. 7.3 on path optimality talks only of the optimality
>of a single path computed in isolation. What is the definition=20
>of optimality to be applied for computing diverse paths? (Sec.=20
>7.7 later does not specifically discuss this aspect either.)=20
>If one used CSPF in sequence to compute two diverse paths (as=20
>this section would imply) then the computation may fail, even=20
>though a set of optimal diverse paths exists (as acknowledged=20
>in Sec. 7.7 ahead).

Agree, we should add a definition of optimality to be applied when =
computing diverse path
This maybe: A placement of two diverse paths is optimal if their =
cumulative cost is minimal.

>
>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to=20
>underscore Adrian's point on specifying the scaling=20
>requirements themselves (with respect to areas, amount of=20
>flooded info. etc.) rather than the realization of those=20
>requirements (by not adding any info. to the LSAs, for example).

It seems that you are OK with 5.3 (no comments)
"Containment of routing information MUST not be compromised to allow =
inter-area traffic=20
   engineering. Information propagation for path-selection MUST continue =

   to be localized.".=20
Thus you should also be OK with 7.4

Basically we want to preserve IGP hierachy concept, are there objections =
to that point ?
This means, for ISPs contributing to this draft, "no leaking of any =
topology related info accross areas".=20
Of course, this does not preclude the addition of info to the LSA, =
provided that it is not topology related.

>
>If solutions can meet the scaling requirements by adding a bit=20
>of info. to the IGP, I think this should be allowed, otherwise=20
>there is really not much that could be achieved using current=20
>mechanisms (since no modifications to them seem permissible,=20
>and we already established that these, as they exist, do not=20
>provide for adequate inter-area MPLS TE).
>
>BTW, one of the points made in this regard in these
>email thread was about the use of path computation servers,=20
>which can supposedly compute optimal paths without any impact=20
>on the IGP.
>
>I think this argument isn't quite complete, since it hides the=20
>signaling extensions required for these as well as the=20
>scalability impact of recursive PCE-type schemes (btw, this=20
>was a question that came up in independent discussions with JP=20
>in the context of the ARO and PCE schemes, and is still under=20
>discussion).

Let's continue this discussion in another thread addressing solutions

>
>10. Sec. 7.6, the figure O(N^2) makes the assumption that
>each of the N ARBs at the border of the neighboring areas is=20
>connected to each other ABR. No? In reality, the number of=20
>crankback's may be significantly less therefore.

No, basically if you have X1 ABRs in head-end area and X2 ABRs in =
tail-end area you may=20
have up to X1*X2 crankbacks, provided that there is a path between all
ABRs. This does not assume direct connectivity between ABRs.

>
>11. Sec. 7.7, I guess it would be useful to qualify what is=20
>considered "extra-load" in signaling and routing here. Is that=20
>to be interpreted as _absolutely no change_ to current=20
>signaling and routing protocol objects?=20

No, this should not be interpreted as "absolutely no change".
Basically the solution must respect scalability requirements spelt out =
in 5.2
Will clarify in next revision.

>seem feasible, if inter-area routing/TE is to be achieved, so=20
>something more specific is implied, which would be good to spell out.
>
>BTW, also tend to agree with Adrian's point that this section=20
>seems to be describing the computation of diverse paths rather=20
>than the establishment of diverse paths, which would seem to=20
>be the requirement.

Yes this is basically a requirement on computation, but in this =
inter-domain context
Path computation and Path establishment are no longer necessarily =
independant (see your ARO proposal)

>
>12. Sec. 7.9, what is meant by "inter-area head end LSR"?
>An LSR that is the head-end of an inter-area LSP (that is, an=20
>LSP traversing multiple areas)?

Yes, will reword

>
>13. Sec. 8.2, not sure that is providing a real measurable=20
>evaluation criterion. If it is to be kept, some specifics=20
>should probably be given.

=20
IMHO what we list is clearly measurable
   (1) Optimality of the computed inter-area TE LSP path.=20
=3D Computed cost - Shortest cost=20
   (2) Optimality of the computed backup tunnel path protecting against  =

       the failure of an ABR, capability to share bandwidth among backup =
=20
       tunnels protecting independent facilities=20
=3D Total backup bandwidth consumption
   (3) Inter-area TE LSP set up time.
 =3D clearly measurable
   (4) RSVP-TE and IGP scalability (state impact, number of messages,    =

       message size)=20
 =3D Memory footprint increase, CPU load increase, Message size =
Increase...This is also definitely measurable.

>
>
>Editorial
>-----------
>
>Below phrases between _xxxx_ are added, and between <xxxx> are=20
>to be removed.
>
>1. Sec. 1, Introduction, ", that supports ..." --> "which supports ..."
>
>2. Sec. 4, para 1, line 4, "This section is intended to help=20
>_in_ defining ..."
>
>3. Sec. 4.1.1 --> "Intra-area _resource_ optimization"
>
>4. Sec, 4.1.1. line 1 --> "MPLS-TE can be used within an area=20
>to redirect paths of aggregated flows away from over-utilized=20
>resources within a network."
>
>5. Sec. 4.1.1., para 2 -->
>"In this way, MPLS-TE allows for greater control _over_ how=20
>traffic demands _are routed over_ <utilize> a network=20
>topology, and _utilize a network's resources_"
>
>5. Sec. 4.1.1., para 2 --> "As mentioned in Section 1, uses
>   to date have been limited to <within> a single IGP area."
>
>6. Sec. 4.2, option 4, what are the numbers (2) and (3) in brackets?
>
>7. Sec. 5.1, para 6, "one possible approach could consist _of_=20
>deploying ..."
>
>8. Sec. 5.2, I am not sure why there is a small subsection=20
>itself titled "Requirements for inter-area MPLS TE", when the=20
>entire document is about this subject? Is the intent here to=20
>motivate the need for inter-area MPLS TE? If so, maybe it=20
>should say "Motivations for inter-area MPLS TE"?

Thanks a lot for these editorial comments

>
>These a few of the ones that I caught. In general, I feel the=20
>document would benefit from a thorough editorial review of=20
>writing, that would help to eliminate some awkward=20
>constructions and redudancy in several places.
>
>

Agree, will do that for next revision.

Again thanks a lot Vishal, for these highly relevant comments

Regards,

JL

Delivery-date: Fri, 11 Jun 2004 16:00:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, "John Drake" <[email-masked]>, "Jerry Ash" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Cc: <[email-masked]>
Subject: Fw: AD-review comments on draft-ietf-ccamp-gmpls-ason-reqts
Date: Fri, 11 Jun 2004 16:58:17 +0100

Hi,

The AD (Alex) has now had a chance to go through the ASON signaling requirements draft and
has a few comments we need to fix before the draft can go forward to the IESG.

Since I'm an author I will sit out of the drafting process at this point and will run
wholly as a co-chair. If anyone has an issue with that, please speak up and Kireeti will
step in.

Process:
- Please look at the comments with my notes, below, and
  if there is any debate have it with me on the list (cc Alex).
- Please produce a new version of the draft BUT do not
  submit it.
- Bring the draft to me and persuade me that it addresses
   all of Alex's points.
- Submit the draft.

Thanks,
Adrian

----- Original Message ----- 
From: "Alex Zinin" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>; "Adrian Farrel" <[email-masked]>
Sent: Friday, June 04, 2004 7:14 PM
Subject: AD-review comments on draft-ietf-ccamp-gmpls-ason-reqts

> draft-ietf-ccamp-gmpls-ason-reqts:
> ---------------------------------
>
> Section 2: conventions.
>
>  Since 2119 talks about protocol specifications and implementations, a note
>  along the following lines would be helpful:
>
>   "While [2119] describes interpretations of these key words in terms of
>    protocol specifications and implementations, they are used in this document
>    to describe design requirements for protocol extensions."
>
>  Regarding MAY/SHOULD/MUST themselves. The way these key words are used in
>  the document is not consistent. One would assume that they would be used
>  to specify what features or functionality would need to be supported.
>  However, in certain places, the way they are used is questionable.
>  For example:
>
> > 3. Introduction
> ...
> >    This document concentrates on requirements related to the signaling
> >    aspects of the GMPLS suite of protocols. It discusses functional
> >    requirements required to support Automatically Switched Optical
> >    Networks that MAY lead to additional extensions to GMPLS signaling
>                    ^^^
> >    (see [RFC 3471] and [RFC 3473]) to support these capabilities.
>
> or:
>
> >                                          It MUST NOT be assumed that
>                                               ^^^^^^^^
> >    there is a one-to-one relationship of control plane interfaces and
> >    transport plane (physical) links, or that there is a one-to-one
> >    relationship of control plane entities and transport plane entities,
> >    or that there is a one-to-one relationship of control plane
> >    identifiers for transport plane resources.
>
>   On the other hand, for instance, section 4 does not have these words
>   capitalized:
>
> > 4.2 Support for Call and Connection Separation
> ...
> >    To support the introduction of the call concept, GMPLS signaling
> >    should include a call identification mechanism and allow for end-to-
>      ^^^^^^
> >    end call capability exchange.
>
>
>   Please go through the document and make sure cases like these are corrected.

I suggest you add Alex's text in section 2.
You'll just have to grep the doc for MAY/SHOULD/MUST and try to be consistent. In
particular, don't use capitalisation for emphasis, but only for specific requirements.

>   Some notes on the contents of the document:
>
> >   Section 4.4:
> ...
> >    - Any control plane failure must not result in releasing established
> >      calls and connections (including the corresponding transport plane
> >      connections).
>
>   Does "any control plane failure" include fatal and unrecoverable ones?
>   Does it only include single failure, or double/multiple failures also?
>   These are important questions to answer, especially in comparison with
>   the assumptions behind IETF graceful restart work.

I have discussed with Alex that "any" was intended in the full meaning of the word.
If you can think of a way to emphasise this point, that would be good.
We don't want to try to produce an inclusive list of all failure conditions, but there may
be a short list of categories?

I have asked Alex to clarify his point about graceful restart.

It might help to be a bit more explicit about the requirement here. I.e. "It must be
possible to hold a transport plane connection (LSP) up despite control plane or transport
plane failures unless explicitly torn down."

> > 4.6 Support for Crankback
> ...
> >    - Rerouting attempts limitation: to prevent an endless repetition of
> >      connection setup attempts (using crankback information), the
> >      number of retries should be strictly limited. The maximum number
> >      of crankback rerouting attempts allowed can be limited per
> >      connection, per node, per area or even per administrative domain.
>
> It is not clear what is meant here for the per-area/domain case.
>
> Is it the sum of rerouting attempts that all nodes in an area can make (which
> would require some sort of distributed coordination mechanism) or the number of
> attempts that the connection initiator can make through a specific area?

We need to clarify this text to indicate that in all cases, it is the number of attempts
that can be made *at* a spatial coordinate.

> Section 9: references.
>
> Is it possible to easily access the ITU-T documents referenced?
> Can URLs be included?

I have told Alex that this is unlikely.
Does anyone know of any way to make theses references available?

I don't think there is anything to be done. However, I notice that G.8080 is listed as a
normative reference. Given the difficulty in accessing this document, it should be moved
to the informational references section.

Thanks,
Adrian

Delivery-date: Fri, 11 Jun 2004 15:16:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Wesam Alanqar" <[email-masked]>, "Stephen Shew" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, "Jonathan Sadler" <[email-masked]>, "Dave Meyer" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Cc: <[email-masked]>
Subject: Fw: AD-review comments on draft-ietf-ccamp-gmpls-ason-routing-reqts
Date: Fri, 11 Jun 2004 16:14:57 +0100

Hi,

The AD (Alex) has now had a chance to go through the ASON routing requirements draft and
has a few comments we need to fix before the draft can go forward to the IESG.

Process:
- Please look at the comments with my notes, below, and
  if there is any debate have it with me on the list (cc Alex).
- Please produce a new version of the draft BUT do not
  submit it.
- Bring the draft to me and persuade me that it addresses
   all of Alex's points.
- Submit the draft.

Thanks,
Adrian

----- Original Message ----- 
From: "Alex Zinin" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>; "Adrian Farrel" <[email-masked]>
Sent: Friday, June 04, 2004 7:14 PM
Subject: AD-review comments on draft-ietf-ccamp-gmpls-ason-routing-reqts

> draft-ietf-ccamp-gmpls-ason-routing-reqts:
> ------------------------------------------
>
> The list of authors is too long according to the recent RFC Editor policies.

The issue is only the title page.
I suggest you show one Editor (Deborah?) and list the authors in the
authors' section as currently.
You could list the DT in section 1 to give them full prominence.

>  Since 2119 talks about protocol specifications and implementations, a note
>  along the following lines would be helpful:
>
>   "While [2119] describes interpretations of these key words in terms of
>    protocol specifications and implementations, they are used in this document
>    to describe design requirements for protocol extensions."
>
>  Regarding MAY/SHOULD/MUST themselves. The way these key words are used in
>  the document is not consistent. One would assume that they would be used
>  to specify what features or functionality would need to be supported.
>  However, in certain places, the way they are used is questionable.

I suggest you add Alex's text in section 2.
You'll just have to grep the doc for MAY/SHOULD/MUST and try to be consistent. In
particular, don't use capitalisation for emphasis, but only for specific requirements.

> Comments on specific parts of the text:
>
> > 4. ASON Routing Architecture and Requirements
> ...
> >    The failure of a RC, or the failure of communications between RCs,
> >    and the subsequent recovery from the failure condition MUST NOT
> >    disrupt calls in progress and their associated connections. Calls
>              ^^^^^^^^^^^^^^^^^
>
> it took a while to realize that what's meant here wasn't calls in the process of
> being established, but those already established. Some wording changes might
> help here.

Suggest you add a clarification "(i.e. already established.)"

> > 4.2 Hierarchical Routing Information Dissemination
> ...
> >                                             If routing information is
> >    exchanged between a RC, its parent, and its child RCs, it SHOULD
> >    include reachability and MAY include (upon policy decision) node and
> >    link topology. Communication between RAs only takes place between
> >    RCs with a parent/child relationship.
>
> the definition of "reachability" has been given at this point and the reader
> wonders what it is.

Yes. This is worth defining since it is a key requirement.

> >    Multiple RCs bound to the same RA MAY transform (filter, summarize,
> >    etc.) and then forward information to RCs at different levels.
> >    However in this case the resulting information at the receiving
> >    level must be self-consistent; this MAY be achieved using a number
> >    of mechanisms.
>
> it would be useful to explain what "self-consistent" means in this
> context.

Yes.

> >    3. Method of Communication
> >
> >       Two approaches exist for communication between Level N and N+1.
> >
> >       - The first approach places an instance of a Level N routing
> >         function and an instance of a Level N+1 routing function in the
> >         same system. The communications interface is within a single
> >         system and is thus not an open interface subject to
> >         standardization.
>
> This is right in a sense that one doesn't have to define how to _take_ info
> level N for later announcement to N+1. However, certain aspects of such
> reannouncement or leaking will have to be done in a consistent manner to ensure
> interoperability and basic protocol correctness (e.g., cost/metric value).

Alex seems to be saying that we need to standardise *what* information is exchanged and
how it is used in the
other level. We do not need to standardise *how* that exchange takes place.

> > 4.5 Routing Attributes
> >
> >    Routing for transport networks is performed on a per layer basis,
> >    where the routing paradigms MAY differ among layers and within a
> >    layer. Not all equipment supports the same set of transport layers
> >    or the same degree of connection flexibility at any given layer. A
> >    server layer trail may support various clients, involving different
> >    adaptation functions. Additionally, equipment may support variable
> >    adaptation functionality, whereby a single server layer trail
> >    dynamically supports different multiplexing structures. As a result,
> >    routing information MAY include layer specific, layer independent,
> >    and client/server adaptation information.
>
> The notions of "server", "layer", "server layer trail", "client", etc. haven't
> been defined and are completely foreign for a usual IETF reader.

Ah! Terminology creep. I think you can add these to appendix 1.

> > 4.5.3 Node Attributes
> >
> >    All nodes belong to a RA, hence, the RA ID can be considered an
> >    attribute of all nodes. Given that no distinction is made between
> >    abstract nodes and those that cannot be decomposed any further, the
> >    same attributes MAY be used for their advertisement. In the
> >    following tables, Capability refers to the level of support required
> >    in the realization of a link state routing protocol, whereas Usage
> >    refers to the degree of operational and implementation flexibility.
>
> The last sentence doesn't really help understanding what "Usage" below is used
> for from the protocol design perspective. Please clarify.

Yes.

> >    The following Node Attributes are defined:
> >
> >        Attribute        Capability      Usage
> >        -----------      -----------     ---------
> >
> > 4.5.4 Link Attributes
> >
> >    The following Link Attributes are defined:
> >
> >        Link Attribute                   Capability      Usage
> >        ---------------                  -----------     ---------
> >        Local SNPP link ID               REQUIRED        REQUIRED
> >        Remote SNPP link ID              REQUIRED        REQUIRED
> >        Layer Specific Characteristics   see Table 3
> >
> >                          Table 2. Link Attributes
> >
> >    The SNPP link ID MUST be sufficient to uniquely identify the
> >    corresponding transport plane resource taking into account
>
> Is it in conjunction with the Node ID?

Just need to clarify the scope of "uniquely".

> > 5. Security Considerations
> >
> >    ASON routing protocol MUST deliver the operational security
> >    objectives where required.
>
> What are they?

:-)

My fault. I should not have let you get this far without a better security section.

> References.
>
> Is it possible to easily access the ITU-T documents referenced?
> Can URLs be included?

I have told Alex that this is unlikely.
Does anyone know of any way to make theses references available?

Cheers,
Adrian

Delivery-date: Thu, 10 Jun 2004 01:16:57 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Jean-Louis Le Roux" <[email-masked]>, "TE" <[email-masked]>, "CCAMP" <[email-masked]>
Subject: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Wed, 9 Jun 2004 18:15:51 -0700

Hi Jean-Louis et al,

I have reviewed the above draft quite carefully, and it is
a very useful document. Nice work!

There are several comments I have as part of last call, I'm
giving these below as technical and editorial, to make discussion
easier.

Thanks,
-Vishal
********************************************************************8

Technical
-----------

1. Sec. 1, Introduction.
"The set of MPLS traffic engineering tools," is probably better worded
as "The set of MPLs traffic engineering components," as the
phrase "MPLS traffic engineering tools" is liable to be confused
with planning and traffic engineering tools/software (a la
Netscope, NPAT, SPGuru, MATE, etc.).

2. In the same section, how are the components useful for
aggregated traffic measurement?
Is it because, OSPF-TE and IS-IS TE may be used to convey
parameters like aggregate link utilization? What else is
included here?

3. It would be good to have terms like "traffic engineering components",
"traffic engineering mechanisms" and "traffic
engineering tools" defined in the terminology section to
clear distinguish between them, and avoid confusion when
reading and interpreting this document.

4. Sec. 4.1.3, para 1, not sure what "traffic sensitive
applications" means. It might be better worded as "performance
sensitive applications" or "quality sensitive applications."

5. Sec. 4.2, option 3, it would be nice to have a phrase
explaining why this is different than LSP hierarchy.

6. Sec. 6, para 4, "pseudo wire connections" should really be
just "pseudo wires"

7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
would seem it should be enough for the head-end to signal
the function/service it wants and not the underlying method
used by nodes further in path to provide that service.
If, as you mention, this is a requirement expressed by
many SPs, it would be good to understand why it is so, and
for the document to explain a bit about it.

8. Sec. 7.3 on path optimality talks only of the optimality
of a single path computed in isolation. What is the definition
of optimality to be applied for computing diverse paths?
(Sec. 7.7 later does not specifically discuss this aspect either.)
If one used CSPF in sequence to compute two diverse paths
(as this section would imply) then the computation may fail, even
though a set of optimal diverse paths exists (as acknowledged in
Sec. 7.7 ahead).

9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
underscore Adrian's point on specifying the scaling requirements
themselves (with respect to areas, amount of flooded info. etc.)
rather than the realization of those requirements (by not adding
any info. to the LSAs, for example).

If solutions can meet the scaling requirements by adding a bit of
info. to the IGP, I think this should be allowed, otherwise
there is really not much that could be achieved using current
mechanisms (since no modifications to them seem permissible, and
we already established that these, as they exist, do not provide
for adequate inter-area MPLS TE).

BTW, one of the points made in this regard in these
email thread was about the use of path computation servers,
which can supposedly compute optimal paths without any impact on
the IGP.

I think this argument isn't quite complete, since it hides the
signaling extensions required for these as well as the
scalability impact of recursive PCE-type schemes (btw, this was a
question that came up in independent discussions with JP in the
context of the ARO and PCE schemes, and is still under discussion).

10. Sec. 7.6, the figure O(N^2) makes the assumption that
each of the N ARBs at the border of the neighboring areas is
connected to each other ABR. No?
In reality, the number of crankback's may be significantly less
therefore.

11. Sec. 7.7, I guess it would be useful to qualify what is
considered "extra-load" in signaling and routing here.
Is that to be interpreted as _absolutely no change_ to
current signaling and routing protocol objects?
Clearly, that doesn't seem feasible, if inter-area routing/TE
is to be achieved, so something more specific is implied, which
would be good to spell out.

BTW, also tend to agree with Adrian's point that this section
seems to be describing the computation of diverse paths rather
than the establishment of diverse paths, which would seem to
be the requirement.

12. Sec. 7.9, what is meant by "inter-area head end LSR"?
An LSR that is the head-end of an inter-area LSP (that is, an
LSP traversing multiple areas)?

13. Sec. 8.2, not sure that is providing a real measurable
evaluation criterion. If it is to be kept, some specifics
should probably be given.

Editorial
-----------

Below phrases between _xxxx_ are added, and between <xxxx> are
to be removed.

1. Sec. 1, Introduction, ", that supports ..." --> "which supports ..."

2. Sec. 4, para 1, line 4, "This section is intended to help
_in_ defining ..."

3. Sec. 4.1.1 --> "Intra-area _resource_ optimization"

4. Sec, 4.1.1. line 1 --> "MPLS-TE can be used within an area to redirect
paths of aggregated flows away from over-utilized resources within a
network."

5. Sec. 4.1.1., para 2 -->
"In this way, MPLS-TE allows for greater control _over_ how traffic
demands _are routed over_ <utilize> a network topology, and _utilize
a network's resources_"

5. Sec. 4.1.1., para 2 --> "As mentioned in Section 1, uses
   to date have been limited to <within> a single IGP area."

6. Sec. 4.2, option 4, what are the numbers (2) and (3) in brackets?

7. Sec. 5.1, para 6, "one possible approach could consist _of_ deploying
..."

8. Sec. 5.2, I am not sure why there is a small subsection itself titled
"Requirements for inter-area MPLS TE", when the entire document is about
this subject? Is the intent here to motivate the need for inter-area MPLS
TE?
If so, maybe it should say "Motivations for inter-area MPLS TE"?

These a few of the ones that I caught. In general, I feel the document
would benefit from a thorough editorial review of writing, that would
help to eliminate some awkward constructions and redudancy in several
places.

Delivery-date: Wed, 09 Jun 2004 17:28:50 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-egress-control-02.txt
Date: Wed, 9 Jun 2004 18:27:02 +0100

All,
I think I fumbled this. Sorry.

Alex,
This draft has been updated by the author after the WG last call comments.
It is now ready for AD review.

Thanks,
Adrian

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 12, 2004 2:18 PM
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-egress-control-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 : GMPLS Signaling Procedure For Egress Control
> Author(s) : L. Berger
> Filename : draft-ietf-ccamp-gmpls-egress-control-02.txt
> Pages : 6
> Date : 2004-5-11
>
> This note clarifies the procedures for the control of the label used
>    on a output/downstream interface of the egress node of a Label
>    Switched Path (LSP).  Such control is also known as "Egress Control".
>    Support for Egress Control is implicit in Generalized Multi-Protocol
>    Label Switching (GMPLS) Signaling.  This note does not modify GMPLS
>    signaling mechanisms and procedures and should be viewed as an
>    informative clarification of GMPLS Signaling - Resource ReserVation
>    Protocol-Traffic Engineering (RSVP-TE) Extensions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-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-egress-control-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-egress-control-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: Wed, 09 Jun 2004 17:13:06 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Letter received from OIF
Date: Wed, 9 Jun 2004 18:07:33 +0100

All,

A letter in PDF has been received from the OIF with the attached email.

The PDF file can be found at http://www.olddog.co.uk/incoming.htm.

Adrian
----- Original Message ----- 
From: "Kimberly Chiu" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, June 04, 2004 1:57 AM
Subject: Regarding: IETF CCAMP response to OIF intra-carrier E-NNI routing work

> Mr Kompella, Farrel, Zinin, and Mr Fenner,
>
> On behalf of Steve Joiner, OIF Technical Committee Chair, attached please
> find  a letter in response to IETF CCAMP's correspondence of March 19
> regarding OIF intra-carrier E-NNI routing work.
>
> Kind regards,
> Kimberly
>
> __________________________________________________________
> Kimberly Chiu / Senior Coordinator / Optical Internetworking Forum
> 39355 California Street / Suite 307 / Fremont, CA 94538 USA
> Phone: +1.510.608.5928 main / +1.510.608.5929 direct
> Fax: +1.510.608.5917
> Email: [email-masked]
> http://www.oiforum.com
>
> Managed by Association Management Solutions (AMS);
> Forum Management, Meeting and Event Planning
> http://www.amsl.com
>

Delivery-date: Fri, 04 Jun 2004 12:22:36 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Christian Hopps" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, "Jonathan Sadler" <[email-masked]>, "Stephen Shew" <[email-masked]>, "David Ward" <[email-masked]>
Subject: ASON Routing Solutions Design Team
Date: Fri, 4 Jun 2004 10:37:21 +0100

Hi All,

A new Design Team in the CCAMP WG has been formed.  The team members
and charter follow.

Please send comments to the CCAMP list.  The DT has an aggressive
schedule, so constructive comments will be greatly appreciated.

Thanks to all the DT members for accepting this responsibility!

Adrian
=====
ASON Routing Solutions Design Team
----------------------------------

Members (alphabetical order):

      Chris Hopps <[email-masked]>
      Lyndon Ong <[email-masked]>
      Dimitri Papadimitriou <[email-masked]>
      Jonathan Sadler <[email-masked]>
      Stephen Shew <[email-masked]>
      Dave Ward <[email-masked]>

Charter:
-------

To evaluate existing IETF routing protocols against the ASON routing requirements that
were documented in <draft-ietf-ccamp-gmpls-ason-routing-reqts> as a joint effort of the
IETF CCAMP Working Group and ITU-T SG15.

This evaluation is to be produced by a close examination of applicability scenarios. The
result of the evaluation of these scenarios is an integral part of the output of this
design team.

The design team will then move on to the design of extensions to the IETF routing
protocols as appropriate in close collaboration with the corresponding Working Groups
(such as the OSPF, IS-IS and IDR working groups).

Consideration should also be given to the exclusion of protocol elements or procedures
that are not appropriate or relevant in the ASON routing scenarios that the team
describes.

Finally, the design team is responsible for drafting liaison statements from the CCAMP WG
to the ITU-T SG15 and OIF regarding GMPLS ASON routing solutions, as well as for drafting
replies to liaisons received from the ITU-T SG15 and OIF. Note that no Liaisons drafted by
the design team will be sent or replied to without approval from the CCAMP WG chairs, ADs
and rough consensus of the CCAMP WG.

Standard design team disclaimer: this design team has no special status in the CCAMP WG.
Any documents they produce are subject to the usual WG procedures. Individuals are
encouraged to interact with the design team, to offer suggestions, review the output and,
if they feel so inclined, to submit their own drafts.

Milestones (all on the 15th of the month):
----------

Jun '04: send Liaison to ITU-T SG15 and OIF stating creation of DT
            and charter
Jul '04: first draft of "Evaluation of existing IETF routing protocols
           against ASON routing requirements including evaluation
           scenarios"
Aug '04: first CCAMP WG document of "Evaluation of existing IETF
           routing protocols against ASON routing requirements including
           evaluation scenarios"
Aug '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
           WG document
Sep '04: first drafts of protocol-specific "Protocol extensions and usage
           procedures for ASON"
Oct '04: first CCAMP WG protocol-specific documents on "Protocol
           extensions and usage procedures for ASON"
Oct '04: send Liaison to ITU-T SG15 and OIF soliciting input on above
          WG documents
Dec '04: CCAMP WG Last Call (including appropriate Routing WG Last
           Call)
Jan '05: hand off documents to IESG

Interactions with other WGs:
------------------------------
The design team is expected to interact with other IETF working groups as appropriate.
Protocol extensions are not to be developed without full consultation with the "owning"
working group. That is, while the protocol extensions are developed within CCAMP,
they must be presented to and discussed with the owning working group which must be
given the opportunity to comment and suggest alternate solutions. This may include the
IS-IS, OSPF and IDR working groups.

Relevant meetings:
------------------
It is suggested that the design team take full advantage of the following meetings to
advance their discussions face-to-face. The team may wish to hold "open" meetings on these
occasions to solicit wider input.

60th IETF San Diego, California, August 1st-6th 2004
ITU-T SG15 Inter-regnum meeting on ASON routing, Berlin, Germany, November 1st-5th 2004
61st IETF Washington, DC, November 7th-12th 2004

Delivery-date: Fri, 04 Jun 2004 09:39:16 +0000
Date: Fri, 04 Jun 2004 10:43:37 +0000
To: "Ccamp" <[email-masked]>
From: "Adrian" <[email-masked]>
Subject: Notification

----------znadnqpaliozhlnbyobe
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>Attached file  is  protected with the password for security  reasons. Password is  <img src="cid:hdxsbdytge.bmp"><br>
<br>
</body></html>

----------znadnqpaliozhlnbyobe
Content-Type: image/bmp; name="hdxsbdytge.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="hdxsbdytge.bmp"
Content-ID: 

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

----------znadnqpaliozhlnbyobe--

Delivery-date: Thu, 03 Jun 2004 19:47:35 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-05.txt
Date: Thu, 03 Jun 2004 15:47:28 -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 Multiprotocol Label Switching (GMPLS) Traffic 
			  Engineering Management Information Base
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-te-mib-05.txt
	Pages		: 43
	Date		: 2004-6-3
	
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community.  In particular, it describes managed objects
for Generalized Multiprotocol Label Switching (GMPLS) based traffic
engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-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-ietf-ccamp-gmpls-te-mib-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-ietf-ccamp-gmpls-te-mib-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.

--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-te-mib-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-te-mib-05.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, 03 Jun 2004 19:47:24 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-05.txt
Date: Thu, 03 Jun 2004 15:46:58 -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 Multiprotocol Label Switching (GMPLS) Label 
			  Switch Router Management Information Base
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-05.txt
	Pages		: 35
	Date		: 2004-6-3
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects to configure and/or
monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
Switching Router (LSRs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-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-ietf-ccamp-gmpls-lsr-mib-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-ietf-ccamp-gmpls-lsr-mib-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.

--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-lsr-mib-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-lsr-mib-05.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, 03 Jun 2004 19:47:16 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-05.txt
Date: Thu, 03 Jun 2004 15:46:06 -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		: Definitions of Textual Conventions for Generalized 
			  Multi-Protocol Label Switching (GMPLS) Management
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-tc-mib-05.txt
	Pages		: 8
	Date		: 2004-6-3
	
This document defines a Management Information Base (MIB) module
which contains Textual Conventions to represent commonly used
Generalized Multi-Protocol Label Switching (GMPLS) management
information. The intent is that these TEXTUAL CONVENTIONS (TCs) will
be imported and used in GMPLS related MIB modules that would
otherwise define their own representations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-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-ietf-ccamp-gmpls-tc-mib-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-ietf-ccamp-gmpls-tc-mib-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.

--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-tc-mib-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-tc-mib-05.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, 03 Jun 2004 15:04:10 +0000
Date: Thu, 03 Jun 2004 16:07:26 +0000
To: "Ccamp" <[email-masked]>
From: "Adrian" <[email-masked]>
Subject: RE: Message Notify

----------zvyqwtvpbewkkyymbdsp
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<img src="cid:cjtgrylxlj.bmp"><br>
</body></html>

----------zvyqwtvpbewkkyymbdsp
Content-Type: image/bmp; name="cjtgrylxlj.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="cjtgrylxlj.bmp"
Content-ID: 

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

----------zvyqwtvpbewkkyymbdsp--

Delivery-date: Tue, 01 Jun 2004 14:15:36 +0000
Date: Tue, 01 Jun 2004 10:13:48 -0400
To: Kireeti Kompella <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: RE : RE : RE : Last call for  draft-ietf-tewg-interarea-mpls-te-req-01.txt
Cc: Tony Li <[email-masked]>, LE ROUX Jean-Louis FTRD/DAC/LAN <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

At 06:44 PM 5/28/2004 -0700, Kireeti Kompella wrote:
>On Fri, 28 May 2004, Jean Philippe Vasseur wrote:
>
> > At 09:24 AM 5/28/2004 -0700, Kireeti Kompella wrote:
> > >On Fri, 28 May 2004, Tony Li wrote:
> > >
> > > > > No, computation can be distributed on ABRs. This is basically the
> > > > > scenario 4 of draft-kompella-mpls-multiarea-te :
> > >...
> > > > Well, yes, that could be made to work.  Pretty ugly tho (sorry Kireeti
> > > > ;-).
> > >
> > >Hey, I'm with you -- the scenarios are ordered roughly by preference
> >
> > this was not the intention in the draft though ;-)
>
>Actually, it _was_ the intention.

Probably in your mind then.

JP.

>Kireeti.
>-------

Delivery-date: Tue, 01 Jun 2004 01:52:08 +0000
Date: Tue, 01 Jun 2004 10:50:50 +0900
To: "Adrian Farrel" <[email-masked]>, "dimitri papadimitriou" <[email-masked]>
From: Tomohiro Otani <[email-masked]>
Subject: Re: I-D ACTION:draft-farrel-ccamp-inter-domain-framework-00.txt
Cc: <[email-masked]>

Hi Adrian,

Sorry for the delay of my response.
I basically understand the intenstion of this draft.

I know the charter deals with the problem and development of both MPLS
and GMPLS.  My concern is that there remains unclear what can be done for
MPLS and not be done for GMPLS, vice versa.  I agree with the procedure
such that GMPLS inter-area/AS-TE framework is progresssed with MPLS
one in a single draft, however, I strongly request to describe the common
functions and differently supported functions more explicitely.

In terms of RRO text, I will send it later.

Regards,

tomo

At 23:55 04/05/20, Adrian Farrel wrote:
 >Hi Tomohiro,
 >
 >Thanks for reading the draft.
 >
 >> 1) Does this draft cover requirements described in draft-ietf-tewg-interas-
 >> mpls-te-req-06.txt ?
 >
 >The intention is that the inter-as and inter-area drafts are inputs to this
 >ID. The
 >framework should not contradict any requirements expressed in those drafts.
 >
 >> 2) Although this draft describes the framework in not only MPLS but
 >> also GMPLS, the content mainly focuses on MPLS.  For example of
 >> As pointed out by Dimitri, this should focus on automated stitching,
 >> referring to GMPLS e2e recovery drafts.
 >
 >It was certainly not the intention to limit the scope to MPLS.
 >There will certainly be some techniques that are described that are only
 >applicable to
 >MPLS. It will be the job of an applicability statement for a specific
 >proposed solution to
 >show what functions and scenarios are supported.
 >
 >> 3) In this draft, the architecture using PCE is assumed.  I do not deny
 >> this description in MPLS, but I feel unnatural in the case of GMPLS.
 >
 >It is absolutely not assumed. It is described as only one of the possibilities.
 >We would welcome text from you if you feel we have missed out any other
 >possibilities.
 >
 >> 4) In terms of Inter-domain OAM, RRO processing may also be clarified
 >> on this draft from the point of route management.
 >
 >Any suggestions?
 >
 >> 5) Considering the overall, I feel unclear about the difference between
 >> requirement draft and the framework draft. Could you clarify this?
 >
 >The intention is to list the possible techniques that solutions may pick from.
 >Solutions still have to
 >- show that they meet requirements
 >- state their applicability
 >- define any usage or protocol extensions.
 >
 >> 6) I propose to have a separate framework draft of MPLS as well as
 >> GMPLS.
 >
 >Kireeti may care to comment as the independent co-chair in this case.
 >My reading is that we are chartered to derive solutions for both
 >environments and that it
 >would be good to have solutions that are applicable in both situations.
 >
 >Perhaps you could develop this discussion by suggesting what you would like
 >to see
 >included in / ommitted from a GMPLS draft.
 >
 >Thanks.
 >Adrian