Subject: Re: WG Consensus Call: Protection/restoration work
From: David Meyer <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 31 Dec 2002 09:35:50 -0800

Sorry for the delay...just finished studying these. 

>> A simple "yes/no/not yet"  for each will suffice.

	Yes and yes.

	Dave

>> Hi All,
>> 
>> Please comment on whether each of the following:
>> 	draft-bala-gmpls-recovery-functional-01.txt "Generalized MPLS
>> 		Recovery Functional Specification"
>> and
>> 	draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt
>> 		"Analysis of Generalized MPLS-based Recovery Mechanisms"
>> 
>> is ready to become a CCAMP WG document.  A simple "yes/no/not yet"
>> for each will suffice.  Start a new thread if you have more detailed
>> comments.
>> 
>> Thank you,
>> Kireeti.
>> 

Delivery-date: Tue, 31 Dec 2002 07:13:07 -0800
From: John Drake <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: Protection/restoration work
Date: Tue, 31 Dec 2002 07:09:05 -0800

yes and yes

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, December 23, 2002 2:43 PM
To: [email-masked]
Subject: WG Consensus Call: Protection/restoration work

Hi All,

Please comment on whether each of the following:
	draft-bala-gmpls-recovery-functional-01.txt "Generalized MPLS
		Recovery Functional Specification"
and
	draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt
		"Analysis of Generalized MPLS-based Recovery Mechanisms"

is ready to become a CCAMP WG document.  A simple "yes/no/not yet"
for each will suffice.  Start a new thread if you have more detailed
comments.

Thank you,
Kireeti.

Delivery-date: Tue, 24 Dec 2002 06:11:51 -0800
From: [email-masked]
Sensitivity: 
Subject: RE: WG Consensus Call: Protection/restoration work
To: <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>
Date: Tue, 24 Dec 2002 15:10:48 +0100

Likewise,

@+ manu

---------------

> Please comment on whether each of the following:
>     draft-bala-gmpls-recovery-functional-01.txt "Generalized MPLS
>           Recovery Functional Specification"
> and
>     draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt
>           "Analysis of Generalized MPLS-based Recovery Mechanisms"
>
> is ready to become a CCAMP WG document.  A simple "yes/no/not yet"
> for each will suffice.

I think both should become a WG doc.

Regards,
Bart.

Delivery-date: Tue, 24 Dec 2002 06:08:44 -0800
Sensitivity: 
Subject: Re: WG Consensus Call: Protection/restoration work
To: Kireeti Kompella <[email-masked]>
Cc: <[email-masked]>
From: [email-masked]
Date: Tue, 24 Dec 2002 15:08:13 +0100

>Please comment on whether each of the following:
>draft-bala-gmpls-recovery-functional-01.txt "Generalized MPLS
>Recovery Functional Specification"

yes.

>draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt
>"Analysis of Generalized MPLS-based Recovery Mechanisms"

yes.

Sven.

Delivery-date: Tue, 24 Dec 2002 06:05:53 -0800
From: [email-masked]
Sensitivity: 
Subject: RE: WG Consensus Call: Protection/restoration work
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Date: Tue, 24 Dec 2002 15:04:18 +0100

> Please comment on whether each of the following:
>     draft-bala-gmpls-recovery-functional-01.txt "Generalized MPLS
>           Recovery Functional Specification"
> and
>     draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt
>           "Analysis of Generalized MPLS-based Recovery Mechanisms"
>
> is ready to become a CCAMP WG document.  A simple "yes/no/not yet"
> for each will suffice.

I think both should become a WG doc.

Regards,
Bart.

Delivery-date: Tue, 24 Dec 2002 04:59:14 -0800
content-class: urn:content-classes:message
Subject: RE: WG Consensus Call: Protection/restoration work
Date: Tue, 24 Dec 2002 07:56:27 -0500
From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>

> Please comment on whether each of the following:
> 	draft-bala-gmpls-recovery-functional-01.txt "Generalized MPLS
> 		Recovery Functional Specification"
> and
> 	draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt
> 		"Analysis of Generalized MPLS-based Recovery Mechanisms"
>=20
> is ready to become a CCAMP WG document.  A simple "yes/no/not yet"
> for each will suffice.

Yes to both.

Jerry

Delivery-date: Mon, 23 Dec 2002 14:43:47 -0800
Date: Mon, 23 Dec 2002 14:42:37 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: <[email-masked]>
Subject: WG Consensus Call: Protection/restoration work

Hi All,

Please comment on whether each of the following:
	draft-bala-gmpls-recovery-functional-01.txt "Generalized MPLS
		Recovery Functional Specification"
and
	draft-papadimitriou-ccamp-gmpls-recovery-analysis-03.txt
		"Analysis of Generalized MPLS-based Recovery Mechanisms"

is ready to become a CCAMP WG document.  A simple "yes/no/not yet"
for each will suffice.  Start a new thread if you have more detailed
comments.

Thank you,
Kireeti.

Delivery-date: Mon, 23 Dec 2002 14:19:42 -0800
Date: Mon, 23 Dec 2002 14:16:13 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: <[email-masked]>
Subject: Note to authors

Hi,

This is a reminder (once again) to authors of Internet drafts
addressed to the CCAMP WG (although it applies to most IDs).

Please read draft-rfc-editor-rfc2223bis-03.txt carefully at least once.
Then refer to the checklist there, as well as the ID guidelines
(http://ietf.org/ietf/1id-guidelines.txt), the ID nits page
(http://ietf.org/ID-nits.html) and for good measure the RFC Editors'
policy page (http://www.rfc-editor.org/policy.html) when you make
changes to your documents.

It would be ideal if CCAMP WG documents are clean with respect to
the above.  At the very least, docs should be reasonably clean before
they go to WG Last Call.  This work has to be done before publication
in any case, but the sooner you do it, the more friends you don't lose :-)

Kireeti.

Delivery-date: Sat, 21 Dec 2002 08:26:15 -0800
Date: Sat, 21 Dec 2002 17:19:14 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Jean Philippe Vasseur <[email-masked]>, sachin laddha <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multi-Area TE Protocol Extensions

hi jean-philippe,

i re-send the below e-mail, in brief i would rather
suggest you provide a clear view on why rsvp as to 
be re-used for path query/response, but if you could
elaborate a bit more wrt to the below discussion
that wouldn't be completely useless for the ccamp
community

thanks,
- dimitri.

Dimitri Papadimitriou wrote:
> 
> hi jean-philippe,
> 
> see in-line...
> 
> Jean Philippe Vasseur wrote:
> >
> > Hi Dimitri,
> >
> > At 23:25 12/12/2002 +0100, [email-masked] wrote:
> > >your impression is too affirmative wrt to my next reply
> > >(i've never said that the xro mechanisms are restricted
> > >to ma-te or that this i-d should be entirely dedicated
> > >to it) also the intention of opening a charter item
> > >implies imho structuring the content of proposals that
> > >are on the table and that may further come in, this in
> > >order to achieve common mechanisms in the scope of the
> > >ccamp wg - in whatever i-d btw as long as it reproduces
> > >the consensus of the wg (taking a look back at gmpls
> > >signalling for instance you will see that it is the
> > >concatenation of many individual submissions coming
> > >from various horizons)
> > >
> > >as said before, we have currently two methods
> >
> > We probably have more ... we can also add some methods consisting on
> > leaking part of the topology info into the areas, ....
> 
> i referred here to the "signalling" based methods (i should
> have said before, sorry) hence, i think we should scope the
> discussion to these two here for the time being
> 
> > But I do agree with you that once the CCAMP charter explicitly includes the
> > multi-area TE item, we will need to find a consensus and work on a single
> > document.
> 
> me too
> 
> > >on the
> > >table 1) constraint passing and 2) path queries, the
> > >first beneficiate from the fact it is the logical
> > >evolution from loose routing (the next step) the other
> > >uses signalling for querying a server, as such there
> > >is one fundamental question  underlying the latter:
> > >moving features from distributed entities to the
> > >centralized ones for path computation purposes solves
> > >an intermediate problem (when a unique server is
> > >available) that comes back when several centralized
> > >systems have to interoperate
> >
> > I guess you are referring to the problem of multiple central systems
> > sharing the path computation requests that indeed need to be in sync. That
> > of course seriously increases the level of complexity but I do not think
> > this is required. In the case of multi-area TE, a determined ABR
> > (statically configured or dynamically discovered) can the THE PCS serving
> > the requests for the LSRs residing within a specific area. In case of
> > failure, a backup PCS can be used.
> 
> it is not "required" but your last sentence clearly
> indicates it will become rapidly a "recommendation"
> this clearly puts limits to the current applicability
> of this method - see also here below - and i think it
> would be wise to start thinking about scoping this
> approach (in case).
> 
> > >but also one fundamental
> > >protocol aspect (which is due to the methods currently
> > >proposed) using a signalling protocol like rsvp to
> > >explicitly query a server is clearly questionable (*)
> >
> > Well, I would be more than happy to discuss this aspect of course, but not
> > from a philosophical point of view ...
> 
> when i say questionable, i don't want to enter into the
> arcane of protocol philosophy but the protocol consistence
> & evolution - imho i think this is part of our common
> responsibility as ietf'ers - this said take this as a
> technical discussion, please (no bad intentions here)
> 
> > We have various options there:
> > (1) try to extend an existing protocol like RSVP. Note that
> > http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt
> > requires to specify only one new message type and a single additional
> > object (REQUEST-ID object). All the other objects are completely optional.
> > All the LSRs have already an RSVP stack and this allows to reuse all the
> > RSVP objects defined so far to pass the constraints to the PCS. So the idea is:
> >          - to slightly extend an existing protocol (with one new message
> > type, one new object required) without impacting its scalability,
> 
> this i-d describes in details the new messages, objects and
> their usage but i don't see any detail about how RSVP works
> in this case ? would you please go first by yourself into
> the details of what's the use of the mandatory objects in
> that context and their semantic wrt respect to their current
> use ? this would help me really to understand the rationales
> behind this method - the issue is as follows there is no
> clear explanations on why rsvp re-use is a key in enabling
> a path query between a client and a server, except from the
> fact it is already used but for resource reservation -
> 
> you've said "without impacting its scalability", first you
> should clarify from which viewpoint since due to the above
> point it is probably a method that complexifies when the
> #pcs > 1 thus i would only consider that #pcs = 1 (in a
> first approach) now, if you refer to the installed and
> running distributed rsvp-te software on the routers and
> other switches from the client side it seems the case since
> you have to maintain a session (but do i have to call it a
> session in this context ?) with one pcs and even if you have
> several sessions (?) you would at most double or triple their
> number so it is clearly limited, the problem is in the other
> way around, where you have a factor n (at least), n being
> the number of nodes; if each of these nodes maintains m flows
> (with m>>1) well the question becomes that the dimensioning
> of the number of lsp's is dependent of the capabilities of
> the pcs (thus in addition, it seems you have introduced a
> new issue in network dimensioning) imho scalability with
> respect to the pcs (in particular wrt to rsvp usage) imho
> would deserve more words in this i-d in particular when
> running on the same device than the one(s) along the lsp.
> 
> >          - re use all the existing objects,
> 
> this re-use is clearly what i refer to here, i clearly
> understand the use of the new objects but what about the
> <SESSION>, <sender_descriptor> etc. what do they represent
> in this context ?
> 
> you will see that this discussion is exactly the one that
> we would have in defining a new application, but where i
> see another point here one start to use rsvp as p2p tunnel
> to transport the info for such kind of applications
> 
> >          - not require any additional protocol running on the LSRs
> > (2) re invent a new protocol from scratch ...
> > I personally vote for the pragmatic approach (1), let see other inputs on
> > the list.
> 
> well you have really point out the two alternatives
> sitting at the both end of the solution spectrum
> 
> > I won't go in the philosophical aspects ... Note that IGPs/RSVP have not
> > been designed to carry Optical/SDH/SONET/...
> 
> well let me point out here they don't carry sdh, they
> extend the set of bandwidth request encoding (as such
> no change in the orientation of resource reservation
> of this protocol)
> 
> > infos either and I think one
> > could mention many other examples like this and as a matter of fact they
> > perfectly make the job. I personally think that if an exiting protocol can
> > be slightly extended (without impacting its scalability, ... ) and can
> > solve an actual problem, this option is preferable than trying to reinvent
> > a new protocol from scratch.
> 
> using your words:
> 
> 1) constraint-passing would be then much more pragmatic
> (since you don't have to implement one new message, only
> new objects) and this without impacting existing approaches
> 
> 2) if one has to implement a new message with new semantic
> (outside of the scope of resource reservation even in a
> generic sense) then we can legitimatelly "ask" the question
> why not a dedicated protocol for it running over udp;
> 
> and this is probably the way to go for this method use
> all the object encoding, errors and s.o. without being
> obliged to maintain backward semantic with rsvp itself
> this is what the ccamp wg did with lmp and i don't think
> this is unfeasible in this case, however i would say
> that this would solve only the easy part of the problem
> (the issue of what happens in case of multiple pcs that
> runs in parallel is still for me an open issue)
> 
> > Again I'll be more than happy to get more feed-backs on the list.
> >
> > >- i think this should be clarified in the kompella i-d
> >
> > What would you exactly want us to clarify in the i-d ?
> 
> the following paragraph says:
> " Once the path computation server computes the path, if the server is
> not along the path, the server is no longer responsible for  maintaining
> the feasibility of the path (for one thing, the server may not even know
> whether the LSR established the path in the first  place)."
> 
> the "if the server is not along the path" is not a
> condition, this applies independently of the condition
> the lsp is along the path, this should be clarified
> otherwise the above paragraph requires that you have
> to maintain the state of the computed path and the
> actual lsp on abr's for instance! but this is this
> may be what you intend to propose ? but in this case
> i don't see this clearly this i-d (is my understanding
> right here ?)
> 
> > >since this is independent from the fact that the server
> > >is collocated on an abr or along the lsp path - back
> > >to previous method using constraint passing i would
> > >say constraint-passing keeps the current philosophy
> > >of rsvp-te since based on the implicit assumption
> > >that each hop (in particular abr in ma-te context) are
> > >capable to respond to the incoming request; is the
> > >latter optimal, no of course; but i would say that at
> > >the end the "simplest solution to this complex problem
> > >will remain", well i think that rfc 3439 phrases this
> > >principle much better than i do;
> > >
> > >(*) understand this as a general remark people have
> > >the tendency to overload/over-generalize the features
> > >supported by a protocol and its applicability scope
> >
> > I am also hopping we will move forward on this discussion with the input of
> > Service Providers on which method(s) for inter-area TE better address their
> > needs.
> 
> of course, the whole ietf community is kindly invited
> to provide comments and input !
> 
> thanks,
> - dimitri.
> 
> > Thanks.
> >
> > Cheers,
> >
> > JP.
> >
> > >thanks,
> > >- dimitri.
> > >
> > >Jean Philippe Vasseur wrote:
> > > >
> > > > Hi,
> > > >
> > > > At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote:
> > > > >Dimitri, JP,
> > > > >While I think an applicability section/statement is fine, I'm not sure
> > > > >if  a mechanism
> > > > >to compute inter-area TE path belong in this  ID.
> > > >
> > > > This was exactly my impression.
> > > >
> > > > JP.
> > > >
> > > > >We did include applications in the first discussion of this ID and in the
> > > > >slides
> > > > >http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in
> > > > >addressing
> > > > >Kireeti's suggestion to include a discussion on the impact of message
> > > > >size, we provided
> > > > >an inter-area example for illustration purposes. However,  there have also
> > > > >been
> > > > >suggestions in the past to not discuss applications specifically  in the
> > > > >draft itself.
> > > > >I am fine with either way.
> > > > >
> > > > >thanks
> > > > >cheng-yin
> > > > >
> > > > >[email-masked] wrote:
> > > > >
> > > > > > jp,
> > > > > >
> > > > > > > this ID does not propose a mechanism to compute inter-area TE path
> > > > > >
> > > > > > well i would say that either none of them does it, or all of
> > > > > > them, more accurately route exclusions are applicable to any
> > > > > > mpls network where full computation of the ero is not performed
> > > > > > before the LSP is signaled, implying thus a "scope" for computed
> > > > > > path thus among other applicable to multiple areas - nevertheless
> > > > > > i agree that a next version of this i-d should probably include
> > > > > > an applicability section covering this in a bit more details (see
> > > > > > also section 4.1 for an example -
> > > > > >
> > > > > > this said and as for any other input or i-d provided on constraint-
> > > > > > passing (as well as path query, btw) lot of work is still needed to
> > > > > > achieve a decent first step in this effort;
> > > > > >
> > > > > > thanks,
> > > > > > - dimitri.
> > > > > >
> > > > > > Jean Philippe Vasseur wrote:
> > > > > > >
> > > > > > > Hi Dimitri,
> > > > > > >
> > > > > > > cc'ing CCAMP - see in line,
> > > > > > >
> > > > > > > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > > > > > > >jp,
> > > > > > > >
> > > > > > > >in fact the below list should simply be as follows for
> > > > > > > >signalling-based methods: 1) constraint-passing 2) loose
> > > > > > > >routing and 3) path query;
> > > > > > > >
> > > > > > > >and the for constraint-passing we have a several i-d's
> > > > > > > >such as,
> > > > > > > >
> > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclu
> > > de-r
> > > > > oute-01.txt
> > > > > > > >
> > > > > > >
> > > > > > > this ID does not propose a mechanism to compute inter-area TE path
> > > > > > >
> > > > > > > >constraint passing may also be extended using the crank-
> > > > > > > >back as listed below; the usage scenarios of these methods
> > > > > > > >are described in the following:
> > > > > > > >
> > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea
> > > -te-
> > > > > 03.txt
> > > > > > > >
> > > > > > > >now probably it is worth spending some time in considering
> > > > > > > >input coming from the tewg wrt to this effort, most of the
> > > > > > > >input that you see listed above has been produced over the
> > > > > > > >past year (and more) i can't imagine stepping in the protocol
> > > > > > > >details without a clear consensus on what do we want to cover
> > > > > > > >within the ccamp wg & w/o taking into account the tewg rec's
> > > > > > > >(probably better to discuss this on the ccamp mailing list)
> > > > > > >
> > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part
> > > of the
> > > > > > > CCAMP charter.
> > > > > > >
> > > > > > > JP.
> > > > > > >
> > > > > > > >thanks,
> > > > > > > >- dimitri.
> > > > > > > >
> > > > > > > >Jean Philippe Vasseur wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > > > > > > >Hi,
> > > > > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > > > > > > >"Initial requirements are given here for protocol support of the
> > > > > > > > multi-area
> > > > > > > > > >TE methods, which include needs to support
> > > > > > > > > >
> > > > > > > > > >*       path-computation-server (PCS) functionality
> > > [kompella, lee,
> > > > > > > > vasseur,
> > > > > > > > > >te-qos-routing],
> > > > > > > > > >*       query functionality [query, vasseur],
> > > > > > > > > >*       crankback functionality [crankback],
> > > > > > > > > >
> > > > > > > > > >and, optionally,
> > > > > > > > > >
> > > > > > > > > >*       TE feedback functionality [feedback], and
> > > > > > > > > >*       summary-LSA functionality [summary_lsa]."
> > > > > > > > > >.
> > > > > > > > > >I want to know whether cisco/juniper routers (standard ones)
> > > > > supports
> > > > > > > > all of
> > > > > > > > > >the above extension.
> > > > > > > > > >or if not,how many.......or Whether router is supposed to
> > > > > support how many
> > > > > > > > > >...
> > > > > > > > >
> > > > > > > > > I do not think any vendor supports all the method mentioned
> > > > > above, but just
> > > > > > > > > a subset. If you are running a network, your feed-backs on your
> > > > > preferred
> > > > > > > > > method is very welcome.
> > > > > > > > >
> > > > > > > > > JP.
> > > > > > > > >
> > > > > > > > > >Regards,
> > > > > > > > > >---Sachin
> > > > > > > >
> > > > > > > >--
> > > > > > > >Papadimitriou Dimitri
> > > > > > > >E-mail : [email-masked]
> > > > > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > > > > >E-mail : [email-masked]
> > > > > > > >Public : http://psg.com/~dpapadimitriou/
> > > > > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > > > > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> > > > > >
> > > > > > --
> > > > > > Papadimitriou Dimitri
> > > > > > E-mail : [email-masked]
> > > > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > > > E-mail : [email-masked]
> > > > > > Public : http://psg.com/~dpapadimitriou/
> > > > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > > > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> > >
> > >--
> > >Papadimitriou Dimitri
> > >E-mail : [email-masked]
> > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > >E-mail : [email-masked]
> > >Public : http://psg.com/~dpapadimitriou/
> > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> 
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 18 Dec 2002 11:45:23 -0800
Date: Wed, 18 Dec 2002 11:41:45 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: <[email-masked]>
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi All,

On Tue, 3 Dec 2002, Kireeti Kompella wrote:

> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
>
> Please indicate your opinion by replying to this email.

Thanks to all who expressed themselves on this topic.  We have
a fairly strong consensus that this work be made a WG doc.

Authors, please resubmit the doc as draft-ietf-ccamp-...  Thanks.

Kireeti.

Delivery-date: Wed, 18 Dec 2002 00:32:58 -0800
From: "Hirokazu Ishimatsu" <[email-masked]>
To: <[email-masked]>
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Wed, 18 Dec 2002 17:30:14 +0900

This ID should be a WG document. The reason why is that I believe
this ID is useful for the case:

 * an end user outsourcers most of its network to a service provider
   (there is a relatively strong trust relationship between an end user and
    a service provider),
 * but a service provider wants to hide its core network.

Simple implementation of the overlay model is enough for this case.

Hiro

> Hi,
> 
> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
> 
> Please indicate your opinion by replying to this email.
> 
> Thanks,
> Kireeti.

Delivery-date: Tue, 17 Dec 2002 22:04:50 -0800
Date: Tue, 17 Dec 2002 22:05:48 -0500
From: Matt Squire <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Here I am throwing in two cents just before the deadline.  

I think this is a useful document and should be progressed as a WG
document.  

- Matt

-----------------

Hi,

This is a call for consensus to make the above document a CCAMP WG
document.  This call will end Dec 17, 2002.

Please indicate your opinion by replying to this email.

Thanks,
Kireeti.

Envelope-to: [email-masked]
Delivery-date: Tue, 17 Dec 2002 10:08:30 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Daniel Awduche" <[email-masked]>
Subject: draft-awduche-ipo-gmpls-signaling-applicability-00.txt
Date: Tue, 17 Dec 2002 13:06:23 -0500

Please be aware the existence of this draft in the IPO WG.
The authors are starting work on the next revision.
We would appreciate your comments sent to the IPO mailing list
[email-masked]

Thanks,
Adrian

Delivery-date: Mon, 16 Dec 2002 15:28:22 -0800
Date: Mon, 16 Dec 2002 18:23:53 -0500
From: Reshad Rahman <[email-masked]>
Organization: Cisco Systems
To: Manoj Agiwal <[email-masked]>
CC: "'Ccamp (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Message ID generation

If the hop objects are being populated with a control channel (numbered) address
then I think one can either generate the message ids per control channel or have
1 "space" for the whole node. If the control channel addresses are unnumbered or
the hop objects contains a node address then there should be only 1 message id
space for the whole node.

Regards,
Reshad.

Manoj Agiwal wrote:

> Hi ,
>       These are the lines from Refresh Reduction RFC
>       " Message identification and acknowledgment is done on a per hop
> basis. All types of MESSAGE_ID objects contain a                   message
> identifier. The identifier MUST be unique on a per object generator's IP
> address basis
>        In case of Gmpls if Per object generators IP address is control
> channel address then Message ID should be unique
>        for each control channel address , or should it be unique per
> Neighbour .
>
>        i.e. If there are two control channel address in a Node that goes to
> the same neighbor in the data plane , the Message Id
>        generation should be unique per control channel address or Message Id
> generation should be unique for each neighbor .
>
> Regards ,
> Manoj

Delivery-date: Mon, 16 Dec 2002 09:17:15 -0800
From: Jonathan Lang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-02.txt
Date: Mon, 16 Dec 2002 09:14:43 -0800

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

------_=_NextPart_000_01C2A526.9FF6FF20
Content-Type: text/plain;
	charset="iso-8859-1"

Folks,

An updated version of the LMP bootstrap draft has been uploaded.

Thanks,
Jonathan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 16, 2002 7:30 AM
Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Control Channel Bootstrap for Link Management
Protocol
	Author(s)	: J. Lang, J. Drake, D. Papadimitriou
	Filename	: draft-lang-ccamp-lmp-bootstrap-02.txt
	Pages		: 9
	Date		: 2002-12-12
	
The Link Management Protocol (LMP) requires that a bi-directional 
control channel is established to form an LMP adjacency.  The 
control channel may be transmitted either in-band with the data 
links or out-of-band over a separate wavelength, fiber, or IP 
network.  This draft specifies a simple procedure to dynamically 
bootstrap LMP control channels and exchange interface mappings using 
a new LMP message that is transmitted in-band over the data links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lang-ccamp-lmp-bootstrap-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-lang-ccamp-lmp-bootstrap-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_000_01C2A526.9FF6FF20
Content-Type: message/rfc822

To: 
Subject: 
Date: Mon, 16 Dec 2002 09:14:46 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C2A526.9FF6FF20"

------_=_NextPart_002_01C2A526.9FF6FF20
Content-Type: text/plain

------_=_NextPart_002_01C2A526.9FF6FF20
Content-Type: application/octet-stream;
	name="ATT12498"
Content-Disposition: attachment;
	filename="ATT12498"

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-lang-ccamp-lmp-bootstrap-02.txt

------_=_NextPart_002_01C2A526.9FF6FF20
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-lang-ccamp-lmp-bootstrap-02.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"

------_=_NextPart_002_01C2A526.9FF6FF20--

------_=_NextPart_000_01C2A526.9FF6FF20--

Delivery-date: Sun, 15 Dec 2002 17:43:19 -0800
Date: Sun, 15 Dec 2002 17:41:05 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-ccamp-tracereq-00.txt (#1)

Hi All,

On Mon, 25 Nov 2002, Kireeti Kompella wrote:

> This begins a WG Last Call for draft-ietf-ccamp-tracereq-00.txt.
> The Last Call ends Wed, Dec 11, 2002 at 5pm EST.

WG Last Call ended a few days ago.

> Please send your comments as a reply to this email for easier
> tracking.

As no comments were received, this document will be forwarded to
the IESG for publication.

Kireeti.

Delivery-date: Sun, 15 Dec 2002 14:16:55 -0800
Date: Sun, 15 Dec 2002 16:54:57 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-wdm-01
To: [email-masked]

Folks,

This last call has ended. I will send the document to the ADs for
processing.

                                       Ron

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]
> Sent: Sunday, November 24, 2002 5:27 PM
> To: [email-masked]
> Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-wdm-01
>
>
> Folks,
>
> In order to give people time to recover from IETF travel, this
> last call has been extended to December 13, 2002.
>
>                                                    Ron
>
> > -----Original Message-----
> > From: Ron Bonica [mailto:[email-masked]]
> > Sent: Thursday, November 21, 2002 11:22 AM
> > To: [email-masked]
> > Subject: WG Last Call: draft-ietf-ccamp-lmp-wdm-01
> >
> >
> > Folks,
> >
> > This email begins a WG last call for draft-ietf-ccamp-lmp-wdm-01.
> > Last call will end at COB on December 6, 2002.
> >
> > (We will let the last call run for two weeks to accommodate folks
> > who are traveling).
> >
> > ===========================================
> > Ronald P. Bonica       Ph: 703 886 1681
> > vBNS Engineering       page: 1 888 268 8021
> > Ashburn, Va.
> > ===========================================
> > "We are not on Earth to guard a museum, but
> > to cultivate a flourishing garden of life."
> >                 -- Angelo Giuseppe Roncalli

Delivery-date: Fri, 13 Dec 2002 13:24:10 -0800
Date: 13 Dec 2002 16:22:08 -0500
From: "Cheng-Yin Lee" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked], "	 Jean Philippe Vasseur" <[email-masked]>
Cc: "sachin laddha" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multi-Area TE Protocol Extensions

JP, Dimitri,
My understanding is that ITU-T SG15 architecture/requirements do allow both a
"distributed" and "centralized" approach and that perhaps the PCS  (btw, the Path
Computation Entity is a functional element, not necessarily a device/server, hence
Path Computation Entity/Component or something not denoting device may be more
appropriate) approach may be more appropriate there.

Both approaches may have its place in networks but perhaps SG15 may be a better place
to advance the PCS/PCE approach? Just my 0.02 cents.

regards
cheng-yin

[email-masked] wrote:

> hi jean-philippe,
>
> see in-line...
>
> Jean Philippe Vasseur wrote:
> >
> > Hi Dimitri,
> >
> > At 23:25 12/12/2002 +0100, [email-masked] wrote:
> > >your impression is too affirmative wrt to my next reply
> > >(i've never said that the xro mechanisms are restricted
> > >to ma-te or that this i-d should be entirely dedicated
> > >to it) also the intention of opening a charter item
> > >implies imho structuring the content of proposals that
> > >are on the table and that may further come in, this in
> > >order to achieve common mechanisms in the scope of the
> > >ccamp wg - in whatever i-d btw as long as it reproduces
> > >the consensus of the wg (taking a look back at gmpls
> > >signalling for instance you will see that it is the
> > >concatenation of many individual submissions coming
> > >from various horizons)
> > >
> > >as said before, we have currently two methods
> >
> > We probably have more ... we can also add some methods consisting on
> > leaking part of the topology info into the areas, ....
>
> i referred here to the "signalling" based methods (i should
> have said before, sorry) hence, i think we should scope the
> discussion to these two here for the time being
>
> > But I do agree with you that once the CCAMP charter explicitly includes the
> > multi-area TE item, we will need to find a consensus and work on a single
> > document.
>
> me too
>
> > >on the
> > >table 1) constraint passing and 2) path queries, the
> > >first beneficiate from the fact it is the logical
> > >evolution from loose routing (the next step) the other
> > >uses signalling for querying a server, as such there
> > >is one fundamental question  underlying the latter:
> > >moving features from distributed entities to the
> > >centralized ones for path computation purposes solves
> > >an intermediate problem (when a unique server is
> > >available) that comes back when several centralized
> > >systems have to interoperate
> >
> > I guess you are referring to the problem of multiple central systems
> > sharing the path computation requests that indeed need to be in sync. That
> > of course seriously increases the level of complexity but I do not think
> > this is required. In the case of multi-area TE, a determined ABR
> > (statically configured or dynamically discovered) can the THE PCS serving
> > the requests for the LSRs residing within a specific area. In case of
> > failure, a backup PCS can be used.
>
> it is not "required" but your last sentence clearly
> indicates it will become rapidly a "recommendation"
> this clearly puts limits to the current applicability
> of this method - see also here below - and i think it
> would be wise to start thinking about scoping this
> approach (in case).
>
> > >but also one fundamental
> > >protocol aspect (which is due to the methods currently
> > >proposed) using a signalling protocol like rsvp to
> > >explicitly query a server is clearly questionable (*)
> >
> > Well, I would be more than happy to discuss this aspect of course, but not
> > from a philosophical point of view ...
>
> when i say questionable, i don't want to enter into the
> arcane of protocol philosophy but the protocol consistence
> & evolution - imho i think this is part of our common
> responsibility as ietf'ers - this said take this as a
> technical discussion, please (no bad intentions here)
>
> > We have various options there:
> > (1) try to extend an existing protocol like RSVP. Note that
> > http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt
> > requires to specify only one new message type and a single additional
> > object (REQUEST-ID object). All the other objects are completely optional.
> > All the LSRs have already an RSVP stack and this allows to reuse all the
> > RSVP objects defined so far to pass the constraints to the PCS. So the idea is:
> >          - to slightly extend an existing protocol (with one new message
> > type, one new object required) without impacting its scalability,
>
> this i-d describes in details the new messages, objects and
> their usage but i don't see any detail about how RSVP works
> in this case ? would you please go first by yourself into
> the details of what's the use of the mandatory objects in
> that context and their semantic wrt respect to their current
> use ? this would help me really to understand the rationales
> behind this method - the issue is as follows there is no
> clear explanations on why rsvp re-use is a key in enabling
> a path query between a client and a server, except from the
> fact it is already used but for resource reservation -
>
> you've said "without impacting its scalability", first you
> should clarify from which viewpoint since due to the above
> point it is probably a method that complexifies when the
> #pcs > 1 thus i would only consider that #pcs = 1 (in a
> first approach) now, if you refer to the installed and
> running distributed rsvp-te software on the routers and
> other switches from the client side it seems the case since
> you have to maintain a session (but do i have to call it a
> session in this context ?) with one pcs and even if you have
> several sessions (?) you would at most double or triple their
> number so it is clearly limited, the problem is in the other
> way around, where you have a factor n (at least), n being
> the number of nodes; if each of these nodes maintains m flows
> (with m>>1) well the question becomes that the dimensioning
> of the number of lsp's is dependent of the capabilities of
> the pcs (thus in addition, it seems you have introduced a
> new issue in network dimensioning) imho scalability with
> respect to the pcs (in particular wrt to rsvp usage) imho
> would deserve more words in this i-d in particular when
> running on the same device than the one(s) along the lsp.
>
> >          - re use all the existing objects,
>
> this re-use is clearly what i refer to here, i clearly
> understand the use of the new objects but what about the
> <SESSION>, <sender_descriptor> etc. what do they represent
> in this context ?
>
> you will see that this discussion is exactly the one that
> we would have in defining a new application, but where i
> see another point here one start to use rsvp as p2p tunnel
> to transport the info for such kind of applications
>
> >          - not require any additional protocol running on the LSRs
> > (2) re invent a new protocol from scratch ...
> > I personally vote for the pragmatic approach (1), let see other inputs on
> > the list.
>
> well you have really point out the two alternatives
> sitting at the both end of the solution spectrum
>
> > I won't go in the philosophical aspects ... Note that IGPs/RSVP have not
> > been designed to carry Optical/SDH/SONET/...
>
> well let me point out here they don't carry sdh, they
> extend the set of bandwidth request encoding (as such
> no change in the orientation of resource reservation
> of this protocol)
>
> > infos either and I think one
> > could mention many other examples like this and as a matter of fact they
> > perfectly make the job. I personally think that if an exiting protocol can
> > be slightly extended (without impacting its scalability, ... ) and can
> > solve an actual problem, this option is preferable than trying to reinvent
> > a new protocol from scratch.
>
> using your words:
>
> 1) constraint-passing would be then much more pragmatic
> (since you don't have to implement one new message, only
> new objects) and this without impacting existing approaches
>
> 2) if one has to implement a new message with new semantic
> (outside of the scope of resource reservation even in a
> generic sense) then we can legitimatelly "ask" the question
> why not a dedicated protocol for it running over udp;
>
> and this is probably the way to go for this method use
> all the object encoding, errors and s.o. without being
> obliged to maintain backward semantic with rsvp itself
> this is what the ccamp wg did with lmp and i don't think
> this is unfeasible in this case, however i would say
> that this would solve only the easy part of the problem
> (the issue of what happens in case of multiple pcs that
> runs in parallel is still for me an open issue)
>
> > Again I'll be more than happy to get more feed-backs on the list.
> >
> > >- i think this should be clarified in the kompella i-d
> >
> > What would you exactly want us to clarify in the i-d ?
>
> the following paragraph says:
> " Once the path computation server computes the path, if the server is
> not along the path, the server is no longer responsible for  maintaining
> the feasibility of the path (for one thing, the server may not even know
> whether the LSR established the path in the first  place)."
>
> the "if the server is not along the path" is not a
> condition, this applies independently of the condition
> the lsp is along the path, this should be clarified
> otherwise the above paragraph requires that you have
> to maintain the state of the computed path and the
> actual lsp on abr's for instance! but this is this
> may be what you intend to propose ? but in this case
> i don't see this clearly this i-d (is my understanding
> right here ?)
>
> > >since this is independent from the fact that the server
> > >is collocated on an abr or along the lsp path - back
> > >to previous method using constraint passing i would
> > >say constraint-passing keeps the current philosophy
> > >of rsvp-te since based on the implicit assumption
> > >that each hop (in particular abr in ma-te context) are
> > >capable to respond to the incoming request; is the
> > >latter optimal, no of course; but i would say that at
> > >the end the "simplest solution to this complex problem
> > >will remain", well i think that rfc 3439 phrases this
> > >principle much better than i do;
> > >
> > >(*) understand this as a general remark people have
> > >the tendency to overload/over-generalize the features
> > >supported by a protocol and its applicability scope
> >
> > I am also hopping we will move forward on this discussion with the input of
> > Service Providers on which method(s) for inter-area TE better address their
> > needs.
>
> of course, the whole ietf community is kindly invited
> to provide comments and input !
>
> thanks,
> - dimitri.
>
> > Thanks.
> >
> > Cheers,
> >
> > JP.
> >
> > >thanks,
> > >- dimitri.
> > >
> > >Jean Philippe Vasseur wrote:
> > > >
> > > > Hi,
> > > >
> > > > At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote:
> > > > >Dimitri, JP,
> > > > >While I think an applicability section/statement is fine, I'm not sure
> > > > >if  a mechanism
> > > > >to compute inter-area TE path belong in this  ID.
> > > >
> > > > This was exactly my impression.
> > > >
> > > > JP.
> > > >
> > > > >We did include applications in the first discussion of this ID and in the
> > > > >slides
> > > > >http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in
> > > > >addressing
> > > > >Kireeti's suggestion to include a discussion on the impact of message
> > > > >size, we provided
> > > > >an inter-area example for illustration purposes. However,  there have also
> > > > >been
> > > > >suggestions in the past to not discuss applications specifically  in the
> > > > >draft itself.
> > > > >I am fine with either way.
> > > > >
> > > > >thanks
> > > > >cheng-yin
> > > > >
> > > > >[email-masked] wrote:
> > > > >
> > > > > > jp,
> > > > > >
> > > > > > > this ID does not propose a mechanism to compute inter-area TE path
> > > > > >
> > > > > > well i would say that either none of them does it, or all of
> > > > > > them, more accurately route exclusions are applicable to any
> > > > > > mpls network where full computation of the ero is not performed
> > > > > > before the LSP is signaled, implying thus a "scope" for computed
> > > > > > path thus among other applicable to multiple areas - nevertheless
> > > > > > i agree that a next version of this i-d should probably include
> > > > > > an applicability section covering this in a bit more details (see
> > > > > > also section 4.1 for an example -
> > > > > >
> > > > > > this said and as for any other input or i-d provided on constraint-
> > > > > > passing (as well as path query, btw) lot of work is still needed to
> > > > > > achieve a decent first step in this effort;
> > > > > >
> > > > > > thanks,
> > > > > > - dimitri.
> > > > > >
> > > > > > Jean Philippe Vasseur wrote:
> > > > > > >
> > > > > > > Hi Dimitri,
> > > > > > >
> > > > > > > cc'ing CCAMP - see in line,
> > > > > > >
> > > > > > > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > > > > > > >jp,
> > > > > > > >
> > > > > > > >in fact the below list should simply be as follows for
> > > > > > > >signalling-based methods: 1) constraint-passing 2) loose
> > > > > > > >routing and 3) path query;
> > > > > > > >
> > > > > > > >and the for constraint-passing we have a several i-d's
> > > > > > > >such as,
> > > > > > > >
> > > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclu
> > > de-r
> > > > > oute-01.txt
> > > > > > > >
> > > > > > >
> > > > > > > this ID does not propose a mechanism to compute inter-area TE path
> > > > > > >
> > > > > > > >constraint passing may also be extended using the crank-
> > > > > > > >back as listed below; the usage scenarios of these methods
> > > > > > > >are described in the following:
> > > > > > > >
> > > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea
> > > -te-
> > > > > 03.txt
> > > > > > > >
> > > > > > > >now probably it is worth spending some time in considering
> > > > > > > >input coming from the tewg wrt to this effort, most of the
> > > > > > > >input that you see listed above has been produced over the
> > > > > > > >past year (and more) i can't imagine stepping in the protocol
> > > > > > > >details without a clear consensus on what do we want to cover
> > > > > > > >within the ccamp wg & w/o taking into account the tewg rec's
> > > > > > > >(probably better to discuss this on the ccamp mailing list)
> > > > > > >
> > > > > > > Fully agree with you. Hopefully multi-area TE should be soon part
> > > of the
> > > > > > > CCAMP charter.
> > > > > > >
> > > > > > > JP.
> > > > > > >
> > > > > > > >thanks,
> > > > > > > >- dimitri.
> > > > > > > >
> > > > > > > >Jean Philippe Vasseur wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > > > > > > >Hi,
> > > > > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > > > > > > >"Initial requirements are given here for protocol support of the
> > > > > > > > multi-area
> > > > > > > > > >TE methods, which include needs to support
> > > > > > > > > >
> > > > > > > > > >*       path-computation-server (PCS) functionality
> > > [kompella, lee,
> > > > > > > > vasseur,
> > > > > > > > > >te-qos-routing],
> > > > > > > > > >*       query functionality [query, vasseur],
> > > > > > > > > >*       crankback functionality [crankback],
> > > > > > > > > >
> > > > > > > > > >and, optionally,
> > > > > > > > > >
> > > > > > > > > >*       TE feedback functionality [feedback], and
> > > > > > > > > >*       summary-LSA functionality [summary_lsa]."
> > > > > > > > > >.
> > > > > > > > > >I want to know whether cisco/juniper routers (standard ones)
> > > > > supports
> > > > > > > > all of
> > > > > > > > > >the above extension.
> > > > > > > > > >or if not,how many.......or Whether router is supposed to
> > > > > support how many
> > > > > > > > > >...
> > > > > > > > >
> > > > > > > > > I do not think any vendor supports all the method mentioned
> > > > > above, but just
> > > > > > > > > a subset. If you are running a network, your feed-backs on your
> > > > > preferred
> > > > > > > > > method is very welcome.
> > > > > > > > >
> > > > > > > > > JP.
> > > > > > > > >
> > > > > > > > > >Regards,
> > > > > > > > > >---Sachin
> > > > > > > >
> > > > > > > >--
> > > > > > > >Papadimitriou Dimitri
> > > > > > > >E-mail : [email-masked]
> > > > > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > > > > >E-mail : [email-masked]
> > > > > > > >Public : http://psg.com/~dpapadimitriou/
> > > > > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > > > > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> > > > > >
> > > > > > --
> > > > > > Papadimitriou Dimitri
> > > > > > E-mail : [email-masked]
> > > > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > > > E-mail : [email-masked]
> > > > > > Public : http://psg.com/~dpapadimitriou/
> > > > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > > > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> > >
> > >--
> > >Papadimitriou Dimitri
> > >E-mail : [email-masked]
> > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > >E-mail : [email-masked]
> > >Public : http://psg.com/~dpapadimitriou/
> > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
>
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Envelope-to: [email-masked]
Delivery-date: Fri, 13 Dec 2002 12:07:12 -0800
Message-Id: <[email-masked]>
To: "Lazer, Monica A, ALASO" <[email-masked]>
cc: "Kireeti Kompella" <[email-masked]>, "Khuzema Pithewan" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt 
Date: Fri, 13 Dec 2002 15:06:10 -0500
From: George Swallow <[email-masked]>

Monica -

You raise some concerns, but you don't actually come out and say that
you would be opposed to this being a workgroup draft.  Are you?

...george

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Fri, 13 Dec 2002 12:06:43 -0800
Date: Fri, 13 Dec 2002 21:03:09 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Jean Philippe Vasseur <[email-masked]>
Cc: [email-masked], sachin laddha <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multi-Area TE Protocol Extensions

hi jean-philippe,

see in-line...

Jean Philippe Vasseur wrote:
> 
> Hi Dimitri,
> 
> At 23:25 12/12/2002 +0100, [email-masked] wrote:
> >your impression is too affirmative wrt to my next reply
> >(i've never said that the xro mechanisms are restricted
> >to ma-te or that this i-d should be entirely dedicated
> >to it) also the intention of opening a charter item
> >implies imho structuring the content of proposals that
> >are on the table and that may further come in, this in
> >order to achieve common mechanisms in the scope of the
> >ccamp wg - in whatever i-d btw as long as it reproduces
> >the consensus of the wg (taking a look back at gmpls
> >signalling for instance you will see that it is the
> >concatenation of many individual submissions coming
> >from various horizons)
> >
> >as said before, we have currently two methods
> 
> We probably have more ... we can also add some methods consisting on
> leaking part of the topology info into the areas, ....

i referred here to the "signalling" based methods (i should
have said before, sorry) hence, i think we should scope the
discussion to these two here for the time being

> But I do agree with you that once the CCAMP charter explicitly includes the
> multi-area TE item, we will need to find a consensus and work on a single
> document.

me too 

> >on the
> >table 1) constraint passing and 2) path queries, the
> >first beneficiate from the fact it is the logical
> >evolution from loose routing (the next step) the other
> >uses signalling for querying a server, as such there
> >is one fundamental question  underlying the latter:
> >moving features from distributed entities to the
> >centralized ones for path computation purposes solves
> >an intermediate problem (when a unique server is
> >available) that comes back when several centralized
> >systems have to interoperate
> 
> I guess you are referring to the problem of multiple central systems
> sharing the path computation requests that indeed need to be in sync. That
> of course seriously increases the level of complexity but I do not think
> this is required. In the case of multi-area TE, a determined ABR
> (statically configured or dynamically discovered) can the THE PCS serving
> the requests for the LSRs residing within a specific area. In case of
> failure, a backup PCS can be used.

it is not "required" but your last sentence clearly
indicates it will become rapidly a "recommendation"
this clearly puts limits to the current applicability 
of this method - see also here below - and i think it
would be wise to start thinking about scoping this
approach (in case).
 
> >but also one fundamental
> >protocol aspect (which is due to the methods currently
> >proposed) using a signalling protocol like rsvp to
> >explicitly query a server is clearly questionable (*)
> 
> Well, I would be more than happy to discuss this aspect of course, but not
> from a philosophical point of view ...

when i say questionable, i don't want to enter into the
arcane of protocol philosophy but the protocol consistence
& evolution - imho i think this is part of our common 
responsibility as ietf'ers - this said take this as a 
technical discussion, please (no bad intentions here) 

> We have various options there:
> (1) try to extend an existing protocol like RSVP. Note that
> http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt
> requires to specify only one new message type and a single additional
> object (REQUEST-ID object). All the other objects are completely optional.
> All the LSRs have already an RSVP stack and this allows to reuse all the
> RSVP objects defined so far to pass the constraints to the PCS. So the idea is:
>          - to slightly extend an existing protocol (with one new message
> type, one new object required) without impacting its scalability,

this i-d describes in details the new messages, objects and 
their usage but i don't see any detail about how RSVP works 
in this case ? would you please go first by yourself into 
the details of what's the use of the mandatory objects in 
that context and their semantic wrt respect to their current
use ? this would help me really to understand the rationales 
behind this method - the issue is as follows there is no
clear explanations on why rsvp re-use is a key in enabling
a path query between a client and a server, except from the
fact it is already used but for resource reservation - 

you've said "without impacting its scalability", first you 
should clarify from which viewpoint since due to the above 
point it is probably a method that complexifies when the 
#pcs > 1 thus i would only consider that #pcs = 1 (in a 
first approach) now, if you refer to the installed and 
running distributed rsvp-te software on the routers and 
other switches from the client side it seems the case since 
you have to maintain a session (but do i have to call it a 
session in this context ?) with one pcs and even if you have 
several sessions (?) you would at most double or triple their 
number so it is clearly limited, the problem is in the other 
way around, where you have a factor n (at least), n being 
the number of nodes; if each of these nodes maintains m flows 
(with m>>1) well the question becomes that the dimensioning 
of the number of lsp's is dependent of the capabilities of 
the pcs (thus in addition, it seems you have introduced a 
new issue in network dimensioning) imho scalability with
respect to the pcs (in particular wrt to rsvp usage) imho
would deserve more words in this i-d in particular when
running on the same device than the one(s) along the lsp.

>          - re use all the existing objects,

this re-use is clearly what i refer to here, i clearly 
understand the use of the new objects but what about the 
<SESSION>, <sender_descriptor> etc. what do they represent 
in this context ? 

you will see that this discussion is exactly the one that 
we would have in defining a new application, but where i 
see another point here one start to use rsvp as p2p tunnel 
to transport the info for such kind of applications

>          - not require any additional protocol running on the LSRs
> (2) re invent a new protocol from scratch ...
> I personally vote for the pragmatic approach (1), let see other inputs on
> the list.

well you have really point out the two alternatives
sitting at the both end of the solution spectrum
 
> I won't go in the philosophical aspects ... Note that IGPs/RSVP have not
> been designed to carry Optical/SDH/SONET/...  

well let me point out here they don't carry sdh, they
extend the set of bandwidth request encoding (as such
no change in the orientation of resource reservation
of this protocol)

> infos either and I think one
> could mention many other examples like this and as a matter of fact they
> perfectly make the job. I personally think that if an exiting protocol can
> be slightly extended (without impacting its scalability, ... ) and can
> solve an actual problem, this option is preferable than trying to reinvent
> a new protocol from scratch.

using your words:

1) constraint-passing would be then much more pragmatic 
(since you don't have to implement one new message, only 
new objects) and this without impacting existing approaches

2) if one has to implement a new message with new semantic
(outside of the scope of resource reservation even in a 
generic sense) then we can legitimatelly "ask" the question 
why not a dedicated protocol for it running over udp; 

and this is probably the way to go for this method use
all the object encoding, errors and s.o. without being
obliged to maintain backward semantic with rsvp itself
this is what the ccamp wg did with lmp and i don't think
this is unfeasible in this case, however i would say 
that this would solve only the easy part of the problem
(the issue of what happens in case of multiple pcs that
runs in parallel is still for me an open issue) 
 
> Again I'll be more than happy to get more feed-backs on the list.
> 
> >- i think this should be clarified in the kompella i-d
> 
> What would you exactly want us to clarify in the i-d ?

the following paragraph says:
" Once the path computation server computes the path, if the server is
not along the path, the server is no longer responsible for  maintaining
the feasibility of the path (for one thing, the server may not even know
whether the LSR established the path in the first  place)."

the "if the server is not along the path" is not a 
condition, this applies independently of the condition 
the lsp is along the path, this should be clarified
otherwise the above paragraph requires that you have
to maintain the state of the computed path and the
actual lsp on abr's for instance! but this is this  
may be what you intend to propose ? but in this case
i don't see this clearly this i-d (is my understanding
right here ?)

> >since this is independent from the fact that the server
> >is collocated on an abr or along the lsp path - back
> >to previous method using constraint passing i would
> >say constraint-passing keeps the current philosophy
> >of rsvp-te since based on the implicit assumption
> >that each hop (in particular abr in ma-te context) are
> >capable to respond to the incoming request; is the
> >latter optimal, no of course; but i would say that at
> >the end the "simplest solution to this complex problem
> >will remain", well i think that rfc 3439 phrases this
> >principle much better than i do;
> >
> >(*) understand this as a general remark people have
> >the tendency to overload/over-generalize the features
> >supported by a protocol and its applicability scope
> 
> I am also hopping we will move forward on this discussion with the input of
> Service Providers on which method(s) for inter-area TE better address their
> needs.

of course, the whole ietf community is kindly invited
to provide comments and input !

thanks,
- dimitri.
 
> Thanks.
> 
> Cheers,
> 
> JP.
> 
> >thanks,
> >- dimitri.
> >
> >Jean Philippe Vasseur wrote:
> > >
> > > Hi,
> > >
> > > At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote:
> > > >Dimitri, JP,
> > > >While I think an applicability section/statement is fine, I'm not sure
> > > >if  a mechanism
> > > >to compute inter-area TE path belong in this  ID.
> > >
> > > This was exactly my impression.
> > >
> > > JP.
> > >
> > > >We did include applications in the first discussion of this ID and in the
> > > >slides
> > > >http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in
> > > >addressing
> > > >Kireeti's suggestion to include a discussion on the impact of message
> > > >size, we provided
> > > >an inter-area example for illustration purposes. However,  there have also
> > > >been
> > > >suggestions in the past to not discuss applications specifically  in the
> > > >draft itself.
> > > >I am fine with either way.
> > > >
> > > >thanks
> > > >cheng-yin
> > > >
> > > >[email-masked] wrote:
> > > >
> > > > > jp,
> > > > >
> > > > > > this ID does not propose a mechanism to compute inter-area TE path
> > > > >
> > > > > well i would say that either none of them does it, or all of
> > > > > them, more accurately route exclusions are applicable to any
> > > > > mpls network where full computation of the ero is not performed
> > > > > before the LSP is signaled, implying thus a "scope" for computed
> > > > > path thus among other applicable to multiple areas - nevertheless
> > > > > i agree that a next version of this i-d should probably include
> > > > > an applicability section covering this in a bit more details (see
> > > > > also section 4.1 for an example -
> > > > >
> > > > > this said and as for any other input or i-d provided on constraint-
> > > > > passing (as well as path query, btw) lot of work is still needed to
> > > > > achieve a decent first step in this effort;
> > > > >
> > > > > thanks,
> > > > > - dimitri.
> > > > >
> > > > > Jean Philippe Vasseur wrote:
> > > > > >
> > > > > > Hi Dimitri,
> > > > > >
> > > > > > cc'ing CCAMP - see in line,
> > > > > >
> > > > > > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > > > > > >jp,
> > > > > > >
> > > > > > >in fact the below list should simply be as follows for
> > > > > > >signalling-based methods: 1) constraint-passing 2) loose
> > > > > > >routing and 3) path query;
> > > > > > >
> > > > > > >and the for constraint-passing we have a several i-d's
> > > > > > >such as,
> > > > > > >
> > > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclu
> > de-r
> > > > oute-01.txt
> > > > > > >
> > > > > >
> > > > > > this ID does not propose a mechanism to compute inter-area TE path
> > > > > >
> > > > > > >constraint passing may also be extended using the crank-
> > > > > > >back as listed below; the usage scenarios of these methods
> > > > > > >are described in the following:
> > > > > > >
> > > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea
> > -te-
> > > > 03.txt
> > > > > > >
> > > > > > >now probably it is worth spending some time in considering
> > > > > > >input coming from the tewg wrt to this effort, most of the
> > > > > > >input that you see listed above has been produced over the
> > > > > > >past year (and more) i can't imagine stepping in the protocol
> > > > > > >details without a clear consensus on what do we want to cover
> > > > > > >within the ccamp wg & w/o taking into account the tewg rec's
> > > > > > >(probably better to discuss this on the ccamp mailing list)
> > > > > >
> > > > > > Fully agree with you. Hopefully multi-area TE should be soon part
> > of the
> > > > > > CCAMP charter.
> > > > > >
> > > > > > JP.
> > > > > >
> > > > > > >thanks,
> > > > > > >- dimitri.
> > > > > > >
> > > > > > >Jean Philippe Vasseur wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > > > > > >Hi,
> > > > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > > > > > >"Initial requirements are given here for protocol support of the
> > > > > > > multi-area
> > > > > > > > >TE methods, which include needs to support
> > > > > > > > >
> > > > > > > > >*       path-computation-server (PCS) functionality
> > [kompella, lee,
> > > > > > > vasseur,
> > > > > > > > >te-qos-routing],
> > > > > > > > >*       query functionality [query, vasseur],
> > > > > > > > >*       crankback functionality [crankback],
> > > > > > > > >
> > > > > > > > >and, optionally,
> > > > > > > > >
> > > > > > > > >*       TE feedback functionality [feedback], and
> > > > > > > > >*       summary-LSA functionality [summary_lsa]."
> > > > > > > > >.
> > > > > > > > >I want to know whether cisco/juniper routers (standard ones)
> > > > supports
> > > > > > > all of
> > > > > > > > >the above extension.
> > > > > > > > >or if not,how many.......or Whether router is supposed to
> > > > support how many
> > > > > > > > >...
> > > > > > > >
> > > > > > > > I do not think any vendor supports all the method mentioned
> > > > above, but just
> > > > > > > > a subset. If you are running a network, your feed-backs on your
> > > > preferred
> > > > > > > > method is very welcome.
> > > > > > > >
> > > > > > > > JP.
> > > > > > > >
> > > > > > > > >Regards,
> > > > > > > > >---Sachin
> > > > > > >
> > > > > > >--
> > > > > > >Papadimitriou Dimitri
> > > > > > >E-mail : [email-masked]
> > > > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > > > >E-mail : [email-masked]
> > > > > > >Public : http://psg.com/~dpapadimitriou/
> > > > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > > > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> > > > >
> > > > > --
> > > > > Papadimitriou Dimitri
> > > > > E-mail : [email-masked]
> > > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > > E-mail : [email-masked]
> > > > > Public : http://psg.com/~dpapadimitriou/
> > > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> >
> >--
> >Papadimitriou Dimitri
> >E-mail : [email-masked]
> >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> >E-mail : [email-masked]
> >Public : http://psg.com/~dpapadimitriou/
> >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Envelope-to: [email-masked]
Delivery-date: Fri, 13 Dec 2002 12:02:57 -0800
Message-Id: <[email-masked]>
To: John Drake <[email-masked]>
cc: "'Varma, Eve L (Eve)'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked], [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt 
Date: Fri, 13 Dec 2002 15:01:24 -0500
From: George Swallow <[email-masked]>

> "It was agreed that further work related to Private-UNI/ILSI would take
> place under the auspices of UNI 2.0, and would not be a separate interface
> specification.  In particular, that services of interest be extracted from
> oif2002.540 and submitted as UNI 2.0 candidates (see candidate #19)."  
> 
> As no subsequent contributions related to possible additional services were
> submitted, candidate #19 was ultimately dropped.
> 
> Thus it is accurate to state that p-UNI/ILSI was not accepted (was rejected)
> as a separate interface specification.

I think what is more accurate to say is that those who were interested
in the Private-UNI/ILSI stopped pursing it becasue in the context of
UNI 2.0 it no longer met their customers' needs.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Envelope-to: [email-masked]
Delivery-date: Fri, 13 Dec 2002 12:01:00 -0800
Message-Id: <[email-masked]>
To: Stephen Trowbridge <[email-masked]>
cc: John Drake <[email-masked]>, "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked], [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt 
Date: Fri, 13 Dec 2002 14:55:11 -0500
From: George Swallow <[email-masked]>

> Let's see, a carrier wants interface A.
>
> A vendor proposes to standardize another interface B which is similar, but
> doesn't quite solve all the same problems as A, and tells the carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface A and interface
> B are both standardized, and if (the/some) carrier(s) want interface A and
> (many/most) vendors choose to build only interface B, then the carriers
> don't get what they want.

If the OIF UNI meets the carrier's requirements, then all the carriers
will ask for it and those who want to sell into that market will build
it.

> This fear is what makes people reluctant to progress work on an interface
> they don't feel is useful for them.

I'm getting requests from other markets (mostly research) that want
something that interfaces with GMPLS is a more direct way.  Are you
saying they can't ahve what they want?  They have to use the thing
that the OIF developed?

Note that the OIF membership represents only a small segment of the
IETF participants.  There are other people in the world!  They do have
other needs.  I want to satisfy all comers.

On the other hand they do represent a very large part (I would guess
the majority) of the market.  I do not think that the
overlay adequately addresses all of the requirements addressed by UNI
1.0.  I do not think they should or would be forced into using some
other interface.  Anyone who wants to address this segment of the
market would be foolish not to build UNI 1.0.  

I really think this is all FUD!

> The idea of standards is surely to promote the deployment of interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the same" problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.

The OIF UNI took GMPLS signalling, added some stuff, and made some
other stuff illeagal.   All of the changes were to meet carrier
requirements on how they wanted to manage and interface which was at
"arms distance".  

The overlay draft is not new protocol!  It is GMPLS signalling with a
few relatively minor changes.  I will have one protocol engine and a
few protocol knobs.  By the way we use the same protocol engine for
UNI 1.0 as well.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Fri, 13 Dec 2002 10:21:37 -0800
Date: Fri, 13 Dec 2002 10:19:09 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Hamid Ould-Brahim <[email-masked]>
cc: <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi Hamid,

On Fri, 13 Dec 2002, Hamid Ould-Brahim wrote:

> It seems there are two components in this discussion:
>
> a) Progress a draft that describes from procedure point of view
>    how GMPLS protocols as defined in ietf can be used to build
>    an overlay model, and by the same token correct a misperception
>    that GMPLS can only be used for a peer model.
>
> b) The relationship of the overlay draft to the OIF-UNI
>    spec.

<snipped>

> I think b) should not stop a) from progressing since it is
> natural to describe how GMPlS protocols can be used to provide
> an overlay deployment scenario regardless of OIF-UNI discussions
> (this doesn't mean b) should not be discussed...).

Excellent summary.

Kireeti.

Delivery-date: Fri, 13 Dec 2002 08:22:22 -0800
Date: Fri, 13 Dec 2002 11:19:36 -0500
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Multi-Area TE Protocol Extensions
Cc: [email-masked], sachin laddha <[email-masked]>, [email-masked], [email-masked]

Hi Dimitri,

At 23:25 12/12/2002 +0100, [email-masked] wrote:
>your impression is too affirmative wrt to my next reply
>(i've never said that the xro mechanisms are restricted
>to ma-te or that this i-d should be entirely dedicated
>to it) also the intention of opening a charter item
>implies imho structuring the content of proposals that
>are on the table and that may further come in, this in
>order to achieve common mechanisms in the scope of the
>ccamp wg - in whatever i-d btw as long as it reproduces
>the consensus of the wg (taking a look back at gmpls
>signalling for instance you will see that it is the
>concatenation of many individual submissions coming
>from various horizons)
>
>as said before, we have currently two methods

We probably have more ... we can also add some methods consisting on 
leaking part of the topology info into the areas, ....
But I do agree with you that once the CCAMP charter explicitly includes the 
multi-area TE item, we will need to find a consensus and work on a single 
document.

>on the
>table 1) constraint passing and 2) path queries, the
>first beneficiate from the fact it is the logical
>evolution from loose routing (the next step) the other
>uses signalling for querying a server, as such there
>is one fundamental question  underlying the latter:
>moving features from distributed entities to the
>centralized ones for path computation purposes solves
>an intermediate problem (when a unique server is
>available) that comes back when several centralized
>systems have to interoperate

I guess you are referring to the problem of multiple central systems 
sharing the path computation requests that indeed need to be in sync. That 
of course seriously increases the level of complexity but I do not think 
this is required. In the case of multi-area TE, a determined ABR 
(statically configured or dynamically discovered) can the THE PCS serving 
the requests for the LSRs residing within a specific area. In case of 
failure, a backup PCS can be used.

>but also one fundamental
>protocol aspect (which is due to the methods currently
>proposed) using a signalling protocol like rsvp to
>explicitly query a server is clearly questionable (*)

Well, I would be more than happy to discuss this aspect of course, but not 
from a philosophical point of view ...
We have various options there:
(1) try to extend an existing protocol like RSVP. Note that 
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt 
requires to specify only one new message type and a single additional 
object (REQUEST-ID object). All the other objects are completely optional. 
All the LSRs have already an RSVP stack and this allows to reuse all the 
RSVP objects defined so far to pass the constraints to the PCS. So the idea is:
         - to slightly extend an existing protocol (with one new message 
type, one new object required) without impacting its scalability,
         - re use all the existing objects,
         - not require any additional protocol running on the LSRs
(2) re invent a new protocol from scratch ...
I personally vote for the pragmatic approach (1), let see other inputs on 
the list.

I won't go in the philosophical aspects ... Note that IGPs/RSVP have not 
been designed to carry Optical/SDH/SONET/...  infos either and I think one 
could mention many other examples like this and as a matter of fact they 
perfectly make the job. I personally think that if an exiting protocol can 
be slightly extended (without impacting its scalability, ... ) and can 
solve an actual problem, this option is preferable than trying to reinvent 
a new protocol from scratch.

Again I'll be more than happy to get more feed-backs on the list.

>- i think this should be clarified in the kompella i-d

What would you exactly want us to clarify in the i-d ?

>
>since this is independent from the fact that the server
>is collocated on an abr or along the lsp path - back
>to previous method using constraint passing i would
>say constraint-passing keeps the current philosophy
>of rsvp-te since based on the implicit assumption
>that each hop (in particular abr in ma-te context) are
>capable to respond to the incoming request; is the
>latter optimal, no of course; but i would say that at
>the end the "simplest solution to this complex problem
>will remain", well i think that rfc 3439 phrases this
>principle much better than i do;
>
>(*) understand this as a general remark people have
>the tendency to overload/over-generalize the features
>supported by a protocol and its applicability scope

I am also hopping we will move forward on this discussion with the input of 
Service Providers on which method(s) for inter-area TE better address their 
needs.

Thanks.

Cheers,

JP.

>thanks,
>- dimitri.
>
>Jean Philippe Vasseur wrote:
> >
> > Hi,
> >
> > At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote:
> > >Dimitri, JP,
> > >While I think an applicability section/statement is fine, I'm not sure
> > >if  a mechanism
> > >to compute inter-area TE path belong in this  ID.
> >
> > This was exactly my impression.
> >
> > JP.
> >
> > >We did include applications in the first discussion of this ID and in the
> > >slides
> > >http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in
> > >addressing
> > >Kireeti's suggestion to include a discussion on the impact of message
> > >size, we provided
> > >an inter-area example for illustration purposes. However,  there have also
> > >been
> > >suggestions in the past to not discuss applications specifically  in the
> > >draft itself.
> > >I am fine with either way.
> > >
> > >thanks
> > >cheng-yin
> > >
> > >[email-masked] wrote:
> > >
> > > > jp,
> > > >
> > > > > this ID does not propose a mechanism to compute inter-area TE path
> > > >
> > > > well i would say that either none of them does it, or all of
> > > > them, more accurately route exclusions are applicable to any
> > > > mpls network where full computation of the ero is not performed
> > > > before the LSP is signaled, implying thus a "scope" for computed
> > > > path thus among other applicable to multiple areas - nevertheless
> > > > i agree that a next version of this i-d should probably include
> > > > an applicability section covering this in a bit more details (see
> > > > also section 4.1 for an example -
> > > >
> > > > this said and as for any other input or i-d provided on constraint-
> > > > passing (as well as path query, btw) lot of work is still needed to
> > > > achieve a decent first step in this effort;
> > > >
> > > > thanks,
> > > > - dimitri.
> > > >
> > > > Jean Philippe Vasseur wrote:
> > > > >
> > > > > Hi Dimitri,
> > > > >
> > > > > cc'ing CCAMP - see in line,
> > > > >
> > > > > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > > > > >jp,
> > > > > >
> > > > > >in fact the below list should simply be as follows for
> > > > > >signalling-based methods: 1) constraint-passing 2) loose
> > > > > >routing and 3) path query;
> > > > > >
> > > > > >and the for constraint-passing we have a several i-d's
> > > > > >such as,
> > > > > >
> > > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclu 
> de-r
> > > oute-01.txt
> > > > > >
> > > > >
> > > > > this ID does not propose a mechanism to compute inter-area TE path
> > > > >
> > > > > >constraint passing may also be extended using the crank-
> > > > > >back as listed below; the usage scenarios of these methods
> > > > > >are described in the following:
> > > > > >
> > > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea 
> -te-
> > > 03.txt
> > > > > >
> > > > > >now probably it is worth spending some time in considering
> > > > > >input coming from the tewg wrt to this effort, most of the
> > > > > >input that you see listed above has been produced over the
> > > > > >past year (and more) i can't imagine stepping in the protocol
> > > > > >details without a clear consensus on what do we want to cover
> > > > > >within the ccamp wg & w/o taking into account the tewg rec's
> > > > > >(probably better to discuss this on the ccamp mailing list)
> > > > >
> > > > > Fully agree with you. Hopefully multi-area TE should be soon part 
> of the
> > > > > CCAMP charter.
> > > > >
> > > > > JP.
> > > > >
> > > > > >thanks,
> > > > > >- dimitri.
> > > > > >
> > > > > >Jean Philippe Vasseur wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > > > > >Hi,
> > > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > > > > >"Initial requirements are given here for protocol support of the
> > > > > > multi-area
> > > > > > > >TE methods, which include needs to support
> > > > > > > >
> > > > > > > >*       path-computation-server (PCS) functionality 
> [kompella, lee,
> > > > > > vasseur,
> > > > > > > >te-qos-routing],
> > > > > > > >*       query functionality [query, vasseur],
> > > > > > > >*       crankback functionality [crankback],
> > > > > > > >
> > > > > > > >and, optionally,
> > > > > > > >
> > > > > > > >*       TE feedback functionality [feedback], and
> > > > > > > >*       summary-LSA functionality [summary_lsa]."
> > > > > > > >.
> > > > > > > >I want to know whether cisco/juniper routers (standard ones)
> > > supports
> > > > > > all of
> > > > > > > >the above extension.
> > > > > > > >or if not,how many.......or Whether router is supposed to
> > > support how many
> > > > > > > >...
> > > > > > >
> > > > > > > I do not think any vendor supports all the method mentioned
> > > above, but just
> > > > > > > a subset. If you are running a network, your feed-backs on your
> > > preferred
> > > > > > > method is very welcome.
> > > > > > >
> > > > > > > JP.
> > > > > > >
> > > > > > > >Regards,
> > > > > > > >---Sachin
> > > > > >
> > > > > >--
> > > > > >Papadimitriou Dimitri
> > > > > >E-mail : [email-masked]
> > > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > > >E-mail : [email-masked]
> > > > > >Public : http://psg.com/~dpapadimitriou/
> > > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> > > >
> > > > --
> > > > Papadimitriou Dimitri
> > > > E-mail : [email-masked]
> > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > E-mail : [email-masked]
> > > > Public : http://psg.com/~dpapadimitriou/
> > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
>
>--
>Papadimitriou Dimitri
>E-mail : [email-masked]
>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
>E-mail : [email-masked]
>Public : http://psg.com/~dpapadimitriou/
>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Fri, 13 Dec 2002 08:02:35 -0800
From: "Hamid Ould-Brahim" <[email-masked]>
To: "Amy Wang" <[email-masked]>, "Ong, Lyndon" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Fri, 13 Dec 2002 10:51:58 -0500

It seems there are two components in this discussion:

a) Progress a draft that describes from procedure point of view 
   how GMPLS protocols as defined in ietf can be used to build 
   an overlay model, and by the same token correct a misperception 
   that GMPLS can only be used for a peer model.

b) The relationship of the overlay draft to the OIF-UNI
   spec. So far I saw four proposals

    1- Explain in the overlay draft the difference between
       this draft and OIF-UNI

    2- Submit the OIF-UNI as an internet-draft and discuss
       it side by side with the overlay draft.

    3- Leave OIF-UNI for OIF (since it was developed in that
       context) and just move on with the overaly draft in 
       the IETF.
  
    4- "DeUni-nize" OIF-UNI to make it look like overlay draft
       (I suppose this is not an option but anyway... ;-))

I think b) should not stop a) from progressing since it is
natural to describe how GMPlS protocols can be used to provide
an overlay deployment scenario regardless of OIF-UNI discussions
(this doesn't mean b) should not be discussed...).
 
Hamid.
 
> 
> 
> I agree.
> 
> Amy Wang
> 
> "Ong, Lyndon" wrote:
> 
> > Hi Folks,
> >
> > Although there is obviously a lot of interest in
> > the overlay draft, there is also a lot of debate
> > about its relationship to the OIF UNI specification.
> >
> > Since the UNI is already out, can the overlay
> > draft be enhanced with some wording that explains
> > fairly clearly how it differs from the UNI?
> > This could help clear up the issue and avoid
> > future repeats of the discussion.
> >
> > BTW, it's a bit late but I withdraw my comment on
> > the voting in Atlanta, others clearly had a better
> > count than I did!
> >
> > Cheers,
> >
> > Lyndon Ong
> 
> 
> 

Delivery-date: Fri, 13 Dec 2002 06:36:54 -0800
Date: Fri, 13 Dec 2002 09:33:56 -0500
From: Amy Wang <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
CC: [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

I agree.

Amy Wang

"Ong, Lyndon" wrote:

> Hi Folks,
>
> Although there is obviously a lot of interest in
> the overlay draft, there is also a lot of debate
> about its relationship to the OIF UNI specification.
>
> Since the UNI is already out, can the overlay
> draft be enhanced with some wording that explains
> fairly clearly how it differs from the UNI?
> This could help clear up the issue and avoid
> future repeats of the discussion.
>
> BTW, it's a bit late but I withdraw my comment on
> the voting in Atlanta, others clearly had a better
> count than I did!
>
> Cheers,
>
> Lyndon Ong

Delivery-date: Fri, 13 Dec 2002 06:14:10 -0800
From: John Drake <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Fri, 13 Dec 2002 06:12:18 -0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, December 13, 2002 2:28 AM
To: John Drake; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John a small observation:
-	I thought IETF worked on the basis of views from individuals not
those of companies?  So if X from company A says one thing its seems that Y
from the same company A can say something else.  So perhaps you should not
draw these conclusions.

JD:  I think I made the point that individuals from the same company
had different opinions.  I'm not sure what conclusions you think I'm
drawing.

-	I count (only) 3 operators responding.  There are a few more
operators out there than that.  So what does this tell us?  Perhaps:
	* they want something else?
	* they don't even care about the stuff being done here (for whatever
reasons, eg no money at the moment, not right time, they are all asleep,
they go elsewhere for their stds, etc)?

JD:  Probably all of the above.

BTW - I note in a later mail you say this draft 'is not for carriers anyway'
(so who is it for?).  However, given that those who you quote support it are
from carriers, and that you seem to be drawing the conclusion that they
represent the views of their company, then have you not got a conflict of
(your own) logic?.  I await my turn to be chastised ;-)

JD:  I think I said not necessarily for carriers.  I was citing the support
of individuals who happen to work for carriers in the context of an blanket
assertion that carriers don't want the Swallow draft.  In this venue that is
the only evidence available.

regards, Neil
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: 12 December 2002 18:00
> To: 'Stephen Trowbridge'
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my 
> e-mail discussing
> this topic, to wit:
> 
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and 
> Jean-Louis
> Le Roux (12/3)."
> 
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group 
> draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> > 
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and 
> managing the
> > network.
> > 
> > JD:  No one is forcing you to supporting this interface, 
> except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 
> e-mail, if you
> > don't think this interface is useful for you, please ignore 
> it, but don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is 
> similar, but
> doesn't quite solve all the same problems as A, and tells the 
> carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface 
> A and interface
> B are both standardized, and if (the/some) carrier(s) want 
> interface A and
> (many/most) vendors choose to build only interface B, then 
> the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on 
> an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of 
> interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the 
> same" problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve
> 
> 

Delivery-date: Fri, 13 Dec 2002 05:36:02 -0800
Content-Class: urn:content-classes:message
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Fri, 13 Dec 2002 13:37:19 -0000
From: "Jorge Pinto" <[email-masked]>
To: <[email-masked]>

I support making this a WG document.

Jorge Pinto

Delivery-date: Fri, 13 Dec 2002 03:38:43 -0800
Date: Fri, 13 Dec 2002 12:34:41 +0100
From: Marcus Brunner <[email-masked]>
Reply-To: [email-masked]
To: Adrian Farrel <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: GMPLS-LSR-MIB

Adrian,

We are currently lloking into the issue of bi-directional LSPs, and we are 
not sure who the MIB is envisioned to work for that case.

In Section 7:
"A single entry in the mplsXCIndex is shared by all of the
   segments for the entire bidirectional LSP. "

Do you mean there will be two XCtable entries produced for a bi-directional 
unicast LSP, where the XCIndex is kept the same for both entries?

The wording "A single entry .." is confusing, probably it should say a 
single value of the mplsXCIndex

Marcus

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
personal home page: http://www.brubers.org/marcus

Delivery-date: Fri, 13 Dec 2002 02:31:08 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Fri, 13 Dec 2002 10:28:02 -0000

John a small observation:
-	I thought IETF worked on the basis of views from individuals not
those of companies?  So if X from company A says one thing its seems that Y
from the same company A can say something else.  So perhaps you should not
draw these conclusions.
-	I count (only) 3 operators responding.  There are a few more
operators out there than that.  So what does this tell us?  Perhaps:
	* they want something else?
	* they don't even care about the stuff being done here (for whatever
reasons, eg no money at the moment, not right time, they are all asleep,
they go elsewhere for their stds, etc)?

BTW - I note in a later mail you say this draft 'is not for carriers anyway'
(so who is it for?).  However, given that those who you quote support it are
from carriers, and that you seem to be drawing the conclusion that they
represent the views of their company, then have you not got a conflict of
(your own) logic?.  I await my turn to be chastised ;-)

regards, Neil
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: 12 December 2002 18:00
> To: 'Stephen Trowbridge'
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my 
> e-mail discussing
> this topic, to wit:
> 
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and 
> Jean-Louis
> Le Roux (12/3)."
> 
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group 
> draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> > 
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and 
> managing the
> > network.
> > 
> > JD:  No one is forcing you to supporting this interface, 
> except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 
> e-mail, if you
> > don't think this interface is useful for you, please ignore 
> it, but don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is 
> similar, but
> doesn't quite solve all the same problems as A, and tells the 
> carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface 
> A and interface
> B are both standardized, and if (the/some) carrier(s) want 
> interface A and
> (many/most) vendors choose to build only interface B, then 
> the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on 
> an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of 
> interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the 
> same" problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve
> 
> 

Delivery-date: Thu, 12 Dec 2002 15:17:19 -0800
Date: Fri, 13 Dec 2002 00:16:13 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: "Varma, Eve L (Eve)" <[email-masked]>
Cc: John Drake <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

hi, to be cristal clear the problem is that what you 
indicate here below is the consequence of a decision
* consequence, which is a triviality by the way ie "if 
you don't have 2 solutions, you have a unique solution".

the decision was clearly related to the following issue
at the oif: how do i interoperate between rsvp-te and 
pnni at the signalling level and nsap vs ip end-point 
identification at the data plane level; the main issue 
is that *none* of the mechanisms currently defined or
considered by the oif gives a clear answer to these 
issues - but as said by bala, this proposal focuses on
rsvp signalling (ie no need for looking at interop 
issues with other signalling protocols *outside of
the box*) and uses ip/unnumbered for data plane only

thus your global statement is not valid with respect 
to its applicability scope

thanks,
- dimitri.

"Varma, Eve L (Eve)" wrote:
> 
> Hi John,
> 
> I don't want to go too many rounds on what was, after all, an
> OIF discussion.  However, there was a fairly sustained effort to
> establish p-UNI as a separate interface specification from
> several of our colleagues in the OIF.  It was however, decided, that it
> would NOT become a separate interface specification and the
> proposal to do otherwise was not accepted.  That is an accurate statement.
> 
> Best regards,
> Eve
> 
> 
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 3:42 PM
> To: 'Varma, Eve L (Eve)'; 'Stephen Trowbridge'
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
>
> Let me try again.
> 
> I think it is a leap of faith to go from what the minutes say:
> 
> "It was agreed that further work related to Private-UNI/ILSI would take
> place under the auspices of UNI 2.0, and would not be a separate interface
> specification.  In particular, that services of interest be extracted from
> oif2002.540 and submitted as UNI 2.0 candidates (see candidate #19)."
> 
> to your interpretation of what the minutes say:
> 
> "Thus it is accurate to state that p-UNI/ILSI was not accepted (was
> rejected) as a separate interface specification."
> 
> -----Original Message-----
> From: Varma, Eve L (Eve) [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 12:34 PM
> To: John Drake; 'Stephen Trowbridge'
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> Hi John,
> 
> In fact, it was agreed within the OIF that the p-UNI/ILSI would not
> become a separate interface specification.  If you refer to the OIF minutes
> in
> OIF2002.269.4, you will see the statement:
> 
> "It was agreed that further work related to Private-UNI/ILSI would take
> place under the auspices of UNI 2.0, and would not be a separate interface
> specification.  In particular, that services of interest be extracted from
> oif2002.540 and submitted as UNI 2.0 candidates (see candidate #19)."
> 
> As no subsequent contributions related to possible additional services were
> submitted, candidate #19 was ultimately dropped.
> 
> Thus it is accurate to state that p-UNI/ILSI was not accepted (was rejected)
> as a separate interface specification.
> 
> Best regards,
> Eve
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 3:10 PM
> To: 'Stephen Trowbridge'
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> I just noticed in this:  "Interface B (P-UNI/ILSI rejected by OIF,
> draft-swallow-gmpls-overlay-00.txt
> currently under consideration for WG status by ccamp)" the sly phrase
> characterization "rejected by OIF".
> 
> In point of fact, it was not rejected by the OIF.  This is the type of
> misinformation that I think Kireeti was talking about in an earlier e-mail.
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 11:08 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> I think that the diversity of opinions indicates a couple of issues
> that are still open for debate.
> 
> There are two proposed interfaces:
> Interface A (using my terminology from the last email): OIF-UNI
> Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
>   currently under consideration for WG status by ccamp)
> 
> I think there are carriers who want interface A who fear that standardizing
> interface B reduces their chance of getting A. Some work needs to go into
> alleviating that fear. One way is to get rid of interface B. Another might
> be to make it clear that vendors still intend to provide interface A
> instead of using interface B as a way to shortcut things and avoid giving
> (certain) carriers what they really want. For example, just because
> Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
> users who really want it from buying Office-XP "Professional".
> 
> Another issue: are A and B different enough to be worth having two
> standardized
> interfaces? Are the shortcuts in B worth introducing interworking issues
> (will these ever be in the same network, e.g., at the enterprise/operator
> boundary?) and having to deal with those in the standards. Analyzing this
> is probably tricky with documents written in different styles produced by
> different organizations. Maybe we need to bring interface A (the OIF-UNI
> functionality) in as an Internet Draft so they can be looked at side by
> side.
> 
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Stephen,
> >
> > I couldn't help but notice that you snipped the part of my e-mail
> discussing
> > this topic, to wit:
> >
> > "JD:  If you're planning to assume the role of arbiter for the whole
> > industry, please review the e-mails all of who support accepting the
> > draft as a CCAMP WG document.  In particular I'd review the e-mails of
> > some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> > of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> > Le Roux (12/3)."
> >
> > The four individuals I explicitly mentioned work for carriers and the
> > e-mails I mentioned
> > all speak in favor of making the the draft a working group draft.  Also, a
> > representative
> > from another carrier is a co-author.  And lest we forget, two of the
> > individuals work for
> > the same carrier that Monica works for.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Thursday, December 12, 2002 9:41 AM
> > To: John Drake
> > Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> > [email-masked]
> > Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> >
> > John,
> >
> > John Drake wrote:
> > (snipped)
> > > Snipped...
> > >
> > > >From a carrier perspective, supporting a third UNI alternative will
> > > bring additional concerns regarding interoperability and managing the
> > > network.
> > >
> > > JD:  No one is forcing you to supporting this interface, except perhaps
> > > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > > don't think this interface is useful for you, please ignore it, but
> don't
> > > assume that it is not useful for others.
> >
> > Let's see, a carrier wants interface A.
> >
> > A vendor proposes to standardize another interface B which is similar, but
> > doesn't quite solve all the same problems as A, and tells the carrier "If
> > you don't like B you don't have to use it".
> >
> > It seems to me that the carrier concern is that if interface A and
> interface
> > B are both standardized, and if (the/some) carrier(s) want interface A and
> > (many/most) vendors choose to build only interface B, then the carriers
> > don't get what they want.
> >
> > This fear is what makes people reluctant to progress work on an interface
> > they don't feel is useful for them.
> >
> > The idea of standards is surely to promote the deployment of interoperable
> > implementations, but part of accomplishing this is to try to limit the
> > number of "standardized" solutions to the same problem.
> > I think the next debate would be what we really mean by "the same"
> problem.
> > Some arguments have appeared that this interface is directed at a
> > different problem, so I have to ask whether it is different enough
> > to justify standardizing a different solution.
> > Regards,
> > Steve

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Thu, 12 Dec 2002 14:26:51 -0800
Date: Thu, 12 Dec 2002 23:25:16 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Jean Philippe Vasseur <[email-masked]>
Cc: [email-masked], sachin laddha <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multi-Area TE Protocol Extensions

your impression is too affirmative wrt to my next reply
(i've never said that the xro mechanisms are restricted 
to ma-te or that this i-d should be entirely dedicated 
to it) also the intention of opening a charter item 
implies imho structuring the content of proposals that 
are on the table and that may further come in, this in
order to achieve common mechanisms in the scope of the 
ccamp wg - in whatever i-d btw as long as it reproduces
the consensus of the wg (taking a look back at gmpls
signalling for instance you will see that it is the 
concatenation of many individual submissions coming
from various horizons) 

as said before, we have currently two methods on the 
table 1) constraint passing and 2) path queries, the
first beneficiate from the fact it is the logical 
evolution from loose routing (the next step) the other
uses signalling for querying a server, as such there
is one fundamental question  underlying the latter:
moving features from distributed entities to the
centralized ones for path computation purposes solves 
an intermediate problem (when a unique server is
available) that comes back when several centralized 
systems have to interoperate but also one fundamental
protocol aspect (which is due to the methods currently 
proposed) using a signalling protocol like rsvp to 
explicitly query a server is clearly questionable (*)
- i think this should be clarified in the kompella i-d  
since this is independent from the fact that the server
is collocated on an abr or along the lsp path - back 
to previous method using constraint passing i would 
say constraint-passing keeps the current philosophy 
of rsvp-te since based on the implicit assumption 
that each hop (in particular abr in ma-te context) are 
capable to respond to the incoming request; is the 
latter optimal, no of course; but i would say that at 
the end the "simplest solution to this complex problem
will remain", well i think that rfc 3439 phrases this 
principle much better than i do; 

(*) understand this as a general remark people have
the tendency to overload/over-generalize the features 
supported by a protocol and its applicability scope

thanks,
- dimitri.

Jean Philippe Vasseur wrote:
> 
> Hi,
> 
> At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote:
> >Dimitri, JP,
> >While I think an applicability section/statement is fine, I'm not sure
> >if  a mechanism
> >to compute inter-area TE path belong in this  ID.
> 
> This was exactly my impression.
> 
> JP.
> 
> >We did include applications in the first discussion of this ID and in the
> >slides
> >http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in
> >addressing
> >Kireeti's suggestion to include a discussion on the impact of message
> >size, we provided
> >an inter-area example for illustration purposes. However,  there have also
> >been
> >suggestions in the past to not discuss applications specifically  in the
> >draft itself.
> >I am fine with either way.
> >
> >thanks
> >cheng-yin
> >
> >[email-masked] wrote:
> >
> > > jp,
> > >
> > > > this ID does not propose a mechanism to compute inter-area TE path
> > >
> > > well i would say that either none of them does it, or all of
> > > them, more accurately route exclusions are applicable to any
> > > mpls network where full computation of the ero is not performed
> > > before the LSP is signaled, implying thus a "scope" for computed
> > > path thus among other applicable to multiple areas - nevertheless
> > > i agree that a next version of this i-d should probably include
> > > an applicability section covering this in a bit more details (see
> > > also section 4.1 for an example -
> > >
> > > this said and as for any other input or i-d provided on constraint-
> > > passing (as well as path query, btw) lot of work is still needed to
> > > achieve a decent first step in this effort;
> > >
> > > thanks,
> > > - dimitri.
> > >
> > > Jean Philippe Vasseur wrote:
> > > >
> > > > Hi Dimitri,
> > > >
> > > > cc'ing CCAMP - see in line,
> > > >
> > > > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > > > >jp,
> > > > >
> > > > >in fact the below list should simply be as follows for
> > > > >signalling-based methods: 1) constraint-passing 2) loose
> > > > >routing and 3) path query;
> > > > >
> > > > >and the for constraint-passing we have a several i-d's
> > > > >such as,
> > > > >
> > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-r
> > oute-01.txt
> > > > >
> > > >
> > > > this ID does not propose a mechanism to compute inter-area TE path
> > > >
> > > > >constraint passing may also be extended using the crank-
> > > > >back as listed below; the usage scenarios of these methods
> > > > >are described in the following:
> > > > >
> > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-
> > 03.txt
> > > > >
> > > > >now probably it is worth spending some time in considering
> > > > >input coming from the tewg wrt to this effort, most of the
> > > > >input that you see listed above has been produced over the
> > > > >past year (and more) i can't imagine stepping in the protocol
> > > > >details without a clear consensus on what do we want to cover
> > > > >within the ccamp wg & w/o taking into account the tewg rec's
> > > > >(probably better to discuss this on the ccamp mailing list)
> > > >
> > > > Fully agree with you. Hopefully multi-area TE should be soon part of the
> > > > CCAMP charter.
> > > >
> > > > JP.
> > > >
> > > > >thanks,
> > > > >- dimitri.
> > > > >
> > > > >Jean Philippe Vasseur wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > > > >Hi,
> > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > > > >"Initial requirements are given here for protocol support of the
> > > > > multi-area
> > > > > > >TE methods, which include needs to support
> > > > > > >
> > > > > > >*       path-computation-server (PCS) functionality [kompella, lee,
> > > > > vasseur,
> > > > > > >te-qos-routing],
> > > > > > >*       query functionality [query, vasseur],
> > > > > > >*       crankback functionality [crankback],
> > > > > > >
> > > > > > >and, optionally,
> > > > > > >
> > > > > > >*       TE feedback functionality [feedback], and
> > > > > > >*       summary-LSA functionality [summary_lsa]."
> > > > > > >.
> > > > > > >I want to know whether cisco/juniper routers (standard ones)
> > supports
> > > > > all of
> > > > > > >the above extension.
> > > > > > >or if not,how many.......or Whether router is supposed to
> > support how many
> > > > > > >...
> > > > > >
> > > > > > I do not think any vendor supports all the method mentioned
> > above, but just
> > > > > > a subset. If you are running a network, your feed-backs on your
> > preferred
> > > > > > method is very welcome.
> > > > > >
> > > > > > JP.
> > > > > >
> > > > > > >Regards,
> > > > > > >---Sachin
> > > > >
> > > > >--
> > > > >Papadimitriou Dimitri
> > > > >E-mail : [email-masked]
> > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > >E-mail : [email-masked]
> > > > >Public : http://psg.com/~dpapadimitriou/
> > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> > >
> > > --
> > > Papadimitriou Dimitri
> > > E-mail : [email-masked]
> > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > E-mail : [email-masked]
> > > Public : http://psg.com/~dpapadimitriou/
> > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Thu, 12 Dec 2002 13:06:51 -0800
From: "Varma, Eve L (Eve)" <[email-masked]>
To: John Drake <[email-masked]>, "Varma, Eve L (Eve)" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 16:05:55 -0500

Hi John,

I don't want to go too many rounds on what was, after all, an
OIF discussion.  However, there was a fairly sustained effort to
establish p-UNI as a separate interface specification from 
several of our colleagues in the OIF.  It was however, decided, that it
would NOT become a separate interface specification and the
proposal to do otherwise was not accepted.  That is an accurate statement.

Best regards,
Eve

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 3:42 PM
To: 'Varma, Eve L (Eve)'; 'Stephen Trowbridge'
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Let me try again.

I think it is a leap of faith to go from what the minutes say:

"It was agreed that further work related to Private-UNI/ILSI would take
place under the auspices of UNI 2.0, and would not be a separate interface
specification.  In particular, that services of interest be extracted from
oif2002.540 and submitted as UNI 2.0 candidates (see candidate #19)." 

to your interpretation of what the minutes say:

"Thus it is accurate to state that p-UNI/ILSI was not accepted (was
rejected) as a separate interface specification."

-----Original Message-----
From: Varma, Eve L (Eve) [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 12:34 PM
To: John Drake; 'Stephen Trowbridge'
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi John,

In fact, it was agreed within the OIF that the p-UNI/ILSI would not
become a separate interface specification.  If you refer to the OIF minutes
in
OIF2002.269.4, you will see the statement:

"It was agreed that further work related to Private-UNI/ILSI would take
place under the auspices of UNI 2.0, and would not be a separate interface
specification.  In particular, that services of interest be extracted from
oif2002.540 and submitted as UNI 2.0 candidates (see candidate #19)."  

As no subsequent contributions related to possible additional services were
submitted, candidate #19 was ultimately dropped.

Thus it is accurate to state that p-UNI/ILSI was not accepted (was rejected)
as a separate interface specification.

Best regards,
Eve

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 3:10 PM
To: 'Stephen Trowbridge'
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

I just noticed in this:  "Interface B (P-UNI/ILSI rejected by OIF,
draft-swallow-gmpls-overlay-00.txt
currently under consideration for WG status by ccamp)" the sly phrase
characterization "rejected by OIF".

In point of fact, it was not rejected by the OIF.  This is the type of
misinformation that I think Kireeti was talking about in an earlier e-mail.

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 11:08 AM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I think that the diversity of opinions indicates a couple of issues
that are still open for debate.

There are two proposed interfaces:
Interface A (using my terminology from the last email): OIF-UNI
Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
  currently under consideration for WG status by ccamp)

I think there are carriers who want interface A who fear that standardizing
interface B reduces their chance of getting A. Some work needs to go into
alleviating that fear. One way is to get rid of interface B. Another might
be to make it clear that vendors still intend to provide interface A
instead of using interface B as a way to shortcut things and avoid giving
(certain) carriers what they really want. For example, just because
Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
users who really want it from buying Office-XP "Professional".

Another issue: are A and B different enough to be worth having two
standardized
interfaces? Are the shortcuts in B worth introducing interworking issues
(will these ever be in the same network, e.g., at the enterprise/operator
boundary?) and having to deal with those in the standards. Analyzing this
is probably tricky with documents written in different styles produced by
different organizations. Maybe we need to bring interface A (the OIF-UNI
functionality) in as an Internet Draft so they can be looked at side by
side.

Regards,
Steve

John Drake wrote:
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my e-mail
discussing
> this topic, to wit:
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> Le Roux (12/3)."
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> >
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and managing the
> > network.
> >
> > JD:  No one is forcing you to supporting this interface, except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > don't think this interface is useful for you, please ignore it, but
don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is similar, but
> doesn't quite solve all the same problems as A, and tells the carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface A and
interface
> B are both standardized, and if (the/some) carrier(s) want interface A and
> (many/most) vendors choose to build only interface B, then the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the same"
problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve

Delivery-date: Thu, 12 Dec 2002 13:00:15 -0800
From: John Drake <[email-masked]>
To: "'Varma, Eve L (Eve)'" <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 12:59:13 -0800

and furthermore, what you said:

"Thus it is accurate to state that p-UNI/ILSI was not accepted (was
rejected) as a separate interface specification." 

is not at all what Stephen said:

"Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
currently under consideration for WG status by ccamp)"

So as far as I'm concerned you're both wrong

-----Original Message-----
From: Varma, Eve L (Eve) [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 12:34 PM
To: John Drake; 'Stephen Trowbridge'
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi John,

In fact, it was agreed within the OIF that the p-UNI/ILSI would not
become a separate interface specification.  If you refer to the OIF minutes
in
OIF2002.269.4, you will see the statement:

"It was agreed that further work related to Private-UNI/ILSI would take
place under the auspices of UNI 2.0, and would not be a separate interface
specification.  In particular, that services of interest be extracted from
oif2002.540 and submitted as UNI 2.0 candidates (see candidate #19)."  

As no subsequent contributions related to possible additional services were
submitted, candidate #19 was ultimately dropped.

Thus it is accurate to state that p-UNI/ILSI was not accepted (was rejected)
as a separate interface specification.

Best regards,
Eve

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 3:10 PM
To: 'Stephen Trowbridge'
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

I just noticed in this:  "Interface B (P-UNI/ILSI rejected by OIF,
draft-swallow-gmpls-overlay-00.txt
currently under consideration for WG status by ccamp)" the sly phrase
characterization "rejected by OIF".

In point of fact, it was not rejected by the OIF.  This is the type of
misinformation that I think Kireeti was talking about in an earlier e-mail.

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 11:08 AM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I think that the diversity of opinions indicates a couple of issues
that are still open for debate.

There are two proposed interfaces:
Interface A (using my terminology from the last email): OIF-UNI
Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
  currently under consideration for WG status by ccamp)

I think there are carriers who want interface A who fear that standardizing
interface B reduces their chance of getting A. Some work needs to go into
alleviating that fear. One way is to get rid of interface B. Another might
be to make it clear that vendors still intend to provide interface A
instead of using interface B as a way to shortcut things and avoid giving
(certain) carriers what they really want. For example, just because
Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
users who really want it from buying Office-XP "Professional".

Another issue: are A and B different enough to be worth having two
standardized
interfaces? Are the shortcuts in B worth introducing interworking issues
(will these ever be in the same network, e.g., at the enterprise/operator
boundary?) and having to deal with those in the standards. Analyzing this
is probably tricky with documents written in different styles produced by
different organizations. Maybe we need to bring interface A (the OIF-UNI
functionality) in as an Internet Draft so they can be looked at side by
side.

Regards,
Steve

John Drake wrote:
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my e-mail
discussing
> this topic, to wit:
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> Le Roux (12/3)."
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> >
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and managing the
> > network.
> >
> > JD:  No one is forcing you to supporting this interface, except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > don't think this interface is useful for you, please ignore it, but
don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is similar, but
> doesn't quite solve all the same problems as A, and tells the carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface A and
interface
> B are both standardized, and if (the/some) carrier(s) want interface A and
> (many/most) vendors choose to build only interface B, then the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the same"
problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve

Delivery-date: Thu, 12 Dec 2002 12:42:54 -0800
From: John Drake <[email-masked]>
To: "'Varma, Eve L (Eve)'" <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 12:41:55 -0800

Let me try again.

I think it is a leap of faith to go from what the minutes say:

"It was agreed that further work related to Private-UNI/ILSI would take
place under the auspices of UNI 2.0, and would not be a separate interface
specification.  In particular, that services of interest be extracted from
oif2002.540 and submitted as UNI 2.0 candidates (see candidate #19)." 

to your interpretation of what the minutes say:

"Thus it is accurate to state that p-UNI/ILSI was not accepted (was
rejected) as a separate interface specification."

-----Original Message-----
From: Varma, Eve L (Eve) [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 12:34 PM
To: John Drake; 'Stephen Trowbridge'
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi John,

In fact, it was agreed within the OIF that the p-UNI/ILSI would not
become a separate interface specification.  If you refer to the OIF minutes
in
OIF2002.269.4, you will see the statement:

"It was agreed that further work related to Private-UNI/ILSI would take
place under the auspices of UNI 2.0, and would not be a separate interface
specification.  In particular, that services of interest be extracted from
oif2002.540 and submitted as UNI 2.0 candidates (see candidate #19)."  

As no subsequent contributions related to possible additional services were
submitted, candidate #19 was ultimately dropped.

Thus it is accurate to state that p-UNI/ILSI was not accepted (was rejected)
as a separate interface specification.

Best regards,
Eve

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 3:10 PM
To: 'Stephen Trowbridge'
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

I just noticed in this:  "Interface B (P-UNI/ILSI rejected by OIF,
draft-swallow-gmpls-overlay-00.txt
currently under consideration for WG status by ccamp)" the sly phrase
characterization "rejected by OIF".

In point of fact, it was not rejected by the OIF.  This is the type of
misinformation that I think Kireeti was talking about in an earlier e-mail.

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 11:08 AM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I think that the diversity of opinions indicates a couple of issues
that are still open for debate.

There are two proposed interfaces:
Interface A (using my terminology from the last email): OIF-UNI
Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
  currently under consideration for WG status by ccamp)

I think there are carriers who want interface A who fear that standardizing
interface B reduces their chance of getting A. Some work needs to go into
alleviating that fear. One way is to get rid of interface B. Another might
be to make it clear that vendors still intend to provide interface A
instead of using interface B as a way to shortcut things and avoid giving
(certain) carriers what they really want. For example, just because
Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
users who really want it from buying Office-XP "Professional".

Another issue: are A and B different enough to be worth having two
standardized
interfaces? Are the shortcuts in B worth introducing interworking issues
(will these ever be in the same network, e.g., at the enterprise/operator
boundary?) and having to deal with those in the standards. Analyzing this
is probably tricky with documents written in different styles produced by
different organizations. Maybe we need to bring interface A (the OIF-UNI
functionality) in as an Internet Draft so they can be looked at side by
side.

Regards,
Steve

John Drake wrote:
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my e-mail
discussing
> this topic, to wit:
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> Le Roux (12/3)."
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> >
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and managing the
> > network.
> >
> > JD:  No one is forcing you to supporting this interface, except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > don't think this interface is useful for you, please ignore it, but
don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is similar, but
> doesn't quite solve all the same problems as A, and tells the carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface A and
interface
> B are both standardized, and if (the/some) carrier(s) want interface A and
> (many/most) vendors choose to build only interface B, then the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the same"
problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve

Delivery-date: Thu, 12 Dec 2002 12:38:51 -0800
From: John Drake <[email-masked]>
To: "'Varma, Eve L (Eve)'" <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 12:38:02 -0800

This is pretty much what Bala said a while back.  I think it is a leap of
faith to go from the minutes say:

: to your interppreation of what the minutes say

-----Original Message-----
From: Varma, Eve L (Eve) [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 12:34 PM
To: John Drake; 'Stephen Trowbridge'
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi John,

In fact, it was agreed within the OIF that the p-UNI/ILSI would not
become a separate interface specification.  If you refer to the OIF minutes
in
OIF2002.269.4, you will see the statement:

"It was agreed that further work related to Private-UNI/ILSI would take
place under the auspices of UNI 2.0, and would not be a separate interface
specification.  In particular, that services of interest be extracted from
oif2002.540 and submitted as UNI 2.0 candidates (see candidate #19)."  

As no subsequent contributions related to possible additional services were
submitted, candidate #19 was ultimately dropped.

Thus it is accurate to state that p-UNI/ILSI was not accepted (was rejected)
as a separate interface specification.

Best regards,
Eve

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 3:10 PM
To: 'Stephen Trowbridge'
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

I just noticed in this:  "Interface B (P-UNI/ILSI rejected by OIF,
draft-swallow-gmpls-overlay-00.txt
currently under consideration for WG status by ccamp)" the sly phrase
characterization "rejected by OIF".

In point of fact, it was not rejected by the OIF.  This is the type of
misinformation that I think Kireeti was talking about in an earlier e-mail.

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 11:08 AM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I think that the diversity of opinions indicates a couple of issues
that are still open for debate.

There are two proposed interfaces:
Interface A (using my terminology from the last email): OIF-UNI
Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
  currently under consideration for WG status by ccamp)

I think there are carriers who want interface A who fear that standardizing
interface B reduces their chance of getting A. Some work needs to go into
alleviating that fear. One way is to get rid of interface B. Another might
be to make it clear that vendors still intend to provide interface A
instead of using interface B as a way to shortcut things and avoid giving
(certain) carriers what they really want. For example, just because
Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
users who really want it from buying Office-XP "Professional".

Another issue: are A and B different enough to be worth having two
standardized
interfaces? Are the shortcuts in B worth introducing interworking issues
(will these ever be in the same network, e.g., at the enterprise/operator
boundary?) and having to deal with those in the standards. Analyzing this
is probably tricky with documents written in different styles produced by
different organizations. Maybe we need to bring interface A (the OIF-UNI
functionality) in as an Internet Draft so they can be looked at side by
side.

Regards,
Steve

John Drake wrote:
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my e-mail
discussing
> this topic, to wit:
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> Le Roux (12/3)."
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> >
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and managing the
> > network.
> >
> > JD:  No one is forcing you to supporting this interface, except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > don't think this interface is useful for you, please ignore it, but
don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is similar, but
> doesn't quite solve all the same problems as A, and tells the carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface A and
interface
> B are both standardized, and if (the/some) carrier(s) want interface A and
> (many/most) vendors choose to build only interface B, then the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the same"
problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve

Delivery-date: Thu, 12 Dec 2002 12:34:51 -0800
From: "Varma, Eve L (Eve)" <[email-masked]>
To: John Drake <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 15:33:44 -0500

Hi John,

In fact, it was agreed within the OIF that the p-UNI/ILSI would not
become a separate interface specification.  If you refer to the OIF minutes in
OIF2002.269.4, you will see the statement:

"It was agreed that further work related to Private-UNI/ILSI would take place under the auspices of UNI 2.0, and would not be a separate interface specification.  In particular, that services of interest be extracted from oif2002.540 and submitted as UNI 2.0 candidates (see candidate #19)."  

As no subsequent contributions related to possible additional services were submitted, candidate #19 was ultimately dropped.

Thus it is accurate to state that p-UNI/ILSI was not accepted (was rejected) as a separate interface specification.

Best regards,
Eve

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 3:10 PM
To: 'Stephen Trowbridge'
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

I just noticed in this:  "Interface B (P-UNI/ILSI rejected by OIF,
draft-swallow-gmpls-overlay-00.txt
currently under consideration for WG status by ccamp)" the sly phrase
characterization "rejected by OIF".

In point of fact, it was not rejected by the OIF.  This is the type of
misinformation that I think Kireeti was talking about in an earlier e-mail.

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 11:08 AM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I think that the diversity of opinions indicates a couple of issues
that are still open for debate.

There are two proposed interfaces:
Interface A (using my terminology from the last email): OIF-UNI
Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
  currently under consideration for WG status by ccamp)

I think there are carriers who want interface A who fear that standardizing
interface B reduces their chance of getting A. Some work needs to go into
alleviating that fear. One way is to get rid of interface B. Another might
be to make it clear that vendors still intend to provide interface A
instead of using interface B as a way to shortcut things and avoid giving
(certain) carriers what they really want. For example, just because
Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
users who really want it from buying Office-XP "Professional".

Another issue: are A and B different enough to be worth having two
standardized
interfaces? Are the shortcuts in B worth introducing interworking issues
(will these ever be in the same network, e.g., at the enterprise/operator
boundary?) and having to deal with those in the standards. Analyzing this
is probably tricky with documents written in different styles produced by
different organizations. Maybe we need to bring interface A (the OIF-UNI
functionality) in as an Internet Draft so they can be looked at side by
side.

Regards,
Steve

John Drake wrote:
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my e-mail
discussing
> this topic, to wit:
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> Le Roux (12/3)."
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> >
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and managing the
> > network.
> >
> > JD:  No one is forcing you to supporting this interface, except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > don't think this interface is useful for you, please ignore it, but
don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is similar, but
> doesn't quite solve all the same problems as A, and tells the carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface A and
interface
> B are both standardized, and if (the/some) carrier(s) want interface A and
> (many/most) vendors choose to build only interface B, then the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the same"
problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve

Delivery-date: Thu, 12 Dec 2002 12:29:20 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 12:28:24 -0800

Let's juxtapose this statement from your e-mail:

"The OIF has a carrier group. At carrier group meetings, only carriers
are allowed to speak. Vendors (like me) can attend and LISTEN, but
are not allowed to speak. In this forum, hours were spent discussing
P-UNI/ILSI and coming to the conclusion that this is not what the
carriers in the OIF wanted."

With this statement from Mark Jones in a 12/3 e-mail: 

"The OIF discussion does not represent all those interested in the 
work.  Sprint is not currently an OIF member, but we are interested in 
the results.  An open standards body has a much better chance of 
representing a broader industry view."

And let us also remember that draft swallow is not necessarily intended
for carriers, let alone 'carriers in the OIF'

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 12:10 PM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I wasn't going to get into this, but since you ask ...

This isn't from reading carrier's minds.

The OIF has a carrier group. At carrier group meetings, only carriers
are allowed to speak. Vendors (like me) can attend and LISTEN, but
are not allowed to speak. In this forum, hours were spent discussing
P-UNI/ILSI and coming to the conclusion that this is not what the
carriers in the OIF wanted.

So I have tried to synthesize what I heard there, but I do have to admit
that this discussion still leaves me puzzled. I would be grateful
if some of the carriers could help clear up my confusion:

What puzzles me is that many of the same carriers participate
in ccamp as in OIF. Yet many of the carriers who adamantly opposed
P-UNI/ILSI in OIF are not so adamantly opposing work on this draft,
and some have actually supported it. So I have to wonder, why?

One possibility is that not everyone has recognized that this is
the same proposal (after all, it has a new name). But by now, with
some of the earlier comments in emails like "IETF has every right
to consider propopsals that have been rejected in another forum",
I think that everyone should recognize that these are really the
same. So I would like to hear from these carriers about the following:
- Do they STILL support this work as it has become more clear that
this is (essentially) the same proposal as P-UNI/ILSI that they
rejected in OIF?
- Have requirements changed since the OIF decision?
- Is there really a different market that is appropriate for IETF
to address that was not considered by OIF?

I hope that carriers can help clear this up for me.
Regards,
Steve

John Drake wrote:
> 
> And another thing.
> 
> What gives you the right to speak as though you can read the minds of the
> carriers and synthesize their thoughts?  I think the ones that are
> interested in this topic have spoken on the list without needing your
help.
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 11:08 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> I think that the diversity of opinions indicates a couple of issues
> that are still open for debate.
> 
> There are two proposed interfaces:
> Interface A (using my terminology from the last email): OIF-UNI
> Interface B (P-UNI/ILSI rejected by OIF,
draft-swallow-gmpls-overlay-00.txt
>   currently under consideration for WG status by ccamp)
> 
> I think there are carriers who want interface A who fear that
standardizing
> interface B reduces their chance of getting A. Some work needs to go into
> alleviating that fear. One way is to get rid of interface B. Another might
> be to make it clear that vendors still intend to provide interface A
> instead of using interface B as a way to shortcut things and avoid giving
> (certain) carriers what they really want. For example, just because
> Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
> users who really want it from buying Office-XP "Professional".
> 
> Another issue: are A and B different enough to be worth having two
> standardized
> interfaces? Are the shortcuts in B worth introducing interworking issues
> (will these ever be in the same network, e.g., at the enterprise/operator
> boundary?) and having to deal with those in the standards. Analyzing this
> is probably tricky with documents written in different styles produced by
> different organizations. Maybe we need to bring interface A (the OIF-UNI
> functionality) in as an Internet Draft so they can be looked at side by
> side.
> 
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Stephen,
> >
> > I couldn't help but notice that you snipped the part of my e-mail
> discussing
> > this topic, to wit:
> >
> > "JD:  If you're planning to assume the role of arbiter for the whole
> > industry, please review the e-mails all of who support accepting the
> > draft as a CCAMP WG document.  In particular I'd review the e-mails of
> > some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> > of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> > Le Roux (12/3)."
> >
> > The four individuals I explicitly mentioned work for carriers and the
> > e-mails I mentioned
> > all speak in favor of making the the draft a working group draft.  Also,
a
> > representative
> > from another carrier is a co-author.  And lest we forget, two of the
> > individuals work for
> > the same carrier that Monica works for.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Thursday, December 12, 2002 9:41 AM
> > To: John Drake
> > Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> > [email-masked]
> > Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> >
> > John,
> >
> > John Drake wrote:
> > (snipped)
> > > Snipped...
> > >
> > > >From a carrier perspective, supporting a third UNI alternative will
> > > bring additional concerns regarding interoperability and managing the
> > > network.
> > >
> > > JD:  No one is forcing you to supporting this interface, except
perhaps
> > > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if
you
> > > don't think this interface is useful for you, please ignore it, but
> don't
> > > assume that it is not useful for others.
> >
> > Let's see, a carrier wants interface A.
> >
> > A vendor proposes to standardize another interface B which is similar,
but
> > doesn't quite solve all the same problems as A, and tells the carrier
"If
> > you don't like B you don't have to use it".
> >
> > It seems to me that the carrier concern is that if interface A and
> interface
> > B are both standardized, and if (the/some) carrier(s) want interface A
and
> > (many/most) vendors choose to build only interface B, then the carriers
> > don't get what they want.
> >
> > This fear is what makes people reluctant to progress work on an
interface
> > they don't feel is useful for them.
> >
> > The idea of standards is surely to promote the deployment of
interoperable
> > implementations, but part of accomplishing this is to try to limit the
> > number of "standardized" solutions to the same problem.
> > I think the next debate would be what we really mean by "the same"
> problem.
> > Some arguments have appeared that this interface is directed at a
> > different problem, so I have to ask whether it is different enough
> > to justify standardizing a different solution.
> > Regards,
> > Steve

Delivery-date: Thu, 12 Dec 2002 12:23:43 -0800
Date: Thu, 12 Dec 2002 15:22:14 -0500
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Multi-Area TE Protocol Extensions
Cc: [email-masked], "sachin laddha" <[email-masked]>, [email-masked], [email-masked]

Hi,

At 10:43 11/12/2002 -0500, Cheng-Yin Lee wrote:
>Dimitri, JP,
>While I think an applicability section/statement is fine, I'm not sure 
>if  a mechanism
>to compute inter-area TE path belong in this  ID.

This was exactly my impression.

JP.

>We did include applications in the first discussion of this ID and in the 
>slides
>http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html and in 
>addressing
>Kireeti's suggestion to include a discussion on the impact of message 
>size, we provided
>an inter-area example for illustration purposes. However,  there have also 
>been
>suggestions in the past to not discuss applications specifically  in the 
>draft itself.
>I am fine with either way.
>
>thanks
>cheng-yin
>
>[email-masked] wrote:
>
> > jp,
> >
> > > this ID does not propose a mechanism to compute inter-area TE path
> >
> > well i would say that either none of them does it, or all of
> > them, more accurately route exclusions are applicable to any
> > mpls network where full computation of the ero is not performed
> > before the LSP is signaled, implying thus a "scope" for computed
> > path thus among other applicable to multiple areas - nevertheless
> > i agree that a next version of this i-d should probably include
> > an applicability section covering this in a bit more details (see
> > also section 4.1 for an example -
> >
> > this said and as for any other input or i-d provided on constraint-
> > passing (as well as path query, btw) lot of work is still needed to
> > achieve a decent first step in this effort;
> >
> > thanks,
> > - dimitri.
> >
> > Jean Philippe Vasseur wrote:
> > >
> > > Hi Dimitri,
> > >
> > > cc'ing CCAMP - see in line,
> > >
> > > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > > >jp,
> > > >
> > > >in fact the below list should simply be as follows for
> > > >signalling-based methods: 1) constraint-passing 2) loose
> > > >routing and 3) path query;
> > > >
> > > >and the for constraint-passing we have a several i-d's
> > > >such as,
> > > >
> > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-r 
> oute-01.txt
> > > >
> > >
> > > this ID does not propose a mechanism to compute inter-area TE path
> > >
> > > >constraint passing may also be extended using the crank-
> > > >back as listed below; the usage scenarios of these methods
> > > >are described in the following:
> > > >
> > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te- 
> 03.txt
> > > >
> > > >now probably it is worth spending some time in considering
> > > >input coming from the tewg wrt to this effort, most of the
> > > >input that you see listed above has been produced over the
> > > >past year (and more) i can't imagine stepping in the protocol
> > > >details without a clear consensus on what do we want to cover
> > > >within the ccamp wg & w/o taking into account the tewg rec's
> > > >(probably better to discuss this on the ccamp mailing list)
> > >
> > > Fully agree with you. Hopefully multi-area TE should be soon part of the
> > > CCAMP charter.
> > >
> > > JP.
> > >
> > > >thanks,
> > > >- dimitri.
> > > >
> > > >Jean Philippe Vasseur wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > > >Hi,
> > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > > >"Initial requirements are given here for protocol support of the
> > > > multi-area
> > > > > >TE methods, which include needs to support
> > > > > >
> > > > > >*       path-computation-server (PCS) functionality [kompella, lee,
> > > > vasseur,
> > > > > >te-qos-routing],
> > > > > >*       query functionality [query, vasseur],
> > > > > >*       crankback functionality [crankback],
> > > > > >
> > > > > >and, optionally,
> > > > > >
> > > > > >*       TE feedback functionality [feedback], and
> > > > > >*       summary-LSA functionality [summary_lsa]."
> > > > > >.
> > > > > >I want to know whether cisco/juniper routers (standard ones) 
> supports
> > > > all of
> > > > > >the above extension.
> > > > > >or if not,how many.......or Whether router is supposed to 
> support how many
> > > > > >...
> > > > >
> > > > > I do not think any vendor supports all the method mentioned 
> above, but just
> > > > > a subset. If you are running a network, your feed-backs on your 
> preferred
> > > > > method is very welcome.
> > > > >
> > > > > JP.
> > > > >
> > > > > >Regards,
> > > > > >---Sachin
> > > >
> > > >--
> > > >Papadimitriou Dimitri
> > > >E-mail : [email-masked]
> > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > >E-mail : [email-masked]
> > > >Public : http://psg.com/~dpapadimitriou/
> > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Thu, 12 Dec 2002 12:17:25 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 12:16:25 -0800

You're still choosing to ignore my question, which is why have you been
designated as the one to speak for the carriers.  Let them speak for
themselves and you speak for yourself.

And as i mentioned earlier, this isn't even necessarily about carriers

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 12:10 PM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I wasn't going to get into this, but since you ask ...

This isn't from reading carrier's minds.

The OIF has a carrier group. At carrier group meetings, only carriers
are allowed to speak. Vendors (like me) can attend and LISTEN, but
are not allowed to speak. In this forum, hours were spent discussing
P-UNI/ILSI and coming to the conclusion that this is not what the
carriers in the OIF wanted.

So I have tried to synthesize what I heard there, but I do have to admit
that this discussion still leaves me puzzled. I would be grateful
if some of the carriers could help clear up my confusion:

What puzzles me is that many of the same carriers participate
in ccamp as in OIF. Yet many of the carriers who adamantly opposed
P-UNI/ILSI in OIF are not so adamantly opposing work on this draft,
and some have actually supported it. So I have to wonder, why?

One possibility is that not everyone has recognized that this is
the same proposal (after all, it has a new name). But by now, with
some of the earlier comments in emails like "IETF has every right
to consider propopsals that have been rejected in another forum",
I think that everyone should recognize that these are really the
same. So I would like to hear from these carriers about the following:
- Do they STILL support this work as it has become more clear that
this is (essentially) the same proposal as P-UNI/ILSI that they
rejected in OIF?
- Have requirements changed since the OIF decision?
- Is there really a different market that is appropriate for IETF
to address that was not considered by OIF?

I hope that carriers can help clear this up for me.
Regards,
Steve

John Drake wrote:
> 
> And another thing.
> 
> What gives you the right to speak as though you can read the minds of the
> carriers and synthesize their thoughts?  I think the ones that are
> interested in this topic have spoken on the list without needing your
help.
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 11:08 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> I think that the diversity of opinions indicates a couple of issues
> that are still open for debate.
> 
> There are two proposed interfaces:
> Interface A (using my terminology from the last email): OIF-UNI
> Interface B (P-UNI/ILSI rejected by OIF,
draft-swallow-gmpls-overlay-00.txt
>   currently under consideration for WG status by ccamp)
> 
> I think there are carriers who want interface A who fear that
standardizing
> interface B reduces their chance of getting A. Some work needs to go into
> alleviating that fear. One way is to get rid of interface B. Another might
> be to make it clear that vendors still intend to provide interface A
> instead of using interface B as a way to shortcut things and avoid giving
> (certain) carriers what they really want. For example, just because
> Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
> users who really want it from buying Office-XP "Professional".
> 
> Another issue: are A and B different enough to be worth having two
> standardized
> interfaces? Are the shortcuts in B worth introducing interworking issues
> (will these ever be in the same network, e.g., at the enterprise/operator
> boundary?) and having to deal with those in the standards. Analyzing this
> is probably tricky with documents written in different styles produced by
> different organizations. Maybe we need to bring interface A (the OIF-UNI
> functionality) in as an Internet Draft so they can be looked at side by
> side.
> 
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Stephen,
> >
> > I couldn't help but notice that you snipped the part of my e-mail
> discussing
> > this topic, to wit:
> >
> > "JD:  If you're planning to assume the role of arbiter for the whole
> > industry, please review the e-mails all of who support accepting the
> > draft as a CCAMP WG document.  In particular I'd review the e-mails of
> > some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> > of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> > Le Roux (12/3)."
> >
> > The four individuals I explicitly mentioned work for carriers and the
> > e-mails I mentioned
> > all speak in favor of making the the draft a working group draft.  Also,
a
> > representative
> > from another carrier is a co-author.  And lest we forget, two of the
> > individuals work for
> > the same carrier that Monica works for.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Thursday, December 12, 2002 9:41 AM
> > To: John Drake
> > Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> > [email-masked]
> > Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> >
> > John,
> >
> > John Drake wrote:
> > (snipped)
> > > Snipped...
> > >
> > > >From a carrier perspective, supporting a third UNI alternative will
> > > bring additional concerns regarding interoperability and managing the
> > > network.
> > >
> > > JD:  No one is forcing you to supporting this interface, except
perhaps
> > > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if
you
> > > don't think this interface is useful for you, please ignore it, but
> don't
> > > assume that it is not useful for others.
> >
> > Let's see, a carrier wants interface A.
> >
> > A vendor proposes to standardize another interface B which is similar,
but
> > doesn't quite solve all the same problems as A, and tells the carrier
"If
> > you don't like B you don't have to use it".
> >
> > It seems to me that the carrier concern is that if interface A and
> interface
> > B are both standardized, and if (the/some) carrier(s) want interface A
and
> > (many/most) vendors choose to build only interface B, then the carriers
> > don't get what they want.
> >
> > This fear is what makes people reluctant to progress work on an
interface
> > they don't feel is useful for them.
> >
> > The idea of standards is surely to promote the deployment of
interoperable
> > implementations, but part of accomplishing this is to try to limit the
> > number of "standardized" solutions to the same problem.
> > I think the next debate would be what we really mean by "the same"
> problem.
> > Some arguments have appeared that this interface is directed at a
> > different problem, so I have to ask whether it is different enough
> > to justify standardizing a different solution.
> > Regards,
> > Steve

Delivery-date: Thu, 12 Dec 2002 12:12:30 -0800
Date: Thu, 12 Dec 2002 13:09:49 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I wasn't going to get into this, but since you ask ...

This isn't from reading carrier's minds.

The OIF has a carrier group. At carrier group meetings, only carriers
are allowed to speak. Vendors (like me) can attend and LISTEN, but
are not allowed to speak. In this forum, hours were spent discussing
P-UNI/ILSI and coming to the conclusion that this is not what the
carriers in the OIF wanted.

So I have tried to synthesize what I heard there, but I do have to admit
that this discussion still leaves me puzzled. I would be grateful
if some of the carriers could help clear up my confusion:

What puzzles me is that many of the same carriers participate
in ccamp as in OIF. Yet many of the carriers who adamantly opposed
P-UNI/ILSI in OIF are not so adamantly opposing work on this draft,
and some have actually supported it. So I have to wonder, why?

One possibility is that not everyone has recognized that this is
the same proposal (after all, it has a new name). But by now, with
some of the earlier comments in emails like "IETF has every right
to consider propopsals that have been rejected in another forum",
I think that everyone should recognize that these are really the
same. So I would like to hear from these carriers about the following:
- Do they STILL support this work as it has become more clear that
this is (essentially) the same proposal as P-UNI/ILSI that they
rejected in OIF?
- Have requirements changed since the OIF decision?
- Is there really a different market that is appropriate for IETF
to address that was not considered by OIF?

I hope that carriers can help clear this up for me.
Regards,
Steve

John Drake wrote:
> 
> And another thing.
> 
> What gives you the right to speak as though you can read the minds of the
> carriers and synthesize their thoughts?  I think the ones that are
> interested in this topic have spoken on the list without needing your help.
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 11:08 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> I think that the diversity of opinions indicates a couple of issues
> that are still open for debate.
> 
> There are two proposed interfaces:
> Interface A (using my terminology from the last email): OIF-UNI
> Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
>   currently under consideration for WG status by ccamp)
> 
> I think there are carriers who want interface A who fear that standardizing
> interface B reduces their chance of getting A. Some work needs to go into
> alleviating that fear. One way is to get rid of interface B. Another might
> be to make it clear that vendors still intend to provide interface A
> instead of using interface B as a way to shortcut things and avoid giving
> (certain) carriers what they really want. For example, just because
> Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
> users who really want it from buying Office-XP "Professional".
> 
> Another issue: are A and B different enough to be worth having two
> standardized
> interfaces? Are the shortcuts in B worth introducing interworking issues
> (will these ever be in the same network, e.g., at the enterprise/operator
> boundary?) and having to deal with those in the standards. Analyzing this
> is probably tricky with documents written in different styles produced by
> different organizations. Maybe we need to bring interface A (the OIF-UNI
> functionality) in as an Internet Draft so they can be looked at side by
> side.
> 
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Stephen,
> >
> > I couldn't help but notice that you snipped the part of my e-mail
> discussing
> > this topic, to wit:
> >
> > "JD:  If you're planning to assume the role of arbiter for the whole
> > industry, please review the e-mails all of who support accepting the
> > draft as a CCAMP WG document.  In particular I'd review the e-mails of
> > some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> > of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> > Le Roux (12/3)."
> >
> > The four individuals I explicitly mentioned work for carriers and the
> > e-mails I mentioned
> > all speak in favor of making the the draft a working group draft.  Also, a
> > representative
> > from another carrier is a co-author.  And lest we forget, two of the
> > individuals work for
> > the same carrier that Monica works for.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Thursday, December 12, 2002 9:41 AM
> > To: John Drake
> > Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> > [email-masked]
> > Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> >
> > John,
> >
> > John Drake wrote:
> > (snipped)
> > > Snipped...
> > >
> > > >From a carrier perspective, supporting a third UNI alternative will
> > > bring additional concerns regarding interoperability and managing the
> > > network.
> > >
> > > JD:  No one is forcing you to supporting this interface, except perhaps
> > > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > > don't think this interface is useful for you, please ignore it, but
> don't
> > > assume that it is not useful for others.
> >
> > Let's see, a carrier wants interface A.
> >
> > A vendor proposes to standardize another interface B which is similar, but
> > doesn't quite solve all the same problems as A, and tells the carrier "If
> > you don't like B you don't have to use it".
> >
> > It seems to me that the carrier concern is that if interface A and
> interface
> > B are both standardized, and if (the/some) carrier(s) want interface A and
> > (many/most) vendors choose to build only interface B, then the carriers
> > don't get what they want.
> >
> > This fear is what makes people reluctant to progress work on an interface
> > they don't feel is useful for them.
> >
> > The idea of standards is surely to promote the deployment of interoperable
> > implementations, but part of accomplishing this is to try to limit the
> > number of "standardized" solutions to the same problem.
> > I think the next debate would be what we really mean by "the same"
> problem.
> > Some arguments have appeared that this interface is directed at a
> > different problem, so I have to ask whether it is different enough
> > to justify standardizing a different solution.
> > Regards,
> > Steve

Delivery-date: Thu, 12 Dec 2002 12:11:52 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 12:09:33 -0800

I just noticed in this:  "Interface B (P-UNI/ILSI rejected by OIF,
draft-swallow-gmpls-overlay-00.txt
currently under consideration for WG status by ccamp)" the sly phrase
characterization "rejected by OIF".

In point of fact, it was not rejected by the OIF.  This is the type of
misinformation that I think Kireeti was talking about in an earlier e-mail.

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 11:08 AM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I think that the diversity of opinions indicates a couple of issues
that are still open for debate.

There are two proposed interfaces:
Interface A (using my terminology from the last email): OIF-UNI
Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
  currently under consideration for WG status by ccamp)

I think there are carriers who want interface A who fear that standardizing
interface B reduces their chance of getting A. Some work needs to go into
alleviating that fear. One way is to get rid of interface B. Another might
be to make it clear that vendors still intend to provide interface A
instead of using interface B as a way to shortcut things and avoid giving
(certain) carriers what they really want. For example, just because
Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
users who really want it from buying Office-XP "Professional".

Another issue: are A and B different enough to be worth having two
standardized
interfaces? Are the shortcuts in B worth introducing interworking issues
(will these ever be in the same network, e.g., at the enterprise/operator
boundary?) and having to deal with those in the standards. Analyzing this
is probably tricky with documents written in different styles produced by
different organizations. Maybe we need to bring interface A (the OIF-UNI
functionality) in as an Internet Draft so they can be looked at side by
side.

Regards,
Steve

John Drake wrote:
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my e-mail
discussing
> this topic, to wit:
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> Le Roux (12/3)."
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> >
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and managing the
> > network.
> >
> > JD:  No one is forcing you to supporting this interface, except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > don't think this interface is useful for you, please ignore it, but
don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is similar, but
> doesn't quite solve all the same problems as A, and tells the carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface A and
interface
> B are both standardized, and if (the/some) carrier(s) want interface A and
> (many/most) vendors choose to build only interface B, then the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the same"
problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve

Delivery-date: Thu, 12 Dec 2002 11:58:29 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 11:57:18 -0800

And lest we forget, Interface A is not a standard

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 11:08 AM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I think that the diversity of opinions indicates a couple of issues
that are still open for debate.

There are two proposed interfaces:
Interface A (using my terminology from the last email): OIF-UNI
Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
  currently under consideration for WG status by ccamp)

I think there are carriers who want interface A who fear that standardizing
interface B reduces their chance of getting A. Some work needs to go into
alleviating that fear. One way is to get rid of interface B. Another might
be to make it clear that vendors still intend to provide interface A
instead of using interface B as a way to shortcut things and avoid giving
(certain) carriers what they really want. For example, just because
Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
users who really want it from buying Office-XP "Professional".

Another issue: are A and B different enough to be worth having two
standardized
interfaces? Are the shortcuts in B worth introducing interworking issues
(will these ever be in the same network, e.g., at the enterprise/operator
boundary?) and having to deal with those in the standards. Analyzing this
is probably tricky with documents written in different styles produced by
different organizations. Maybe we need to bring interface A (the OIF-UNI
functionality) in as an Internet Draft so they can be looked at side by
side.

Regards,
Steve

John Drake wrote:
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my e-mail
discussing
> this topic, to wit:
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> Le Roux (12/3)."
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> >
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and managing the
> > network.
> >
> > JD:  No one is forcing you to supporting this interface, except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > don't think this interface is useful for you, please ignore it, but
don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is similar, but
> doesn't quite solve all the same problems as A, and tells the carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface A and
interface
> B are both standardized, and if (the/some) carrier(s) want interface A and
> (many/most) vendors choose to build only interface B, then the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the same"
problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve

Delivery-date: Thu, 12 Dec 2002 11:45:38 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 11:44:40 -0800

And another thing.

What gives you the right to speak as though you can read the minds of the
carriers and synthesize their thoughts?  I think the ones that are
interested in this topic have spoken on the list without needing your help.

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 11:08 AM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I think that the diversity of opinions indicates a couple of issues
that are still open for debate.

There are two proposed interfaces:
Interface A (using my terminology from the last email): OIF-UNI
Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
  currently under consideration for WG status by ccamp)

I think there are carriers who want interface A who fear that standardizing
interface B reduces their chance of getting A. Some work needs to go into
alleviating that fear. One way is to get rid of interface B. Another might
be to make it clear that vendors still intend to provide interface A
instead of using interface B as a way to shortcut things and avoid giving
(certain) carriers what they really want. For example, just because
Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
users who really want it from buying Office-XP "Professional".

Another issue: are A and B different enough to be worth having two
standardized
interfaces? Are the shortcuts in B worth introducing interworking issues
(will these ever be in the same network, e.g., at the enterprise/operator
boundary?) and having to deal with those in the standards. Analyzing this
is probably tricky with documents written in different styles produced by
different organizations. Maybe we need to bring interface A (the OIF-UNI
functionality) in as an Internet Draft so they can be looked at side by
side.

Regards,
Steve

John Drake wrote:
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my e-mail
discussing
> this topic, to wit:
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> Le Roux (12/3)."
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> >
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and managing the
> > network.
> >
> > JD:  No one is forcing you to supporting this interface, except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > don't think this interface is useful for you, please ignore it, but
don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is similar, but
> doesn't quite solve all the same problems as A, and tells the carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface A and
interface
> B are both standardized, and if (the/some) carrier(s) want interface A and
> (many/most) vendors choose to build only interface B, then the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the same"
problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve

Delivery-date: Thu, 12 Dec 2002 11:40:25 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 11:39:06 -0800

This is silly.

The ony person from a carrier that has indicated any opposition is Monica.
You're trying to create a 'diversity of opinions' when none exists.  And
BTW, the Swallow draft is not necessarily intended for carriers in any
event.

Kirreti and Ron, can we just get a read on 'rough consensus' and move on?

Thanks,

John  

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 11:08 AM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I think that the diversity of opinions indicates a couple of issues
that are still open for debate.

There are two proposed interfaces:
Interface A (using my terminology from the last email): OIF-UNI
Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
  currently under consideration for WG status by ccamp)

I think there are carriers who want interface A who fear that standardizing
interface B reduces their chance of getting A. Some work needs to go into
alleviating that fear. One way is to get rid of interface B. Another might
be to make it clear that vendors still intend to provide interface A
instead of using interface B as a way to shortcut things and avoid giving
(certain) carriers what they really want. For example, just because
Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
users who really want it from buying Office-XP "Professional".

Another issue: are A and B different enough to be worth having two
standardized
interfaces? Are the shortcuts in B worth introducing interworking issues
(will these ever be in the same network, e.g., at the enterprise/operator
boundary?) and having to deal with those in the standards. Analyzing this
is probably tricky with documents written in different styles produced by
different organizations. Maybe we need to bring interface A (the OIF-UNI
functionality) in as an Internet Draft so they can be looked at side by
side.

Regards,
Steve

John Drake wrote:
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my e-mail
discussing
> this topic, to wit:
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> Le Roux (12/3)."
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> >
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and managing the
> > network.
> >
> > JD:  No one is forcing you to supporting this interface, except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > don't think this interface is useful for you, please ignore it, but
don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is similar, but
> doesn't quite solve all the same problems as A, and tells the carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface A and
interface
> B are both standardized, and if (the/some) carrier(s) want interface A and
> (many/most) vendors choose to build only interface B, then the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the same"
problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve

Delivery-date: Thu, 12 Dec 2002 11:11:27 -0800
Date: Thu, 12 Dec 2002 12:07:43 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,
I think that the diversity of opinions indicates a couple of issues
that are still open for debate.

There are two proposed interfaces:
Interface A (using my terminology from the last email): OIF-UNI
Interface B (P-UNI/ILSI rejected by OIF, draft-swallow-gmpls-overlay-00.txt
  currently under consideration for WG status by ccamp)

I think there are carriers who want interface A who fear that standardizing
interface B reduces their chance of getting A. Some work needs to go into
alleviating that fear. One way is to get rid of interface B. Another might
be to make it clear that vendors still intend to provide interface A
instead of using interface B as a way to shortcut things and avoid giving
(certain) carriers what they really want. For example, just because
Microsoft sells an Office-XP "Home" edition doesn't prevent corporate
users who really want it from buying Office-XP "Professional".

Another issue: are A and B different enough to be worth having two standardized
interfaces? Are the shortcuts in B worth introducing interworking issues
(will these ever be in the same network, e.g., at the enterprise/operator
boundary?) and having to deal with those in the standards. Analyzing this
is probably tricky with documents written in different styles produced by
different organizations. Maybe we need to bring interface A (the OIF-UNI
functionality) in as an Internet Draft so they can be looked at side by side.

Regards,
Steve

John Drake wrote:
> 
> Stephen,
> 
> I couldn't help but notice that you snipped the part of my e-mail discussing
> this topic, to wit:
> 
> "JD:  If you're planning to assume the role of arbiter for the whole
> industry, please review the e-mails all of who support accepting the
> draft as a CCAMP WG document.  In particular I'd review the e-mails of
> some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
> of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
> Le Roux (12/3)."
> 
> The four individuals I explicitly mentioned work for carriers and the
> e-mails I mentioned
> all speak in favor of making the the draft a working group draft.  Also, a
> representative
> from another carrier is a co-author.  And lest we forget, two of the
> individuals work for
> the same carrier that Monica works for.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 9:41 AM
> To: John Drake
> Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
> [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> John,
> 
> John Drake wrote:
> (snipped)
> > Snipped...
> >
> > >From a carrier perspective, supporting a third UNI alternative will
> > bring additional concerns regarding interoperability and managing the
> > network.
> >
> > JD:  No one is forcing you to supporting this interface, except perhaps
> > potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> > don't think this interface is useful for you, please ignore it, but don't
> > assume that it is not useful for others.
> 
> Let's see, a carrier wants interface A.
> 
> A vendor proposes to standardize another interface B which is similar, but
> doesn't quite solve all the same problems as A, and tells the carrier "If
> you don't like B you don't have to use it".
> 
> It seems to me that the carrier concern is that if interface A and interface
> B are both standardized, and if (the/some) carrier(s) want interface A and
> (many/most) vendors choose to build only interface B, then the carriers
> don't get what they want.
> 
> This fear is what makes people reluctant to progress work on an interface
> they don't feel is useful for them.
> 
> The idea of standards is surely to promote the deployment of interoperable
> implementations, but part of accomplishing this is to try to limit the
> number of "standardized" solutions to the same problem.
> I think the next debate would be what we really mean by "the same" problem.
> Some arguments have appeared that this interface is directed at a
> different problem, so I have to ask whether it is different enough
> to justify standardizing a different solution.
> Regards,
> Steve

Delivery-date: Thu, 12 Dec 2002 10:17:44 -0800
From: Jonathan Lang <[email-masked]>
To: "'Ong, Lyndon'" <[email-masked]>, 'Ron Bonica' <[email-masked]>, [email-masked]
Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-test-sonet-sdh-00
Date: Thu, 12 Dec 2002 10:14:10 -0800

Lyndon,
  Thanks for the comments. My responses inline.

-Jonathan

> -----Original Message-----
> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Wednesday, December 11, 2002 4:22 PM
> To: 'Ron Bonica'; [email-masked]
> Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-test-sonet-sdh-00
> 
> 
> Hi Ron,
> 
> Some comments on the draft:
> 
> -- It is a bit difficult to tell from the draft when the
> functions discussed are required or optional.  In particular,
> section 1 says "Specifically, we define the SONET/SDH test 
> procedures used for Link verification and link property 
> correlation.  This requires a new trace monitoring function
> that is discussed in this document."  
> 
> This could be interpreted to mean that the 
> test procedures defined are required for link property
> correlation, a mandatory procedure in LMP, whereas the
> procedures (correct me if I'm wrong) are really required
> for link verification, an optional procedure.
> 
> How about making the following changes for clarification:
> 
> Abstract: "This document details the Synchronous Optical
> NETwork (SONET)/Synchronous Digital Hierarchy (SDH) technology
> specific information needed when sending Link Management 
> Protocol (LMP) test messages _for link 
> verification_.
ok

> 
> Section 1, last paragraph:  "In this document, we define SONET/SDH
> specific information needed _for the optional LMP link verification
> procedure_.  Specifically, we define the SONET/SDH test procedures
> used for link verification _when this is enabled_.  _These procedures_
> require a new trace monitoring function that is discussed in this
> document.  Once the data links have been verified, they can be
> grouped to form TE links."
I modified the text to read:

"In this document, we define SONET/SDH technology specific information
needed for the LMP link verification procedure.  These procedures require a
new trace monitoring function that is introduced in this document.  Once the
data links have been verified, they can be grouped to form TE links."

> 
> -- in section 4.1.6, the "TraceReq Message" does not define any
> specific frame length to be returned; is this implicit, or is
> some kind of indication required for this to work?
The frame length is implicit in the Trace Type (J0/J1/J2).

> 
> -- there is a minor typo in 4.1.9, "TraceInsertReq Message" should
> be "InsertTraceReq Mesage".
done.

> 
> 
> Cheers,
> 
> Lyndon Ong
> 
> 
> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 6:03 AM
> To: [email-masked]
> Subject: WG Last Call: draft-ietf-ccamp-lmp-test-sonet-sdh-00
> 
> 
> Folks,
> 
> This message begins a Working Group last call on
> draft-ietf-ccamp-lmp-test-sonet-sdh-00. Last call will end 
> two weeks from
> today, on December 20, 2002.
> 
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "We are not on Earth to guard a museum, but
> to cultivate a flourishing garden of life."
>                 -- Angelo Giuseppe Roncalli
> 
> 
> 

Delivery-date: Thu, 12 Dec 2002 10:02:09 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 10:00:22 -0800

Stephen,

I couldn't help but notice that you snipped the part of my e-mail discussing
this topic, to wit:

"JD:  If you're planning to assume the role of arbiter for the whole
industry, please review the e-mails all of who support accepting the
draft as a CCAMP WG document.  In particular I'd review the e-mails of
some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
Le Roux (12/3)."

The four individuals I explicitly mentioned work for carriers and the
e-mails I mentioned
all speak in favor of making the the draft a working group draft.  Also, a
representative
from another carrier is a co-author.  And lest we forget, two of the
individuals work for
the same carrier that Monica works for.

Thanks,

John

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 9:41 AM
To: John Drake
Cc: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan;
[email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,

John Drake wrote:
(snipped)
> Snipped...
> 
> >From a carrier perspective, supporting a third UNI alternative will
> bring additional concerns regarding interoperability and managing the
> network.
> 
> JD:  No one is forcing you to supporting this interface, except perhaps
> potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> don't think this interface is useful for you, please ignore it, but don't
> assume that it is not useful for others.

Let's see, a carrier wants interface A.

A vendor proposes to standardize another interface B which is similar, but
doesn't quite solve all the same problems as A, and tells the carrier "If
you don't like B you don't have to use it".

It seems to me that the carrier concern is that if interface A and interface
B are both standardized, and if (the/some) carrier(s) want interface A and
(many/most) vendors choose to build only interface B, then the carriers
don't get what they want.

This fear is what makes people reluctant to progress work on an interface
they don't feel is useful for them.

The idea of standards is surely to promote the deployment of interoperable
implementations, but part of accomplishing this is to try to limit the
number of "standardized" solutions to the same problem.
I think the next debate would be what we really mean by "the same" problem.
Some arguments have appeared that this interface is directed at a
different problem, so I have to ask whether it is different enough
to justify standardizing a different solution.
Regards,
Steve

Delivery-date: Thu, 12 Dec 2002 09:43:02 -0800
Date: Thu, 12 Dec 2002 10:41:20 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

John,

John Drake wrote:
(snipped)
> Snipped...
> 
> >From a carrier perspective, supporting a third UNI alternative will
> bring additional concerns regarding interoperability and managing the
> network.
> 
> JD:  No one is forcing you to supporting this interface, except perhaps
> potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
> don't think this interface is useful for you, please ignore it, but don't
> assume that it is not useful for others.

Let's see, a carrier wants interface A.

A vendor proposes to standardize another interface B which is similar, but
doesn't quite solve all the same problems as A, and tells the carrier "If
you don't like B you don't have to use it".

It seems to me that the carrier concern is that if interface A and interface
B are both standardized, and if (the/some) carrier(s) want interface A and
(many/most) vendors choose to build only interface B, then the carriers
don't get what they want.

This fear is what makes people reluctant to progress work on an interface
they don't feel is useful for them.

The idea of standards is surely to promote the deployment of interoperable
implementations, but part of accomplishing this is to try to limit the
number of "standardized" solutions to the same problem.
I think the next debate would be what we really mean by "the same" problem.
Some arguments have appeared that this interface is directed at a
different problem, so I have to ask whether it is different enough
to justify standardizing a different solution.
Regards,
Steve

Delivery-date: Thu, 12 Dec 2002 09:17:36 -0800
From: Yanhe Fan <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Thu, 12 Dec 2002 12:16:23 -0500

It should be a working group document.

Thanks,
Yanhe

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 2:39 PM
To: [email-masked]
Subject: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi,

This is a call for consensus to make the above document a CCAMP WG
document.  This call will end Dec 17, 2002.

Please indicate your opinion by replying to this email.

Thanks,
Kireeti.

Delivery-date: Thu, 12 Dec 2002 09:06:13 -0800
Date: Thu, 12 Dec 2002 09:03:18 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Khuzema Pithewan <[email-masked]>
cc: "Lazer, Monica A, ALASO" <[email-masked]>, <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi Khuzema,

On Wed, 11 Dec 2002, Khuzema Pithewan wrote:

> Hi,
>
> Whatever u said about the responsibility of OIF, ITU-T, and IETF makes
> sense. Now we have a document from OIF, which was the responsibility of
> IETF.

It was *not* the responsibility of the IETF!!!  (This is another
example of misleading statements.)

> Can't IETF adopt that document?

It's simple: someone produce an *individual* contribution and post
it as an Internet draft.  However, I should first answer your other
point:

> ... instead
> of developing a standard from scratch?

If you read the GMPLS overlay document, you'll see that it *is not*
developing a standard from scratch.  In fact, there are no extensions,
just some slight procedural changes.

So, the alternatives are:
a) take the OIF UNI1.0 doc, remove a bunch of extensions not present
   in the IETF GMPLS, add EROs and RROs and handling procedures; OR
b) take the GMPLS doc, add nothing, subtract nothing, explain ERO and
   RRO handling and addressing ...

Which seems more rational to you?

BTW, the consensus *at the IETF* seems fairly clear.

Kireeti.

Delivery-date: Wed, 11 Dec 2002 20:29:08 -0800
From: Khuzema Pithewan <[email-masked]>
To: Kireeti Kompella <[email-masked]>, "Lazer, Monica A, ALASO" <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Wed, 11 Dec 2002 22:25:18 -0600

Hi,

Whatever u said about the responsibility of OIF, ITU-T, and IETF makes
sense. Now we have a document from OIF, which was the responsibility of
IETF. Cant IETF adopt that document, enhance it using public forum instead
of developing a standard from scratch? If that happens, Vendor/Carrier
community will get largely benefitted from it. It will save the efforts put
by OIF. Will reduce interop problems.

Khuzema

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 9:31 AM
To: Lazer, Monica A, ALASO
Cc: Khuzema Pithewan; [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi Monica,

On Wed, 11 Dec 2002, Lazer, Monica A, ALASO wrote:

> Generally speaking, I do not think it is a good idea to proliferate
> multiple options supporting the same thing. It will make
> interoperability efforts quite painful. So, regarding you points, I
> would like to bring the following.
> OIF produces interoperability agreements,

Implementation agreements, to be pedantic.  And these are certainly
useful, but they are not standards.

In fact, if you look at the OIF FAQ, you'll see:

| Question: How will the work of the OIF differ from that of the other
| various standards bodies?

| Answer: The OIF will concentrate on interlayer issues that specifically
| pertain to data networking elements natively accessing the optical
| layer.  Most standardization efforts are defining characteristics within
| the optical network rather than addressing how it interacts with data
| networks. Because of this, the OIF expects to be completely
| complementary to work in the standards bodies.

In the case of GMPLS Overlay, a standardization body (namely, the
IETF) is addressing the interaction of the optical network with data
networks.  Does this mean that the OIF will recognize this and stop
any further work on the OIF UNI?  This is why I suggested that Khuzema
bring up this issue with the OIF.

> it is a forum recognized by
> ITU-T,

Can ITU-T recommendations make normative references to OIF implementation
agreements?  In what sense does the ITU-T recognize the OIF: is there
any recognition beyond the fact that liaison statements are exchanged?

Since this issue has come up several times, it would be useful if
someone speaking on behalf of the ITU-T would comment on the nature
of the relationship between the ITU-T and the OIF, the fact that the OIF
is not a standards forum, and that their documents are implementation
agreements.

> and until recently also by IETF.

I wasn't aware of this.  Can you point me to any document or public
statement that substantiates this?  That would be very helpful.  As
far as I know, there is no formal liaison (see
http://www.ietf.org/ietf/1ietf-liaisons.txt)

I would really like closure on this.  I see a *lot* of misleading
statements (e.g., supposed formal relationships between the OIF and the
IETF, that the OIF develops standards, etc.) used to support arguments,
and this is doing a real disservice to the community.

> ITU-T produces recommendations. So would one than state that they are
> not standards?  IETF produces RFC (request for comments?) Then these are
> also not standards?

This is what the ITU says about its Recommendations:

| ITU-T Recommendations
|
| ITU-T produces high-quality standards (Recommendations) on technical,
| operating and tariff questions.

As for RFCs, read 2026, section 4.1.1.

Both bodies recognize this and can make normative cross references.

As for the OIF, read their mission statement, or the FAQ above.

Kireeti.

PS: you should know from the tutorial I gave at the T1X1.5 meeting that
    RFCs are not really Requests for Comments.  Comments are welcome
    right up to Last Call, but once an RFC is published, it is immutable.

Delivery-date: Wed, 11 Dec 2002 20:19:58 -0800
From: "Ong, Lyndon" <[email-masked]>
To: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Wed, 11 Dec 2002 20:18:55 -0800

Hi Folks,

Although there is obviously a lot of interest in
the overlay draft, there is also a lot of debate
about its relationship to the OIF UNI specification.

Since the UNI is already out, can the overlay
draft be enhanced with some wording that explains 
fairly clearly how it differs from the UNI?
This could help clear up the issue and avoid 
future repeats of the discussion.

BTW, it's a bit late but I withdraw my comment on
the voting in Atlanta, others clearly had a better
count than I did!

Cheers,

Lyndon Ong

Delivery-date: Wed, 11 Dec 2002 20:03:54 -0800
Date: Wed, 11 Dec 2002 20:01:29 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Lazer, Monica A, ALASO" <[email-masked]>
cc: Khuzema Pithewan <[email-masked]>, <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi Monica,

On Wed, 11 Dec 2002, Lazer, Monica A, ALASO wrote:

> Generally speaking, I do not think it is a good idea to proliferate
> multiple options supporting the same thing. It will make
> interoperability efforts quite painful. So, regarding you points, I
> would like to bring the following.
> OIF produces interoperability agreements,

Implementation agreements, to be pedantic.  And these are certainly
useful, but they are not standards.

In fact, if you look at the OIF FAQ, you'll see:

| Question: How will the work of the OIF differ from that of the other
| various standards bodies?

| Answer: The OIF will concentrate on interlayer issues that specifically
| pertain to data networking elements natively accessing the optical
| layer.  Most standardization efforts are defining characteristics within
| the optical network rather than addressing how it interacts with data
| networks. Because of this, the OIF expects to be completely
| complementary to work in the standards bodies.

In the case of GMPLS Overlay, a standardization body (namely, the
IETF) is addressing the interaction of the optical network with data
networks.  Does this mean that the OIF will recognize this and stop
any further work on the OIF UNI?  This is why I suggested that Khuzema
bring up this issue with the OIF.

> it is a forum recognized by
> ITU-T,

Can ITU-T recommendations make normative references to OIF implementation
agreements?  In what sense does the ITU-T recognize the OIF: is there
any recognition beyond the fact that liaison statements are exchanged?

Since this issue has come up several times, it would be useful if
someone speaking on behalf of the ITU-T would comment on the nature
of the relationship between the ITU-T and the OIF, the fact that the OIF
is not a standards forum, and that their documents are implementation
agreements.

> and until recently also by IETF.

I wasn't aware of this.  Can you point me to any document or public
statement that substantiates this?  That would be very helpful.  As
far as I know, there is no formal liaison (see
http://www.ietf.org/ietf/1ietf-liaisons.txt)

I would really like closure on this.  I see a *lot* of misleading
statements (e.g., supposed formal relationships between the OIF and the
IETF, that the OIF develops standards, etc.) used to support arguments,
and this is doing a real disservice to the community.

> ITU-T produces recommendations. So would one than state that they are
> not standards?  IETF produces RFC (request for comments?) Then these are
> also not standards?

This is what the ITU says about its Recommendations:

| ITU-T Recommendations
|
| ITU-T produces high-quality standards (Recommendations) on technical,
| operating and tariff questions.

As for RFCs, read 2026, section 4.1.1.

Both bodies recognize this and can make normative cross references.

As for the OIF, read their mission statement, or the FAQ above.

Kireeti.

PS: you should know from the tutorial I gave at the T1X1.5 meeting that
    RFCs are not really Requests for Comments.  Comments are welcome
    right up to Last Call, but once an RFC is published, it is immutable.

Delivery-date: Wed, 11 Dec 2002 16:22:54 -0800
From: "Ong, Lyndon" <[email-masked]>
To: 'Ron Bonica' <[email-masked]>, [email-masked]
Subject: RE: WG Last Call: draft-ietf-ccamp-lmp-test-sonet-sdh-00
Date: Wed, 11 Dec 2002 16:21:40 -0800

Hi Ron,

Some comments on the draft:

-- It is a bit difficult to tell from the draft when the
functions discussed are required or optional.  In particular,
section 1 says "Specifically, we define the SONET/SDH test 
procedures used for Link verification and link property 
correlation.  This requires a new trace monitoring function
that is discussed in this document."  

This could be interpreted to mean that the 
test procedures defined are required for link property
correlation, a mandatory procedure in LMP, whereas the
procedures (correct me if I'm wrong) are really required
for link verification, an optional procedure.

How about making the following changes for clarification:

Abstract: "This document details the Synchronous Optical
NETwork (SONET)/Synchronous Digital Hierarchy (SDH) technology
specific information needed when sending Link Management 
Protocol (LMP) test messages _for link 
verification_.

Section 1, last paragraph:  "In this document, we define SONET/SDH
specific information needed _for the optional LMP link verification
procedure_.  Specifically, we define the SONET/SDH test procedures
used for link verification _when this is enabled_.  _These procedures_
require a new trace monitoring function that is discussed in this
document.  Once the data links have been verified, they can be
grouped to form TE links."

-- in section 4.1.6, the "TraceReq Message" does not define any
specific frame length to be returned; is this implicit, or is
some kind of indication required for this to work?

-- there is a minor typo in 4.1.9, "TraceInsertReq Message" should
be "InsertTraceReq Mesage".

Cheers,

Lyndon Ong

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]]
Sent: Friday, December 06, 2002 6:03 AM
To: [email-masked]
Subject: WG Last Call: draft-ietf-ccamp-lmp-test-sonet-sdh-00

Folks,

This message begins a Working Group last call on
draft-ietf-ccamp-lmp-test-sonet-sdh-00. Last call will end two weeks from
today, on December 20, 2002.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli

Delivery-date: Wed, 11 Dec 2002 13:03:53 -0800
From: John Drake <[email-masked]>
To: 'Bala Rajagopalan' <[email-masked]>, "'Lazer, Monica A, ALASO'" <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Wed, 11 Dec 2002 13:01:51 -0800

Comments in line

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Wednesday, December 11, 2002 12:03 PM
To: John Drake; 'Lazer, Monica A, ALASO'
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

JD:  A general comment is that I think your e-mail is sort of orthogonal
to my e-mail.  I.e., I'm not sure how what you wrote relates to what I
wrote.

John,

I don't agree with your assertions below.
The swallow draft addresses the case where 

1. it's implicit that you're running GMPLS RSVP-TE within the core

JD:  This is assumed, but not required.

2. you're using IP addresses (only) for transport NEs

JD:  Are you saying that you cannot signal IP addresses in UNI 1.0?  This
is surprising.

3. there's a possibility of exchanging some (limited)
   reachability information between the core and edge

JD:  Reachability exchange is mentioned in the draft.  It is certainly
is not required, in which case the functionality reduces to UNI 1.0.

As I mentioned earlier, I think it's useful to 
consider this specific scenario further.

But these assumptions are not made in the case of UNI 1.0.

JD:  Fine, but what does any of this have to do with my e-mail?

Bala

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Wednesday, December 11, 2002 12:31 PM
> To: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan
> Cc: [email-masked]
> Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> 
> JD:  This is simply not true.  Since we're dealing with an 
> overlay model,
> any control plane can be used inside the cloud.
> 
> 
> UNI 1.0 allows transition to use of GMPLS-based protocols
> without the assumption of overnight replacement of existing control
> plane implementations, which is not even feasible for a large network.
> 
> 
> JD:  You seem to be implicitly asserting that this is NOT the 
> case with
> this interface.  If this is in fact what you are asserting, then it is
> simply not true.
> 
> 
> Monica A. Lazer
> Network Architecture and Reliability
> 
> 908 234 8462
> [email-masked]
> 
> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Wednesday, December 11, 2002 5:04 AM
> To: Khuzema Pithewan
> Cc: [email-masked]
> Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> > This draft addresses the overlay networks which UNI1.0 from OIF
> addresses.
> > shouldn't we have one document addressing one problem. In 
> fact, UNI1.0
> > addresses it in-depth, so why there is a need of another document
> talking
> > about overlay networks?
> 
> I guess you haven't really been following the CCAMP email, so I'll
> repeat:
> (a) the OIF UNI1.0 is *not* a standard;
> (b) just because the OIF is discussing something doesn't preclude the
>     IETF from discussing it;
> (c) the problems addressed are not quite the same.
> 
> If having two documents in this space is an issue, please make your
> concerns known to the OIF.
> 
> Kireeti.
> 

Delivery-date: Wed, 11 Dec 2002 12:10:38 -0800
From: Bala Rajagopalan <[email-masked]>
To: 'John Drake' <[email-masked]>, "'Lazer, Monica A, ALASO'" <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Wed, 11 Dec 2002 15:03:28 -0500

John,

I don't agree with your assertions below.
The swallow draft addresses the case where 

1. it's implicit that you're running GMPLS RSVP-TE within the core
2. you're using IP addresses (only) for transport NEs
3. there's a possibility of exchanging some (limited)
   reachability information between the core and edge

As I mentioned earlier, I think it's useful to 
consider this specific scenario further.

But these assumptions are not made in the case of UNI 1.0.

Bala

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Wednesday, December 11, 2002 12:31 PM
> To: 'Lazer, Monica A, ALASO'; Kireeti Kompella; Khuzema Pithewan
> Cc: [email-masked]
> Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> 
> JD:  This is simply not true.  Since we're dealing with an 
> overlay model,
> any control plane can be used inside the cloud.
> 
> 
> UNI 1.0 allows transition to use of GMPLS-based protocols
> without the assumption of overnight replacement of existing control
> plane implementations, which is not even feasible for a large network.
> 
> 
> JD:  You seem to be implicitly asserting that this is NOT the 
> case with
> this interface.  If this is in fact what you are asserting, then it is
> simply not true.
> 
> 
> Monica A. Lazer
> Network Architecture and Reliability
> 
> 908 234 8462
> [email-masked]
> 
> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Wednesday, December 11, 2002 5:04 AM
> To: Khuzema Pithewan
> Cc: [email-masked]
> Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> > This draft addresses the overlay networks which UNI1.0 from OIF
> addresses.
> > shouldn't we have one document addressing one problem. In 
> fact, UNI1.0
> > addresses it in-depth, so why there is a need of another document
> talking
> > about overlay networks?
> 
> I guess you haven't really been following the CCAMP email, so I'll
> repeat:
> (a) the OIF UNI1.0 is *not* a standard;
> (b) just because the OIF is discussing something doesn't preclude the
>     IETF from discussing it;
> (c) the problems addressed are not quite the same.
> 
> If having two documents in this space is an issue, please make your
> concerns known to the OIF.
> 
> Kireeti.
> 

Delivery-date: Wed, 11 Dec 2002 10:04:56 -0800
Date: 11 Dec 2002 13:02:19 -0500
From: "Cheng-Yin Lee" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Cc: "Jean Philippe Vasseur" <[email-masked]>, "sachin laddha" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multi-Area TE Protocol Extensions

Hi Dimitri,

[email-masked] wrote:

> hi, my suggestion based on the jp's comment was to
> scope the examples and usage scenarios in this i-d
> to have at the end some material for the coverage
> of constraint passing methods in the ma-te context
> (i interpreted the remark of jp as follows, it is
> not cristal clear to see how this method applies
> to ma-te),

Ok, I see. Clarifying the scope of the problem that the ID addresses, is definitely useful.

> also discussion from ietf 53 is settled
> we don't cover inter-as for the time being at the
> ccamp wg - fyi te wg has just start the discussions
> on inter-as te thus we first wait for their input...
> and then we see based on their results -

Understood.

> ps: this said there are plenty of ways to avoid to
> deal with specific application usage within the core
> of the document specifications

Sure.

thanks
cheng-yin

>
>
> thanks,
> - dimitri.
>
> [email-masked] wrote:
> >
> > Dimitri, JP,
> > While I think an applicability section/statement is fine, I'm not sure if  a mechanism
> > to compute inter-area TE path belong in this  ID.
> >
> > We did include applications in the first discussion of this ID and in the slides
> > http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html  and in addressing
> > Kireeti's suggestion to include a discussion on the impact of message size, we provided
> > an inter-area example for illustration purposes. However,  there have also been
> > suggestions in the past to not discuss applications specifically  in the draft itself.
> > I am fine with either way.
> >
> > thanks
> > cheng-yin
> >
> > [email-masked] wrote:
> >
> > > jp,
> > >
> > > > this ID does not propose a mechanism to compute inter-area TE path
> > >
> > > well i would say that either none of them does it, or all of
> > > them, more accurately route exclusions are applicable to any
> > > mpls network where full computation of the ero is not performed
> > > before the LSP is signaled, implying thus a "scope" for computed
> > > path thus among other applicable to multiple areas - nevertheless
> > > i agree that a next version of this i-d should probably include
> > > an applicability section covering this in a bit more details (see
> > > also section 4.1 for an example -
> > >
> > > this said and as for any other input or i-d provided on constraint-
> > > passing (as well as path query, btw) lot of work is still needed to
> > > achieve a decent first step in this effort;
> > >
> > > thanks,
> > > - dimitri.
> > >
> > > Jean Philippe Vasseur wrote:
> > > >
> > > > Hi Dimitri,
> > > >
> > > > cc'ing CCAMP - see in line,
> > > >
> > > > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > > > >jp,
> > > > >
> > > > >in fact the below list should simply be as follows for
> > > > >signalling-based methods: 1) constraint-passing 2) loose
> > > > >routing and 3) path query;
> > > > >
> > > > >and the for constraint-passing we have a several i-d's
> > > > >such as,
> > > > >
> > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt
> > > > >
> > > >
> > > > this ID does not propose a mechanism to compute inter-area TE path
> > > >
> > > > >constraint passing may also be extended using the crank-
> > > > >back as listed below; the usage scenarios of these methods
> > > > >are described in the following:
> > > > >
> > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt
> > > > >
> > > > >now probably it is worth spending some time in considering
> > > > >input coming from the tewg wrt to this effort, most of the
> > > > >input that you see listed above has been produced over the
> > > > >past year (and more) i can't imagine stepping in the protocol
> > > > >details without a clear consensus on what do we want to cover
> > > > >within the ccamp wg & w/o taking into account the tewg rec's
> > > > >(probably better to discuss this on the ccamp mailing list)
> > > >
> > > > Fully agree with you. Hopefully multi-area TE should be soon part of the
> > > > CCAMP charter.
> > > >
> > > > JP.
> > > >
> > > > >thanks,
> > > > >- dimitri.
> > > > >
> > > > >Jean Philippe Vasseur wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > > > >Hi,
> > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > > > >"Initial requirements are given here for protocol support of the
> > > > > multi-area
> > > > > > >TE methods, which include needs to support
> > > > > > >
> > > > > > >*       path-computation-server (PCS) functionality [kompella, lee,
> > > > > vasseur,
> > > > > > >te-qos-routing],
> > > > > > >*       query functionality [query, vasseur],
> > > > > > >*       crankback functionality [crankback],
> > > > > > >
> > > > > > >and, optionally,
> > > > > > >
> > > > > > >*       TE feedback functionality [feedback], and
> > > > > > >*       summary-LSA functionality [summary_lsa]."
> > > > > > >.
> > > > > > >I want to know whether cisco/juniper routers (standard ones) supports
> > > > > all of
> > > > > > >the above extension.
> > > > > > >or if not,how many.......or Whether router is supposed to support how many
> > > > > > >...
> > > > > >
> > > > > > I do not think any vendor supports all the method mentioned above, but just
> > > > > > a subset. If you are running a network, your feed-backs on your preferred
> > > > > > method is very welcome.
> > > > > >
> > > > > > JP.
> > > > > >
> > > > > > >Regards,
> > > > > > >---Sachin
> > > > >
> > > > >--
> > > > >Papadimitriou Dimitri
> > > > >E-mail : [email-masked]
> > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > >E-mail : [email-masked]
> > > > >Public : http://psg.com/~dpapadimitriou/
> > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> > >
> > > --
> > > Papadimitriou Dimitri
> > > E-mail : [email-masked]
> > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > E-mail : [email-masked]
> > > Public : http://psg.com/~dpapadimitriou/
> > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
>
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 11 Dec 2002 09:32:08 -0800
From: John Drake <[email-masked]>
To: "'Lazer, Monica A, ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Khuzema Pithewan <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Wed, 11 Dec 2002 09:31:11 -0800

Comments inline

-----Original Message-----
From: Lazer, Monica A, ALASO [mailto:[email-masked]]
Sent: Wednesday, December 11, 2002 6:16 AM
To: Kireeti Kompella; Khuzema Pithewan
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Snipped...

Regarding point b - true. But I would like to understand what is the
value for the whole industry in doing this, which brings me to point c.

JD:  If you're planning to assume the role of arbiter for the whole
industry, please review the e-mails all of who support accepting the
draft as a CCAMP WG document.  In particular I'd review the e-mails of
some of your peers:  Deborah Brungard (12/6), Gerry Ash (12/3) (both
of whom I think you know), as well as Mark Jones (12/2), and Jean-Louis
Le Roux (12/3).

While the application may not be identical, I believe that the
application addressed by this draft can easily supported by the existing
UNI 1.0.

JD:  Interesting.  I believe that Area 51 contains the remains of space
aliens.   

Snipped... 

>From a carrier perspective, supporting a third UNI alternative will
bring additional concerns regarding interoperability and managing the
network.

JD:  No one is forcing you to supporting this interface, except perhaps
potential customers.  To paraphrase George Swallow's 12/3 e-mail, if you
don't think this interface is useful for you, please ignore it, but don't
assume that it is not useful for others. 

Snipped...

having a protocol that only works with one protocol, which is not widely
deployed, will make it difficult to operate.

JD:  This is simply not true.  Since we're dealing with an overlay model,
any control plane can be used inside the cloud.

UNI 1.0 allows transition to use of GMPLS-based protocols
without the assumption of overnight replacement of existing control
plane implementations, which is not even feasible for a large network.

JD:  You seem to be implicitly asserting that this is NOT the case with
this interface.  If this is in fact what you are asserting, then it is
simply not true.

Monica A. Lazer
Network Architecture and Reliability

908 234 8462
[email-masked]

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Wednesday, December 11, 2002 5:04 AM
To: Khuzema Pithewan
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

> This draft addresses the overlay networks which UNI1.0 from OIF
addresses.
> shouldn't we have one document addressing one problem. In fact, UNI1.0
> addresses it in-depth, so why there is a need of another document
talking
> about overlay networks?

I guess you haven't really been following the CCAMP email, so I'll
repeat:
(a) the OIF UNI1.0 is *not* a standard;
(b) just because the OIF is discussing something doesn't preclude the
    IETF from discussing it;
(c) the problems addressed are not quite the same.

If having two documents in this space is an issue, please make your
concerns known to the OIF.

Kireeti.

Delivery-date: Wed, 11 Dec 2002 09:28:33 -0800
Date: Wed, 11 Dec 2002 18:30:29 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: [email-masked]
Cc: Jean Philippe Vasseur <[email-masked]>, sachin laddha <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multi-Area TE Protocol Extensions

hi, my suggestion based on the jp's comment was to 
scope the examples and usage scenarios in this i-d 
to have at the end some material for the coverage 
of constraint passing methods in the ma-te context
(i interpreted the remark of jp as follows, it is 
not cristal clear to see how this method applies
to ma-te), also discussion from ietf 53 is settled 
we don't cover inter-as for the time being at the 
ccamp wg - fyi te wg has just start the discussions 
on inter-as te thus we first wait for their input... 
and then we see based on their results - 

ps: this said there are plenty of ways to avoid to 
deal with specific application usage within the core 
of the document specifications

thanks,
- dimitri.

[email-masked] wrote:
> 
> Dimitri, JP,
> While I think an applicability section/statement is fine, I'm not sure if  a mechanism
> to compute inter-area TE path belong in this  ID.
> 
> We did include applications in the first discussion of this ID and in the slides
> http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html  and in addressing
> Kireeti's suggestion to include a discussion on the impact of message size, we provided
> an inter-area example for illustration purposes. However,  there have also been
> suggestions in the past to not discuss applications specifically  in the draft itself.
> I am fine with either way.
> 
> thanks
> cheng-yin
> 
> [email-masked] wrote:
> 
> > jp,
> >
> > > this ID does not propose a mechanism to compute inter-area TE path
> >
> > well i would say that either none of them does it, or all of
> > them, more accurately route exclusions are applicable to any
> > mpls network where full computation of the ero is not performed
> > before the LSP is signaled, implying thus a "scope" for computed
> > path thus among other applicable to multiple areas - nevertheless
> > i agree that a next version of this i-d should probably include
> > an applicability section covering this in a bit more details (see
> > also section 4.1 for an example -
> >
> > this said and as for any other input or i-d provided on constraint-
> > passing (as well as path query, btw) lot of work is still needed to
> > achieve a decent first step in this effort;
> >
> > thanks,
> > - dimitri.
> >
> > Jean Philippe Vasseur wrote:
> > >
> > > Hi Dimitri,
> > >
> > > cc'ing CCAMP - see in line,
> > >
> > > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > > >jp,
> > > >
> > > >in fact the below list should simply be as follows for
> > > >signalling-based methods: 1) constraint-passing 2) loose
> > > >routing and 3) path query;
> > > >
> > > >and the for constraint-passing we have a several i-d's
> > > >such as,
> > > >
> > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt
> > > >
> > >
> > > this ID does not propose a mechanism to compute inter-area TE path
> > >
> > > >constraint passing may also be extended using the crank-
> > > >back as listed below; the usage scenarios of these methods
> > > >are described in the following:
> > > >
> > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt
> > > >
> > > >now probably it is worth spending some time in considering
> > > >input coming from the tewg wrt to this effort, most of the
> > > >input that you see listed above has been produced over the
> > > >past year (and more) i can't imagine stepping in the protocol
> > > >details without a clear consensus on what do we want to cover
> > > >within the ccamp wg & w/o taking into account the tewg rec's
> > > >(probably better to discuss this on the ccamp mailing list)
> > >
> > > Fully agree with you. Hopefully multi-area TE should be soon part of the
> > > CCAMP charter.
> > >
> > > JP.
> > >
> > > >thanks,
> > > >- dimitri.
> > > >
> > > >Jean Philippe Vasseur wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > > >Hi,
> > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > > >"Initial requirements are given here for protocol support of the
> > > > multi-area
> > > > > >TE methods, which include needs to support
> > > > > >
> > > > > >*       path-computation-server (PCS) functionality [kompella, lee,
> > > > vasseur,
> > > > > >te-qos-routing],
> > > > > >*       query functionality [query, vasseur],
> > > > > >*       crankback functionality [crankback],
> > > > > >
> > > > > >and, optionally,
> > > > > >
> > > > > >*       TE feedback functionality [feedback], and
> > > > > >*       summary-LSA functionality [summary_lsa]."
> > > > > >.
> > > > > >I want to know whether cisco/juniper routers (standard ones) supports
> > > > all of
> > > > > >the above extension.
> > > > > >or if not,how many.......or Whether router is supposed to support how many
> > > > > >...
> > > > >
> > > > > I do not think any vendor supports all the method mentioned above, but just
> > > > > a subset. If you are running a network, your feed-backs on your preferred
> > > > > method is very welcome.
> > > > >
> > > > > JP.
> > > > >
> > > > > >Regards,
> > > > > >---Sachin
> > > >
> > > >--
> > > >Papadimitriou Dimitri
> > > >E-mail : [email-masked]
> > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > >E-mail : [email-masked]
> > > >Public : http://psg.com/~dpapadimitriou/
> > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 11 Dec 2002 08:16:03 -0800
To: IETF-Announce: ;
Cc: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-srisuresh-ospf-te-04.txt
Date: Wed, 11 Dec 2002 11:11:26 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Traffic Engineering Working Group of the IETF.

	Title		: OSPF-TE: An experimental extension to OSPF for Traffic
                          Engineering
	Author(s)	: P. Srisuresh, P. Joseph
	Filename	: draft-srisuresh-ospf-te-04.txt
	Pages		: 45
	Date		: 2002-12-9
	
This document defines OSPF-TE, an experimental traffic engineering
(TE) extension to the link-state routing protocol OSPF. New TE 
LSAs are designed to disseminate TE metrics within an autonomous 
System (AS) - intra-area as well as inter-area. An Autonomous 
System may consist of TE and non-TE nodes. Non-TE nodes are 
uneffected by the distribution of TE LSAs. A stand-alone TE Link
State Database (TE-LSDB), separate from the native OSPF LSDB, is
generated for the computation of TE circuit paths. OSPF-TE is 
also extendible to non-packet networks such as SONET/TDM and 
optical networks. A transition path is provided for those
currently using [OPQLSA-TE] and wish to adapt OSPF-TE.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-srisuresh-ospf-te-04.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-srisuresh-ospf-te-04.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-srisuresh-ospf-te-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-srisuresh-ospf-te-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 11 Dec 2002 07:46:53 -0800
Date: 11 Dec 2002 10:43:41 -0500
From: "Cheng-Yin Lee" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Cc: "Jean Philippe Vasseur" <[email-masked]>, "sachin laddha" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multi-Area TE Protocol Extensions

Dimitri, JP,
While I think an applicability section/statement is fine, I'm not sure if  a mechanism
to compute inter-area TE path belong in this  ID.

We did include applications in the first discussion of this ID and in the slides
http://www.ietf.org/proceedings/02mar/slides/ccamp-6/index.html  and in addressing
Kireeti's suggestion to include a discussion on the impact of message size, we provided
an inter-area example for illustration purposes. However,  there have also been
suggestions in the past to not discuss applications specifically  in the draft itself.
I am fine with either way.

thanks
cheng-yin

[email-masked] wrote:

> jp,
>
> > this ID does not propose a mechanism to compute inter-area TE path
>
> well i would say that either none of them does it, or all of
> them, more accurately route exclusions are applicable to any
> mpls network where full computation of the ero is not performed
> before the LSP is signaled, implying thus a "scope" for computed
> path thus among other applicable to multiple areas - nevertheless
> i agree that a next version of this i-d should probably include
> an applicability section covering this in a bit more details (see
> also section 4.1 for an example -
>
> this said and as for any other input or i-d provided on constraint-
> passing (as well as path query, btw) lot of work is still needed to
> achieve a decent first step in this effort;
>
> thanks,
> - dimitri.
>
> Jean Philippe Vasseur wrote:
> >
> > Hi Dimitri,
> >
> > cc'ing CCAMP - see in line,
> >
> > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > >jp,
> > >
> > >in fact the below list should simply be as follows for
> > >signalling-based methods: 1) constraint-passing 2) loose
> > >routing and 3) path query;
> > >
> > >and the for constraint-passing we have a several i-d's
> > >such as,
> > >
> > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt
> > >
> >
> > this ID does not propose a mechanism to compute inter-area TE path
> >
> > >constraint passing may also be extended using the crank-
> > >back as listed below; the usage scenarios of these methods
> > >are described in the following:
> > >
> > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt
> > >
> > >now probably it is worth spending some time in considering
> > >input coming from the tewg wrt to this effort, most of the
> > >input that you see listed above has been produced over the
> > >past year (and more) i can't imagine stepping in the protocol
> > >details without a clear consensus on what do we want to cover
> > >within the ccamp wg & w/o taking into account the tewg rec's
> > >(probably better to discuss this on the ccamp mailing list)
> >
> > Fully agree with you. Hopefully multi-area TE should be soon part of the
> > CCAMP charter.
> >
> > JP.
> >
> > >thanks,
> > >- dimitri.
> > >
> > >Jean Philippe Vasseur wrote:
> > > >
> > > > Hi,
> > > >
> > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > >Hi,
> > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > >"Initial requirements are given here for protocol support of the
> > > multi-area
> > > > >TE methods, which include needs to support
> > > > >
> > > > >*       path-computation-server (PCS) functionality [kompella, lee,
> > > vasseur,
> > > > >te-qos-routing],
> > > > >*       query functionality [query, vasseur],
> > > > >*       crankback functionality [crankback],
> > > > >
> > > > >and, optionally,
> > > > >
> > > > >*       TE feedback functionality [feedback], and
> > > > >*       summary-LSA functionality [summary_lsa]."
> > > > >.
> > > > >I want to know whether cisco/juniper routers (standard ones) supports
> > > all of
> > > > >the above extension.
> > > > >or if not,how many.......or Whether router is supposed to support how many
> > > > >...
> > > >
> > > > I do not think any vendor supports all the method mentioned above, but just
> > > > a subset. If you are running a network, your feed-backs on your preferred
> > > > method is very welcome.
> > > >
> > > > JP.
> > > >
> > > > >Regards,
> > > > >---Sachin
> > >
> > >--
> > >Papadimitriou Dimitri
> > >E-mail : [email-masked]
> > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > >E-mail : [email-masked]
> > >Public : http://psg.com/~dpapadimitriou/
> > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
>
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 11 Dec 2002 06:19:49 -0800
content-class: urn:content-classes:message
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Wed, 11 Dec 2002 09:16:18 -0500
From: "Lazer, Monica A, ALASO" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, "Khuzema Pithewan" <[email-masked]>
Cc: <[email-masked]>

Kireeti,
Generally speaking, I do not think it is a good idea to proliferate
multiple options supporting the same thing. It will make
interoperability efforts quite painful. So, regarding you points, I
would like to bring the following.
OIF produces interoperability agreements, it is a forum recognized by
ITU-T, and until recently also by IETF. It has had a liaison process
with both (among others). In this sense I do not quite understand your
point a. Other interoperability forums, such as ATMF, TMF produce
agreements, which are then referenced by both vendors and operators for
compliance. So, in this sense it is not clear to me what is the truth
value of the statement in point a. Not clear what the semantics are -
ITU-T produces recommendations. So would one than state that they are
not standards? IETF produces RFC (request for comments?) Then these are
also not standards?

Regarding point b - true. But I would like to understand what is the
value for the whole industry in doing this, which brings me to point c.
While the application may not be identical, I believe that the
application addressed by this draft can easily supported by the existing
UNI 1.0.

Overall, I was glad to see IETF agreeing to the importance of the
overlay model for the carriers, which are still the owners of the more
ubiquitous networks. However, I believe that we should be careful about
proliferating protocols without due diligence in assessing whether they
are required. From a carrier perspective, supporting a third UNI
alternative will bring additional concerns regarding interoperability
and managing the network. Since the existing networks use a range of
control alternatives, having a protocol that only works with one
protocol, which is not widely deployed, will make it difficult to
operate. UNI 1.0 allows transition to use of GMPLS-based protocols
without the assumption of overnight replacement of existing control
plane implementations, which is not even feasible for a large network.

Monica A. Lazer
Network Architecture and Reliability

908 234 8462
[email-masked]

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Wednesday, December 11, 2002 5:04 AM
To: Khuzema Pithewan
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

> This draft addresses the overlay networks which UNI1.0 from OIF
addresses.
> shouldn't we have one document addressing one problem. In fact, UNI1.0
> addresses it in-depth, so why there is a need of another document
talking
> about overlay networks?

I guess you haven't really been following the CCAMP email, so I'll
repeat:
(a) the OIF UNI1.0 is *not* a standard;
(b) just because the OIF is discussing something doesn't preclude the
    IETF from discussing it;
(c) the problems addressed are not quite the same.

If having two documents in this space is an issue, please make your
concerns known to the OIF.

Kireeti.

Delivery-date: Wed, 11 Dec 2002 03:13:01 -0800
Date: Wed, 11 Dec 2002 12:15:17 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Kireeti Kompella <[email-masked]>
Cc: Khuzema Pithewan <[email-masked]>, [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

hi kireeti,

i agree w/ the following statement:

> If having two documents in this space is an issue, please make your
> concerns known to the OIF.=20

this mis-understanding of the current situation=20
doesn't arise due to the ccamp community effort=20
*=A8which is open * but from oif positioning which=20
does only produces "implementation agreements"=20
on public uni, nni, whatever but nothing else

in order to have a constructive discussion on the
above mentioned document i hope that (since the=20
point has been clarified twice, at least) that we=20
will focus now on our own efforts concerning=20
gmpls for overlay networks

thanks,
- dimitri.

Kireeti Kompella wrote:
>=20
> > This draft addresses the overlay networks which UNI1.0 from OIF address=
es.
> > shouldn't we have one document addressing one problem. In fact, UNI1.0
> > addresses it in-depth, so why there is a need of another document talki=
ng
> > about overlay networks?
>=20
> I guess you haven't really been following the CCAMP email, so I'll repeat:
> (a) the OIF UNI1.0 is *not* a standard;
> (b) just because the OIF is discussing something doesn't preclude the
>     IETF from discussing it;
> (c) the problems addressed are not quite the same.
>=20
> If having two documents in this space is an issue, please make your
> concerns known to the OIF.
>=20
> Kireeti.

--=20
Papadimitriou Dimitri=20
E-mail : [email-masked]=20
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 11 Dec 2002 02:05:44 -0800
Date: Wed, 11 Dec 2002 02:03:02 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
cc: Greg Bernstein <[email-masked]>, <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi Lyndon,

On Tue, 10 Dec 2002, Ong, Lyndon wrote:

> Excuse my ignorance of the past history on this, but why are
> the MPLS and GMPLS architecture documents Standards Track?
> Most architecture documents I've seen have been Informational

A fair question.

A document is standards track (or informational, or BCP) because
of its contents, not because of what other similar documents are.
I am not in a position to comment on the MPLS arch doc, but the
GMPLS arch doc has many prescriptive statements that would make it
at least a BCP, and very likely a PS.  It also provides the glue
between all the PS docs that make up the GMPLS suite; and that role
also suggests that it be PS.

Kireeti.

Delivery-date: Wed, 11 Dec 2002 02:05:35 -0800
Date: Wed, 11 Dec 2002 02:04:25 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Khuzema Pithewan <[email-masked]>
cc: <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

> This draft addresses the overlay networks which UNI1.0 from OIF addresses.
> shouldn't we have one document addressing one problem. In fact, UNI1.0
> addresses it in-depth, so why there is a need of another document talking
> about overlay networks?

I guess you haven't really been following the CCAMP email, so I'll repeat:
(a) the OIF UNI1.0 is *not* a standard;
(b) just because the OIF is discussing something doesn't preclude the
    IETF from discussing it;
(c) the problems addressed are not quite the same.

If having two documents in this space is an issue, please make your
concerns known to the OIF.

Kireeti.

Delivery-date: Tue, 10 Dec 2002 15:20:51 -0800
From: "Ong, Lyndon" <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, Greg Bernstein <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Tue, 10 Dec 2002 15:19:44 -0800

Hi Kireeti,

Excuse my ignorance of the past history on this, but why are
the MPLS and GMPLS architecture documents Standards Track?
Most architecture documents I've seen have been Informational
(e.g., megaco, sigtran, iptel architectures) since these are
not specifications that can be tested through the usual IETF
process.

I have nothing against the GMPLS architecture, mind you, having 
added some text to it in the past.

Cheers,

Lyndon Ong

Delivery-date: Tue, 10 Dec 2002 14:05:21 -0800
To: [email-masked]
cc: Jean Philippe Vasseur <[email-masked]>, sachin laddha <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multi-Area TE Protocol Extensions 
Date: Tue, 10 Dec 2002 14:03:43 -0800
From: Yakov Rekhter <[email-masked]>

Dimitri,

> yakov, 
> 
> i think this i-d provides a fair amount of valuable 
> input thus wouldn't be just better to submit an 
> updated version (since the registers value should
> be updated anyway) also it fits imho in the context 
> of the ccamp even more largely than just for ma-te

I fully agree with you. I hope that the author of this i-d
would be kind enough to resubmit it.

Yakov.

> 
> thanks,
> - dimitri.
> 
> Yakov Rekhter wrote:
> > 
> > Dimitri,
> > 
> > > > this ID does not propose a mechanism to compute inter-area TE path
> > >
> > > well i would say that either none of them does it, or all of
> > > them, more accurately route exclusions are applicable to any
> > > mpls network where full computation of the ero is not performed
> > > before the LSP is signaled, implying thus a "scope" for computed
> > > path thus among other applicable to multiple areas - nevertheless
> > > i agree that a next version of this i-d should probably include
> > > an applicability section covering this in a bit more details (see
> > > also section 4.1 for an example -
> > >
> > > this said and as for any other input or i-d provided on constraint-
> > > passing (as well as path query, btw) lot of work is still needed to
> > > achieve a decent first step in this effort;
> > 
> > On the subject passing constraint, I'd like to mention
> > draft-kompella-mpls-rsvp-constraints-00.txt (expired, but I could
> > provide a copy upon request). It contains a fairly general mechanism
> > for passing constraints in RSVP.
> > 
> > Yakov.
> > 
> > >
> > > thanks,
> > > - dimitri.
> > >
> > > Jean Philippe Vasseur wrote:
> > > >
> > > > Hi Dimitri,
> > > >
> > > > cc'ing CCAMP - see in line,
> > > >
> > > > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > > > >jp,
> > > > >
> > > > >in fact the below list should simply be as follows for
> > > > >signalling-based methods: 1) constraint-passing 2) loose
> > > > >routing and 3) path query;
> > > > >
> > > > >and the for constraint-passing we have a several i-d's
> > > > >such as,
> > > > >
> > > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-ro
ute-
> > 01.txt
> > > > >
> > > >
> > > > this ID does not propose a mechanism to compute inter-area TE path
> > > >
> > > > >constraint passing may also be extended using the crank-
> > > > >back as listed below; the usage scenarios of these methods
> > > > >are described in the following:
> > > > >
> > > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-0
3.tx
> > t
> > > > >
> > > > >now probably it is worth spending some time in considering
> > > > >input coming from the tewg wrt to this effort, most of the
> > > > >input that you see listed above has been produced over the
> > > > >past year (and more) i can't imagine stepping in the protocol
> > > > >details without a clear consensus on what do we want to cover
> > > > >within the ccamp wg & w/o taking into account the tewg rec's
> > > > >(probably better to discuss this on the ccamp mailing list)
> > > >
> > > > Fully agree with you. Hopefully multi-area TE should be soon part of th
e
> > > > CCAMP charter.
> > > >
> > > > JP.
> > > >
> > > > >thanks,
> > > > >- dimitri.
> > > > >
> > > > >Jean Philippe Vasseur wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > > > >Hi,
> > > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > > > >"Initial requirements are given here for protocol support of the
> > > > > multi-area
> > > > > > >TE methods, which include needs to support
> > > > > > >
> > > > > > >*       path-computation-server (PCS) functionality [kompella, lee
,
> > > > > vasseur,
> > > > > > >te-qos-routing],
> > > > > > >*       query functionality [query, vasseur],
> > > > > > >*       crankback functionality [crankback],
> > > > > > >
> > > > > > >and, optionally,
> > > > > > >
> > > > > > >*       TE feedback functionality [feedback], and
> > > > > > >*       summary-LSA functionality [summary_lsa]."
> > > > > > >.
> > > > > > >I want to know whether cisco/juniper routers (standard ones) suppo
rts
> > > > > all of
> > > > > > >the above extension.
> > > > > > >or if not,how many.......or Whether router is supposed to support 
how
> > many
> > > > > > >...
> > > > > >
> > > > > > I do not think any vendor supports all the method mentioned above, 
but
> > just
> > > > > > a subset. If you are running a network, your feed-backs on your pre
ferr
> > ed
> > > > > > method is very welcome.
> > > > > >
> > > > > > JP.
> > > > > >
> > > > > > >Regards,
> > > > > > >---Sachin
> > > > >
> > > > >--
> > > > >Papadimitriou Dimitri
> > > > >E-mail : [email-masked]
> > > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > > >E-mail : [email-masked]
> > > > >Public : http://psg.com/~dpapadimitriou/
> > > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> > >
> > > --
> > > Papadimitriou Dimitri
> > > E-mail : [email-masked]
> > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > E-mail : [email-masked]
> > > Public : http://psg.com/~dpapadimitriou/
> > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> > >
> 
> -- 
> Papadimitriou Dimitri 
> E-mail : [email-masked] 
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 10 Dec 2002 13:12:21 -0800
Date: Tue, 10 Dec 2002 22:14:24 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Yakov Rekhter <[email-masked]>
Cc: Jean Philippe Vasseur <[email-masked]>, sachin laddha <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multi-Area TE Protocol Extensions

yakov, 

i think this i-d provides a fair amount of valuable 
input thus wouldn't be just better to submit an 
updated version (since the registers value should
be updated anyway) also it fits imho in the context 
of the ccamp even more largely than just for ma-te

thanks,
- dimitri.

Yakov Rekhter wrote:
> 
> Dimitri,
> 
> > > this ID does not propose a mechanism to compute inter-area TE path
> >
> > well i would say that either none of them does it, or all of
> > them, more accurately route exclusions are applicable to any
> > mpls network where full computation of the ero is not performed
> > before the LSP is signaled, implying thus a "scope" for computed
> > path thus among other applicable to multiple areas - nevertheless
> > i agree that a next version of this i-d should probably include
> > an applicability section covering this in a bit more details (see
> > also section 4.1 for an example -
> >
> > this said and as for any other input or i-d provided on constraint-
> > passing (as well as path query, btw) lot of work is still needed to
> > achieve a decent first step in this effort;
> 
> On the subject passing constraint, I'd like to mention
> draft-kompella-mpls-rsvp-constraints-00.txt (expired, but I could
> provide a copy upon request). It contains a fairly general mechanism
> for passing constraints in RSVP.
> 
> Yakov.
> 
> >
> > thanks,
> > - dimitri.
> >
> > Jean Philippe Vasseur wrote:
> > >
> > > Hi Dimitri,
> > >
> > > cc'ing CCAMP - see in line,
> > >
> > > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > > >jp,
> > > >
> > > >in fact the below list should simply be as follows for
> > > >signalling-based methods: 1) constraint-passing 2) loose
> > > >routing and 3) path query;
> > > >
> > > >and the for constraint-passing we have a several i-d's
> > > >such as,
> > > >
> > > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-
> 01.txt
> > > >
> > >
> > > this ID does not propose a mechanism to compute inter-area TE path
> > >
> > > >constraint passing may also be extended using the crank-
> > > >back as listed below; the usage scenarios of these methods
> > > >are described in the following:
> > > >
> > > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.tx
> t
> > > >
> > > >now probably it is worth spending some time in considering
> > > >input coming from the tewg wrt to this effort, most of the
> > > >input that you see listed above has been produced over the
> > > >past year (and more) i can't imagine stepping in the protocol
> > > >details without a clear consensus on what do we want to cover
> > > >within the ccamp wg & w/o taking into account the tewg rec's
> > > >(probably better to discuss this on the ccamp mailing list)
> > >
> > > Fully agree with you. Hopefully multi-area TE should be soon part of the
> > > CCAMP charter.
> > >
> > > JP.
> > >
> > > >thanks,
> > > >- dimitri.
> > > >
> > > >Jean Philippe Vasseur wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > > >Hi,
> > > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > > >"Initial requirements are given here for protocol support of the
> > > > multi-area
> > > > > >TE methods, which include needs to support
> > > > > >
> > > > > >*       path-computation-server (PCS) functionality [kompella, lee,
> > > > vasseur,
> > > > > >te-qos-routing],
> > > > > >*       query functionality [query, vasseur],
> > > > > >*       crankback functionality [crankback],
> > > > > >
> > > > > >and, optionally,
> > > > > >
> > > > > >*       TE feedback functionality [feedback], and
> > > > > >*       summary-LSA functionality [summary_lsa]."
> > > > > >.
> > > > > >I want to know whether cisco/juniper routers (standard ones) supports
> > > > all of
> > > > > >the above extension.
> > > > > >or if not,how many.......or Whether router is supposed to support how
> many
> > > > > >...
> > > > >
> > > > > I do not think any vendor supports all the method mentioned above, but
> just
> > > > > a subset. If you are running a network, your feed-backs on your preferr
> ed
> > > > > method is very welcome.
> > > > >
> > > > > JP.
> > > > >
> > > > > >Regards,
> > > > > >---Sachin
> > > >
> > > >--
> > > >Papadimitriou Dimitri
> > > >E-mail : [email-masked]
> > > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > >E-mail : [email-masked]
> > > >Public : http://psg.com/~dpapadimitriou/
> > > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> >

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 10 Dec 2002 12:18:08 -0800
To: [email-masked]
cc: Jean Philippe Vasseur <[email-masked]>, sachin laddha <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multi-Area TE Protocol Extensions 
Date: Tue, 10 Dec 2002 12:15:46 -0800
From: Yakov Rekhter <[email-masked]>

Dimitri,

> > this ID does not propose a mechanism to compute inter-area TE path
> 
> well i would say that either none of them does it, or all of
> them, more accurately route exclusions are applicable to any 
> mpls network where full computation of the ero is not performed 
> before the LSP is signaled, implying thus a "scope" for computed
> path thus among other applicable to multiple areas - nevertheless
> i agree that a next version of this i-d should probably include
> an applicability section covering this in a bit more details (see
> also section 4.1 for an example -
> 
> this said and as for any other input or i-d provided on constraint-
> passing (as well as path query, btw) lot of work is still needed to
> achieve a decent first step in this effort; 

On the subject passing constraint, I'd like to mention
draft-kompella-mpls-rsvp-constraints-00.txt (expired, but I could
provide a copy upon request). It contains a fairly general mechanism
for passing constraints in RSVP.

Yakov.

> 
> thanks,
> - dimitri.
> 
> Jean Philippe Vasseur wrote:
> > 
> > Hi Dimitri,
> > 
> > cc'ing CCAMP - see in line,
> > 
> > At 17:45 10/12/2002 +0100, [email-masked] wrote:
> > >jp,
> > >
> > >in fact the below list should simply be as follows for
> > >signalling-based methods: 1) constraint-passing 2) loose
> > >routing and 3) path query;
> > >
> > >and the for constraint-passing we have a several i-d's
> > >such as,
> > >
> > >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-
01.txt
> > >
> > 
> > this ID does not propose a mechanism to compute inter-area TE path
> > 
> > >constraint passing may also be extended using the crank-
> > >back as listed below; the usage scenarios of these methods
> > >are described in the following:
> > >
> > >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.tx
t
> > >
> > >now probably it is worth spending some time in considering
> > >input coming from the tewg wrt to this effort, most of the
> > >input that you see listed above has been produced over the
> > >past year (and more) i can't imagine stepping in the protocol
> > >details without a clear consensus on what do we want to cover
> > >within the ccamp wg & w/o taking into account the tewg rec's
> > >(probably better to discuss this on the ccamp mailing list)
> > 
> > Fully agree with you. Hopefully multi-area TE should be soon part of the
> > CCAMP charter.
> > 
> > JP.
> > 
> > >thanks,
> > >- dimitri.
> > >
> > >Jean Philippe Vasseur wrote:
> > > >
> > > > Hi,
> > > >
> > > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > > >Hi,
> > > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > > >"Initial requirements are given here for protocol support of the
> > > multi-area
> > > > >TE methods, which include needs to support
> > > > >
> > > > >*       path-computation-server (PCS) functionality [kompella, lee,
> > > vasseur,
> > > > >te-qos-routing],
> > > > >*       query functionality [query, vasseur],
> > > > >*       crankback functionality [crankback],
> > > > >
> > > > >and, optionally,
> > > > >
> > > > >*       TE feedback functionality [feedback], and
> > > > >*       summary-LSA functionality [summary_lsa]."
> > > > >.
> > > > >I want to know whether cisco/juniper routers (standard ones) supports
> > > all of
> > > > >the above extension.
> > > > >or if not,how many.......or Whether router is supposed to support how 
many
> > > > >...
> > > >
> > > > I do not think any vendor supports all the method mentioned above, but 
just
> > > > a subset. If you are running a network, your feed-backs on your preferr
ed
> > > > method is very welcome.
> > > >
> > > > JP.
> > > >
> > > > >Regards,
> > > > >---Sachin
> > >
> > >--
> > >Papadimitriou Dimitri
> > >E-mail : [email-masked]
> > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > >E-mail : [email-masked]
> > >Public : http://psg.com/~dpapadimitriou/
> > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> 
> -- 
> Papadimitriou Dimitri 
> E-mail : [email-masked] 
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> 

Delivery-date: Tue, 10 Dec 2002 11:42:01 -0800
Date: Tue, 10 Dec 2002 20:43:27 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Jean Philippe Vasseur <[email-masked]>
Cc: sachin laddha <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multi-Area TE Protocol Extensions

jp,

> this ID does not propose a mechanism to compute inter-area TE path

well i would say that either none of them does it, or all of
them, more accurately route exclusions are applicable to any 
mpls network where full computation of the ero is not performed 
before the LSP is signaled, implying thus a "scope" for computed
path thus among other applicable to multiple areas - nevertheless
i agree that a next version of this i-d should probably include
an applicability section covering this in a bit more details (see
also section 4.1 for an example -

this said and as for any other input or i-d provided on constraint-
passing (as well as path query, btw) lot of work is still needed to
achieve a decent first step in this effort; 

thanks,
- dimitri.

Jean Philippe Vasseur wrote:
> 
> Hi Dimitri,
> 
> cc'ing CCAMP - see in line,
> 
> At 17:45 10/12/2002 +0100, [email-masked] wrote:
> >jp,
> >
> >in fact the below list should simply be as follows for
> >signalling-based methods: 1) constraint-passing 2) loose
> >routing and 3) path query;
> >
> >and the for constraint-passing we have a several i-d's
> >such as,
> >
> >http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt
> >
> 
> this ID does not propose a mechanism to compute inter-area TE path
> 
> >constraint passing may also be extended using the crank-
> >back as listed below; the usage scenarios of these methods
> >are described in the following:
> >
> >http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt
> >
> >now probably it is worth spending some time in considering
> >input coming from the tewg wrt to this effort, most of the
> >input that you see listed above has been produced over the
> >past year (and more) i can't imagine stepping in the protocol
> >details without a clear consensus on what do we want to cover
> >within the ccamp wg & w/o taking into account the tewg rec's
> >(probably better to discuss this on the ccamp mailing list)
> 
> Fully agree with you. Hopefully multi-area TE should be soon part of the
> CCAMP charter.
> 
> JP.
> 
> >thanks,
> >- dimitri.
> >
> >Jean Philippe Vasseur wrote:
> > >
> > > Hi,
> > >
> > > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > > >Hi,
> > > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > > >"Initial requirements are given here for protocol support of the
> > multi-area
> > > >TE methods, which include needs to support
> > > >
> > > >*       path-computation-server (PCS) functionality [kompella, lee,
> > vasseur,
> > > >te-qos-routing],
> > > >*       query functionality [query, vasseur],
> > > >*       crankback functionality [crankback],
> > > >
> > > >and, optionally,
> > > >
> > > >*       TE feedback functionality [feedback], and
> > > >*       summary-LSA functionality [summary_lsa]."
> > > >.
> > > >I want to know whether cisco/juniper routers (standard ones) supports
> > all of
> > > >the above extension.
> > > >or if not,how many.......or Whether router is supposed to support how many
> > > >...
> > >
> > > I do not think any vendor supports all the method mentioned above, but just
> > > a subset. If you are running a network, your feed-backs on your preferred
> > > method is very welcome.
> > >
> > > JP.
> > >
> > > >Regards,
> > > >---Sachin
> >
> >--
> >Papadimitriou Dimitri
> >E-mail : [email-masked]
> >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> >E-mail : [email-masked]
> >Public : http://psg.com/~dpapadimitriou/
> >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> >Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 10 Dec 2002 09:40:23 -0800
Date: Tue, 10 Dec 2002 12:36:10 -0500
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Multi-Area TE Protocol Extensions
Cc: sachin laddha <[email-masked]>, [email-masked], [email-masked]

Hi Dimitri,

cc'ing CCAMP - see in line,

At 17:45 10/12/2002 +0100, [email-masked] wrote:
>jp,
>
>in fact the below list should simply be as follows for
>signalling-based methods: 1) constraint-passing 2) loose
>routing and 3) path query;
>
>and the for constraint-passing we have a several i-d's
>such as,
>
>http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-01.txt 
>

this ID does not propose a mechanism to compute inter-area TE path

>constraint passing may also be extended using the crank-
>back as listed below; the usage scenarios of these methods
>are described in the following:
>
>http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt
>
>now probably it is worth spending some time in considering
>input coming from the tewg wrt to this effort, most of the
>input that you see listed above has been produced over the
>past year (and more) i can't imagine stepping in the protocol
>details without a clear consensus on what do we want to cover
>within the ccamp wg & w/o taking into account the tewg rec's
>(probably better to discuss this on the ccamp mailing list)

Fully agree with you. Hopefully multi-area TE should be soon part of the 
CCAMP charter.

JP.

>thanks,
>- dimitri.
>
>Jean Philippe Vasseur wrote:
> >
> > Hi,
> >
> > At 13:53 10/12/2002 +0530, sachin laddha wrote:
> > >Hi,
> > >'draft-ash-multi-area-te-reqmts-01.txt' stated in section 5 as
> > >"Initial requirements are given here for protocol support of the 
> multi-area
> > >TE methods, which include needs to support
> > >
> > >*       path-computation-server (PCS) functionality [kompella, lee, 
> vasseur,
> > >te-qos-routing],
> > >*       query functionality [query, vasseur],
> > >*       crankback functionality [crankback],
> > >
> > >and, optionally,
> > >
> > >*       TE feedback functionality [feedback], and
> > >*       summary-LSA functionality [summary_lsa]."
> > >.
> > >I want to know whether cisco/juniper routers (standard ones) supports 
> all of
> > >the above extension.
> > >or if not,how many.......or Whether router is supposed to support how many
> > >...
> >
> > I do not think any vendor supports all the method mentioned above, but just
> > a subset. If you are running a network, your feed-backs on your preferred
> > method is very welcome.
> >
> > JP.
> >
> > >Regards,
> > >---Sachin
>
>--
>Papadimitriou Dimitri
>E-mail : [email-masked]
>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
>E-mail : [email-masked]
>Public : http://psg.com/~dpapadimitriou/
>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Mon, 09 Dec 2002 08:15:29 -0800
content-class: urn:content-classes:message
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Mon, 9 Dec 2002 17:10:19 +0100
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>

> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
>=20
> Please indicate your opinion by replying to this email.

I support this draft as a WG document.

JL Le Roux

E-mail : [email-masked]
Address: Ft R&D Av Pierre Marzin 22300 Lannion France
Phone  : +33 2 96 05 30 20

Delivery-date: Mon, 09 Dec 2002 01:07:17 -0800
From: Manoj Agiwal <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Message ID generation
Date: Mon, 9 Dec 2002 03:03:42 -0600 

Hi ,
      These are the lines from Refresh Reduction RFC 
      " Message identification and acknowledgment is done on a per hop
basis. All types of MESSAGE_ID objects contain a                   message
identifier. The identifier MUST be unique on a per object generator's IP
address basis 
       In case of Gmpls if Per object generators IP address is control
channel address then Message ID should be unique 
       for each control channel address , or should it be unique per
Neighbour .

       i.e. If there are two control channel address in a Node that goes to
the same neighbor in the data plane , the Message Id 
       generation should be unique per control channel address or Message Id
generation should be unique for each neighbor .

Regards ,
Manoj

Delivery-date: Sun, 08 Dec 2002 22:44:07 -0800
From: Khuzema Pithewan <[email-masked]>
To: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Mon, 9 Dec 2002 00:39:14 -0600 

Hi,

This draft addresses the overlay networks which UNI1.0 from OIF addresses.
shouldn't we have one document addressing one problem. In fact, UNI1.0
addresses it in-depth, so why there is a need of another document talking
about overlay networks?

Khuzema

Delivery-date: Sun, 08 Dec 2002 08:38:45 -0800
From: Bala Rajagopalan <[email-masked]>
To: [email-masked]
Subject: RE: Overlay draft and OIF history...
Date: Sun, 8 Dec 2002 11:32:57 -0500 

I agree with Deborah's conclusion: it's worthwhile
to consider the swallow draft further in the WG.

There has been some concern expressed about confusion in
the industry w.r.t this draft and the existing
UNI spec (OIF) and the ongoing NNI work. I'm personally
not too concerned about this. My observation is that
the control plane standards work  has outpaced 
deployment significantly. The present draft adds
to the set of available solutions, addressing a specific
application scenario. In doing so, it  does not
take away the rationale behind the UNI or the NNI work,
which are based on specific SP requirements.
It now remains for the SPs to evaluate the available
choices and deploy the solutions that meet their needs.

regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Pl.
Ocean Port, NJ 07757
USA
Ph: +1-732-923-4237
Email: [email-masked]

> -----Original Message-----
> From: Brungard, Deborah A, ALASO [mailto:[email-masked]]
> Sent: Saturday, December 07, 2002 12:18 AM
> To: Greg Bernstein; [email-masked]
> Subject: RE: Overlay draft and OIF history...
> 
> 
> The support of non-IP addresses was to support non-IP clients 
> e.g. either within the network (I-NNI) or over the public UNI 
> (e.g. ATM equipment with SONET interfaces, SONET equipment). 
> A multi-service architecture.
>  
> Overlay and peer terminology has become very confused between 
> IETF/OIF/ITU. In ITU-T, we discuss Public UNI, E-NNI, I-NNI. 
> Most of our effort in ASON is to distinguish E-NNI/Public UNI 
> from I-NNI as we (ITU) need to distinguish what is needed to 
> support inter-operability (inter-domains/inter-operators) 
> without constraining our choices for intra-domain 
> implementations. For E-NNI and UNI, as already noted, it is 
> untrusted i.e. overlay. For I-NNI, ASON does not limit an 
> operator's choice - it is considered intra-domain. The 
> current definition of the I-NNI is based on peer but there is 
> no intention to limit an operator's choice for intra-domain - 
> either or both overlay and peer models may be used. And for 
> all three, the definitions are soft depending on the level of 
> trust/applications.
>  
> Early discussion on the exploder also discussed overlay and 
> peer in reference to the transport layers e.g. IP/SONET. 
> Because of the multiple possibilities which network equipment 
> can support and use of the equipment in a network 
> (P-UNI/E-NNI/I-NNI), ITU-T defines separately the layers as 
> overlay. For definition. Again, no intention to drive 
> specific implementations.
>  
> Considering the overlay-draft applications, it is appropriate 
> as an IETF work item.
>  
> Deborah
>  
>  
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Greg Bernstein
> Sent: Wednesday, December 04, 2002 11:10 AM
> To: [email-masked]
> Subject: Overlay draft and OIF history...
> 
> 
> 
> Hi all, it's great to see a draft and this much support for a 
> UNI model which seems necessary when offering support out to 
> the edge of "connection oriented services".  
> 
>  
> 
> This is very similar to the original OIF UNI work, until a 
> huge issue arose over supported address types.  The initial 
> thrust was for only IP address types (v4 and v6).  However 
> this didn't fly with a bunch of folks with installed networks 
> using NSAPs.  However it was never really clear, to me, that 
> NSAPs were needed, i.e., the optical control plane was to be 
> IP based and any other "addresses" could be viewed as "names" 
> and translated when and if necessary.  Note that all previous 
> SONET/SDH standards specified OSI stacks on the "in band" 
> data communications channels (if you were wondering how we 
> got into this mess).
> 
>  
> 
> This is an area that could use a bit of thinking since from 
> the ITU-T perspective other (non IP) address are desirable.  
> And it would be nice to harmonize the work at the various 
> standards bodies.
> 
>  
> 
> Greg B.
> 
>  
> 
> Greg Bernstein, Grotto-Networking
> 
>  
> 
> 

Delivery-date: Sat, 07 Dec 2002 07:37:12 -0800
content-class: urn:content-classes:message
Subject: RE: J0/J1 encoding issues
Date: Sat, 7 Dec 2002 10:33:53 -0500
From: "Brungard, Deborah A, ALASO" <[email-masked]>
To: "Maarten Vissers" <[email-masked]>, "John Drake" <[email-masked]>
Cc: "ccamp " <[email-masked]>

Just to clarify, most of this discussion has been focused on G.831 for =
inter-operator use. G.831 also defines for intra-domain an operator is =
free to choose, and defines three basic types though there is no =
intention to constrain an operator's choices. And for inter-operator, =
use is based on mutual operator agreements. Any format can be used. The =
E.164 has not been so popular, most inter-ops are using the G.831 =
appendix. T1M1 (USA) has multiple other uses defined.

The other clarification is that the use of the path trace as defined =
today in SDH/SONET is for in-service path verification - from a =
termination point to another termination point. Discovery is a different =
application - it is pre-service e.g. discovery of "potential" =
connections. I have already discussed previously on both the IETF =
exploder and ITU-T exploder my concerns that we need to understand the =
scenario of use before we can say one implementation is valid or not. =
Use will depend on intra-domain or inter-domain, discovery of =
termination (TTP) or connection (CTP), processes (pre-service, =
in-service). Also, if supports intermediate legacy equipment, use of =
monitors, use of legacy components/firmware/software.

LMP bootstrap provides multiple options, depending on an operator's =
preference. I'd suggest to help us understand the different options =
perhaps doing an applicability draft?

Deborah

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 5:01 AM
To: John Drake
Cc: 'ccamp '
Subject: Re: J0/J1 encoding issues

John,

Here is a copy of the text of section 3/G.831 which defines the Access =
Point
Identifier that is transmitted in the Trail Trace Identifiers (J0, J1, =
J2 in
SDH):

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D section 3/G.831 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

3	SDH access point identification

An essential requirement for successful management of SDH networks =
incorporating
features such as point-to-point and point-to-multipoint paths is a =
unique means
of identifying significant points in the network, e.g. access points. =
The
features of Access Point Identifiers (APIs) are:

- each access point identifier must be globally unique in its layer =
network;
- where it may be expected that the access point may be required for =
path
  set-up across an inter-operator boundary, the access point identifier
  must be available to other network operators;
- the access point identifier should not change while the access point
  remains in existence;
- the access point identifier should be able to identify the country
  and network operator which is responsible for routing to and from the
  access point;
- the set of all access point identifiers belonging to a single
  administrative layer network should form a single access point
  identification scheme;
- the scheme of access point identifiers for each administrative
  layer network can be independent from the scheme in any other
  administrative layer network.

It is recommended that the VC-11, VC-12, VC-2, VC-2-xc, VC-3, VC-4 and =
VC-4-xc
should each have the access point identification scheme bases on a =
tree-like
format to aid routing control search algorithms. The access point =
identifier
should be globally unambiguous.

The API shall begin with either the country code as defined in ITU-T =
E.164 (one,
two or three numeric characters) or, the three alphabetic character =
country code
as defined in ISO 3166.

The remainder of the API characters that follow the country code shall =
be a
matter for the organization to whom the country code has been assigned, =
provided
that uniqueness is guaranteed. These characters may be any alphanumeric
characters as defined in ITU-T T.50 (International Reference Version - =
7-bit
coded character set for information interchange).

The alphanumeric character set consists of the characters "a" to "z", =
"A" to
"Z", and "0" to "9".
In the case where the API uses less than fifteen characters, the API =
will be
padded (extended) with the T.50 "NUL" character to get a fifteen byte =
character
string.
=20
For interworking with equipment developed prior to this version of the
Recommendation that may use the T.50 space as a padding character, new =
equipment
should be able to generate T.50 "SPACE" padding characters as an option.

A similar access and test point identification scheme is required for =
the
section layer to support point-to-point and point-to-multipoint paths =
and wide
area multiplexors as used in satellite subnetworks.

The byte allocations for the transmission of the access point identifier =
at the
section layer, higher?order path layer and lower-order path layer are =
given in
ITU-T G.707.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D end of section =
3/G.831 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

Furthermore, there is the ANSI specification in "Structure and =
Representation of
Trace
Message Formats for the North American Telecommunications System =
T1.269-2000".=20
This standard specifies the National Segment portion of the API.

As you can see G.831 restricts the character set to the alfanumeric =
symbols
a..z, A..Z and 0..9 with NUL (or SPACE) padding at the end.

Regards,

Maarten
PS. Older SDH equipment developed before the first version of G.831 =
(08/96) was
often less restrictive in the supported character set, and allowed other
printable and non-printable characters. This caused a lot of headaches =
when
trying to discover why there was a Trace Identfier Mismatch (TIM) alarm; =
the
Expected Trace Identifier and the Received Trace Identifier looked the =
same on
the GUI. Only when the GUI supported a HEX presentation mode, it was =
possible to
discover the non-printable characters that were causing the mismatch.

Regards,

Maarten

John Drake wrote:
>=20
> Jonathan S,
>=20
> Okay, now you've really confused me.
>=20
> In this e-mail, you seem to be saying that any T.50 character is valid =
in
> J0/J1/J2.  However, in your earlier e-mail, which is included way down =
at
> the bottom of this e-mail, you say "The requirements for J0/J1/J2 =
(found
> in G.707) state the trace message payload must utilize the printable
> characters
> defined in T.50".
>=20
> Which is the real requirement?
>=20
> If it is the former, then there is no issue with
> draft-lang-ccamp-lmp-bootstrap.
> I.e., T.50 defines all possible 7 bit values and
> draft-lang-ccamp-lmp-bootstrap
> specifies that 7 bits of information are to be carried in each octet, =
so by
> definition every possible seven bit value is a valid T.50 character.
>=20
> If it is the latter, then it doesn't sound as though the latest draft
> G.7714.1
> is any more conformant than draft-lang-ccamp-lmp-bootstrap is.
>=20
> Thanks,
>=20
> John
>=20
>=20
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2002 8:49 AM
> To: John Drake
> Cc: Razdan, Rajender; Jonathan Lang; 'Brungard, Deborah A, ALASO ';
> 'ccamp '
> Subject: Re: J0/J1 encoding issues
>=20
> John,
>=20
> There are a number of T.50 characters that are non-E.164 and
> non-alphabetic.  The use of a non-E.164 and non-alphabetic character =
in
> the format defined by draft G.7714.1 is to provide backward
> compatability with the country-specific and carrier-specific encodings
> described in G.831.
>=20
> Jonathan Sadler
>=20
> John Drake wrote:
> >
> > Rajender,
> >
> > Why don't you send a pointer to the draft, so that any interested =
party
> can
> > take a look at it and decide for themselves?
> >
> > As I understand it, the  version presented at the Experts Meeting in
> Ottawa
> > did not comply with T.50 requirements, and it is only the newest =
draft
> > version that attempts to address the T.50 requirements.  It does so =
by
> > re-defining current Jx processing with a new format that "uses a =
non-E.164
> > and non-alphabetic character in the first byte of the message".
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Razdan, Rajender [mailto:[email-masked]]
> > Sent: Monday, November 25, 2002 8:55 AM
> > To: John Drake; [email-masked]
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: RE: J0/J1 encoding issues
> >
> > John,
> >
> >     I don't subscribe to the ccamp mailing list, and so haven't had =
a
> chance
> > to comment on the LMP drafts till now. The discussion on J0/J1 =
issues was
> > forwarded to me by Jonathan Sadler. As the editor of Draft G.7714.1, =
I was
> > quite distressed to read about your understanding that none of the =
work
> > aimed
> > at G.7714.1 is compatible with the T.50 requirement. I don't know =
how you
> > got
> > that absolutely wrong impression. In fact, compatibility with the =
T.50
> > requirement, as dictated by ITU Rec. G.707, has been the most =
important
> > consideration for us in our defining J0/J1/J2 discovery mechanisms. =
The
> > current
> > draft of G.7714.1 clearly states this. I FULLY agree with Jonathan =
Sadler
> > that
> > the LMP work should also be consistent with this requirement.
> >
> > Regards,
> > Rajender Razdan
> >
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Monday, November 25, 2002 11:24 AM
> > To: [email-masked]
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: RE: J0/J1 encoding issues
> >
> > Jonathan,
> >
> > The various Test transport mechanisms that are currently defined in
> > draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to input =
from
> > various carriers and organizations such as the OIF.  The fact that =
the
> > individual carriers have different requirements for the contents of =
the
> > various SDH/SONET overheads is also consistent with my reading of
> Deborah's
> > recent e-mail on this topic.
> >
> > Since one of the transport mechanisms, the J0/J1/J2 trace =
correlation,
> > allows the transport of T.50 characters, I think we're done wrt
> > draft-ietf-ccamp-lmp-test-sonet-sdh.
> >
> > Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding that none =
of the
> > work aimed at G.7714.1 is compatible with the T.50 requirement.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Thursday, November 21, 2002 8:23 PM
> > To: John Drake
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> >
> > John -
> >
> > I think you forgot what my original message said.  It stated:
> >
> > > > As mentioned at the CCAMP meeting, the SDH trace bytes =
(J0/J1/J2)
> > > > have restrictions not only on the length of a trace message and =
on
> > > > the bits usable in a octet, but also on whether the payload in =
the
> > > > message uses printable ASCII characters.
> > > >
> > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > message payload must utilize the printable characters defined in
> > > > T.50.  Two current LMP drafts =
(draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > consistant with this requirement.
> >
> > I fail to see what is incorrect with the above.
> >
> > While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
> > J0/J1/J2 that fall within the requirements of G.707, it also =
includes
> > methods that don't.  This situation SHOULD be resolved to provide =
the
> > greatest amount of interoperability while reducing the number of =
trace
> > methods that need to be implemented.
> >
> > I'm glad to see we agree on the fact that =
draft-lang-ccamp-lmp-bootstrap
> > only provides methods that fall outside the requirements of G.707.  =
This
> > situation MUST be resolved.
> >
> > Jonathan Sadler
> >
> > John Drake wrote:
> > >
> > > Wouldn't it be more precise to say that it is an issue with
> > > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Thursday, November 21, 2002 12:49 PM
> > > To: John Drake
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: Re: J0/J1 encoding issues
> > >
> > > John -
> > >
> > > draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> > > Therefore, it is an issue.
> > >
> > > Jonathan Sadler
> > >
> > > John Drake wrote:
> > > >
> > > > Is it the case that if one chooses to use J0/J1/J2 Trace =
Correlation,
> > then
> > > > Jonathan Sadler's issue is a non-issue?
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Lang
> > > > Sent: Thursday, November 21, 2002 8:56 AM
> > > > To: 'Brungard, Deborah A, ALASO '; [email-masked] =
';
> > > > 'ccamp '
> > > > Subject: FW: J0/J1 encoding issues
> > > >
> > > > Deborah,
> > > >   Thanks for the note. The option that Jonathan mentioned is one =
of a
> > > couple
> > > > options we define for Jx. We defined other options to
> > > > interwork with existing equipment without requiring any changes =
to
> > > > existing encodings (this would support both C1 and T.50 =
requirements).
> > > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > > Correlation. We welcome additional comments from you and others =
at
> > > > T1X1.5/ITU.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > -----Original Message-----
> > > > From: Brungard, Deborah A, ALASO
> > > > To: [email-masked]; ccamp
> > > > Sent: 11/21/2002 5:22 AM
> > > > Subject: RE: J0/J1 encoding issues
> > > >
> > > > As Jonathan says, the current G.707 is using T.50. And there's =
more.
> > > > Example, for J0, one currently needs to support:
> > > > - previously defined C1 (repeating one-byte)
> > > > - T.50 (with format of G.707)
> > > > - no J0 (for equipment not supporting).
> > > >
> > > > So already we have defined multiple applications for this byte. =
Not to
> > > > say, there will be not any new ones. Even ITU knows, it never is
> > > > final;-)
> > > >
> > > > For supporting LMP's use, we need to understand the scenarios of =
use
> > > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > > inter-operator, applied for equipment installation verification =
or
> > > > service connection verification, etc. And hardware implications.
> > > >
> > > > Actually, G.831 defines multiple uses depending if inter or =
intra -
> > > > including for intra-operator, support of routing/path set-up =
(and
> G.831
> > > > was done years ago).
> > > >
> > > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, =
contribute
> the
> > > > proposal for the meeting and we can start the discussion. The =
next
> ITU-T
> > > > meeting is in January. If the LMP editors need help on our =
T1X1.5
> > > > process, just ask.
> > > >
> > > > Deborah
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > Sent: Monday, November 18, 2002 7:59 PM
> > > > To: ccamp
> > > > Subject: J0/J1 encoding issues
> > > >
> > > > All -
> > > >
> > > > As mentioned at the CCAMP meeting, the SDH trace bytes =
(J0/J1/J2)
> > > > have restrictions not only on the length of a trace message and =
on
> > > > the bits usable in a octet, but also on whether the payload in =
the
> > > > message uses printable ASCII characters.
> > > >
> > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > message payload must utilize the printable characters defined in
> > > > T.50.  Two current LMP drafts =
(draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > consistant with this requirement.
> > > >
> > > > This message is being sent to document this issue.  It is not a
> > > > statement that no other issues exist -- I expect that the =
appropriate
> > > > experts in the ITU will review the rest of these two drafts and
> > > > provide appropriate comment.
> > > >
> > > > Jonathan Sadler
> >
> > (I disclaim the disclaimer that follows this message.)
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > The information contained in this message may be privileged
> > and confidential and protected from disclosure.  If the
> > reader of this message is not the intended recipient, or an
> > employee or agent responsible for delivering this message to
> > the intended recipient, you are hereby notified that any
> > reproduction, dissemination or distribution of this
> > communication is strictly prohibited. If you have received
> > this communication in error, please notify us immediately by
> > replying to the message and deleting it from your computer.
> >
> > Thank you.
> > Tellabs
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
>=20
> Thank you.
> Tellabs
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Delivery-date: Fri, 06 Dec 2002 21:22:19 -0800
content-class: urn:content-classes:message
Subject: RE: Overlay draft and OIF history...
Date: Sat, 7 Dec 2002 00:17:46 -0500
From: "Brungard, Deborah A, ALASO" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, <[email-masked]>

The support of non-IP addresses was to support non-IP clients e.g. =
either within the network (I-NNI) or over the public UNI (e.g. ATM =
equipment with SONET interfaces, SONET equipment). A multi-service =
architecture.
=20
Overlay and peer terminology has become very confused between =
IETF/OIF/ITU. In ITU-T, we discuss Public UNI, E-NNI, I-NNI. Most of our =
effort in ASON is to distinguish E-NNI/Public UNI from I-NNI as we (ITU) =
need to distinguish what is needed to support inter-operability =
(inter-domains/inter-operators) without constraining our choices for =
intra-domain implementations. For E-NNI and UNI, as already noted, it is =
untrusted i.e. overlay. For I-NNI, ASON does not limit an operator's =
choice - it is considered intra-domain. The current definition of the =
I-NNI is based on peer but there is no intention to limit an operator's =
choice for intra-domain - either or both overlay and peer models may be =
used. And for all three, the definitions are soft depending on the level =
of trust/applications.
=20
Early discussion on the exploder also discussed overlay and peer in =
reference to the transport layers e.g. IP/SONET. Because of the multiple =
possibilities which network equipment can support and use of the =
equipment in a network (P-UNI/E-NNI/I-NNI), ITU-T defines separately the =
layers as overlay. For definition. Again, no intention to drive specific =
implementations.
=20
Considering the overlay-draft applications, it is appropriate as an IETF =
work item.
=20
Deborah
=20
=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On =
Behalf Of Greg Bernstein
Sent: Wednesday, December 04, 2002 11:10 AM
To: [email-masked]
Subject: Overlay draft and OIF history...

Hi all, it's great to see a draft and this much support for a UNI model =
which seems necessary when offering support out to the edge of =
"connection oriented services". =20

=20

This is very similar to the original OIF UNI work, until a huge issue =
arose over supported address types.  The initial thrust was for only IP =
address types (v4 and v6).  However this didn't fly with a bunch of =
folks with installed networks using NSAPs.  However it was never really =
clear, to me, that NSAPs were needed, i.e., the optical control plane =
was to be IP based and any other "addresses" could be viewed as "names" =
and translated when and if necessary.  Note that all previous SONET/SDH =
standards specified OSI stacks on the "in band" data communications =
channels (if you were wondering how we got into this mess).

=20

This is an area that could use a bit of thinking since from the ITU-T =
perspective other (non IP) address are desirable.  And it would be nice =
to harmonize the work at the various standards bodies.

=20

Greg B.

=20

Greg Bernstein, Grotto-Networking

=20

Delivery-date: Fri, 06 Dec 2002 11:04:26 -0800
Date: Fri, 6 Dec 2002 11:02:21 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Jorge Pinto <[email-masked]>
cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-09.txt

Hi Jorge,

On Fri, 6 Dec 2002, Jorge Pinto wrote:

> I don't quite follow you on this mail... I'm not at all familiar
> with IETF procedures regarding document commenting, so this one got me
> thinking: I've posted a comment (addreseed to Ccamp, Kireeti an Yakov)
> on the last draft (...-extensions-9.txt), dated 4-12-2002.

The date is 4-dec-2002 :-) (I was confused for a second or two).

> I get the feeling that i should have waited for ccamp's WG Last Call
> Event regarding this draft, or my comment won't be analysed... or not

You don't need to wait for a WG Last Call to comment on a draft.
The Last Call is a last call for comments, though -- beyond the Last
Call, there would have to be a serious reason to change the document.
As the two week + two days WG Last Call was in August, I do not believe
that your comments will be applied to this document.

On the other hand, that doesn't mean that your comments will go
unanswered.

> (confused)... i get this feeling from the "no comments were received in
> the two week window soliciting comments" phrase on your last mail.

No comments were received from the OSPF WG, whom we informed about this
document to make sure they are aware of the situation, the changes
proposed to OSPF, and the impacts thereof.  Ideally (if the authors
have done due diligence), there should be no comments from the OSPF WG.

> IMHO the Last Call Event isn't a MUST, but with all the burocracy we
> see everyday (not here) it makes me wonder. Anyway, could someone (to
> free Kireeti from the "answer to moron" task) confirm to me that,
> besides the pathetic content, my comment will get the slightest
> attention of the WG? Thanks in advance,

The Last Call "event" is a MUST by IETF procedures.

However, we will try to get you an answer.  As for attention in the
WG, that's a two-edged sword -- be careful what you ask for :-)

Kireeti.

Delivery-date: Fri, 06 Dec 2002 10:46:34 -0800
Date: Fri, 6 Dec 2002 10:44:10 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Greg Bernstein <[email-masked]>
cc: <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi Greg,

On Fri, 6 Dec 2002, Greg Bernstein wrote:

> Hi it wasn't clear from this call whether this document would be standards
> track or informational.

Typically, calls for consensus don't state the targetted track, although
in my opinion all drafts should say so fairly early in their lives.

> Since this document is more in the vein of an architecture document.  I'd
> say it could only be an informational document.

How does that argument stand up in the light that the MPLS and GMPLS
architecture documents are standards track?

> It doesn't introduce any new
> functionality (rather just a proper subset of OIF UNI) and just details a
> possible deployment scenario using GMPLS protocols.

Not completely accurate: it modifies processing of RSVP messages, in
particular the ERO and RRO.  Therefore it should be standards track.

> Hence, I'm not for this being a working group document.  The deployment
> scenario outlined should be in the GMPLS architecture (informational)
> document.  I don't see enough content to warrant a separate document.

Noted.  I'd gotten the opposite impression from your earlier mail, so
I'll reverse that.

Thanks,
Kireeti.

Delivery-date: Fri, 06 Dec 2002 09:26:26 -0800
From: "Greg Bernstein" <[email-masked]>
To: <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Fri, 6 Dec 2002 09:23:21 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0027_01C29D09.1F3D9030
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi it wasn't clear from this call whether this document would be =
standards
track or informational.
Since this document is more in the vein of an architecture document.  =
I'd
say it could only be an informational document. It doesn't introduce any =
new
functionality (rather just a proper subset of OIF UNI) and just details =
a
possible deployment scenario using GMPLS protocols.

Hence, I'm not for this being a working group document.  The deployment
scenario outlined should be in the GMPLS architecture (informational)
document.  I don't see enough content to warrant a separate document.

Greg B.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf
Of Kireeti Kompella
Sent: Tuesday, December 03, 2002 11:39 AM
To: [email-masked]
Subject: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi,

This is a call for consensus to make the above document a CCAMP WG
document.  This call will end Dec 17, 2002.

Please indicate your opinion by replying to this email.

Thanks,
Kireeti.

------=_NextPart_000_0027_01C29D09.1F3D9030
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

------=_NextPart_000_0027_01C29D09.1F3D9030--

Delivery-date: Fri, 06 Dec 2002 08:07:14 -0800
From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Fri, 6 Dec 2002 11:05:45 -0500 

Hi Kireeti,

In terms of overlay and "call vs. connection", they are very much related. An overlay is simply a way to keep information from going from one network to another network. The "call" concept embodies that, but at the same time also adds a service concept to the signaling, as per what operators have requested. (People have concentrated on comparing overlay to UNI; I guess we have to remember that there is also the work on E-NNI). In terms of understanding the call concept, if you're familiar with the SS7 or ATM signaling, then call concept should be very familiar to you as well (it's been part of the telecom network for a long time). I'm not sure whether a clarification for this is needed, since we're all in the telecom industry and many of us have worked with either SS7 or ATM related signaling protocols before. Is this a bad assumption to make?

In terms of "IETF pursue its own standards track documents", of course this decision is up to us as IETF members to decide whether to create a standard for the overlay. However, we should concentrate on what makes the most sense for the industry. A side-note considering the relevance of the GMPLS work is that ITU is not talking about the IP network, but the transport network using this...

Related to your question about standards track vs. informational, the document was planned for standards track. However, as the request from ITU specifically says that there is a time constraint of Jan. '03, and as the standards track takes longer than what was required by the ITU-T, it was changed to informational. Kireeti you were kept in the loop during this process so should have been aware of this. 

For a position, I think the overlay issue has been resolved (and includes an additional component of supporting the service concept -- albeit all done in a different standards body) so should not need to be repeated here. But if IETF wants to repeat it and specify something different, than that can always be done based on the consensus of the body (regardless of whether it helps or hurts the industry)...

Zhi

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Friday, December 06, 2002 1:31 AM
To: Lin, Zhi-Wei (Zhi)
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi Zhi,

On Tue, 3 Dec 2002, Lin, Zhi-Wei (Zhi) wrote:

> Hi all,
>
> Actually the work been done in the ITU-T deals specifically with the overlay, at least the application that operators have identified as been important to them. These documents are planned to be consented at the Jan ITU-T meeting (G.7713.x series). ITU-T has communicated to the IETF regarding this work for some time now (I'm bad at remembering dates but you can probably trace back the emails or the liaison statements).

I'm probably confused, but I recall the issue that the liaison statement
raised as being "call and connection separation".  Perhaps that's the
same as overlay; if so, it would be useful to clarify that.

> In addition, I have submitted two I-Ds, one on requirements and another on protocol extensions needed to support the overlay. It is my understanding that the protocol extensions document has passed through IESG review and sent off to the RFC editors already?
>
> http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rqts-00.txt
>
> http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-04.txt

My understanding was that these documents were to be standards track;
I learned at in Atlanta that their status was changed to informational.
It would have been friendly to state the change on the mailing list for
everyone's benefit.

In any case, as they are to be informational, I think it makes sense
that the IETF pursue its own standards track documents for overlay mode
if it sees fit (i.e., a chartered work item, and rough consensus).  The
CCAMP WG has been careful (with help from delegates from the ITU :-))
not to tread on the ITU's standards jurisdiction in the course of
developing IETF standards; however in this case, the IETF is extending
(or clarifying) its own protocols, and this issue doesn't arise.  One
might ask if the ITU is treading on the IETF's toes in this matter,
but it's a bit late for that.

Zhi, you didn't actually indicate an opinion on the swallow draft.
I will assume you don't have one unless I get mail otherwise.

Thanks,
Kireeti.

Delivery-date: Fri, 06 Dec 2002 06:25:28 -0800
Date: Fri, 06 Dec 2002 09:02:43 -0500
From: Ron Bonica <[email-masked]>
Subject: WG Last Call: draft-ietf-ccamp-lmp-test-sonet-sdh-00
To: [email-masked]

Folks,

This message begins a Working Group last call on
draft-ietf-ccamp-lmp-test-sonet-sdh-00. Last call will end two weeks from
today, on December 20, 2002.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli

Delivery-date: Fri, 06 Dec 2002 02:33:25 -0800
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
Date: Fri, 6 Dec 2002 10:34:40 -0000
From: "Jorge Pinto" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Kireeti,

	I don't quite follow you on this mail... I'm not at all familiar with =
IETF procedures regarding document commenting, so this one got me =
thinking:
	I've posted a comment (addreseed to Ccamp, Kireeti an Yakov) on the =
last draft (...-extensions-9.txt), dated 4-12-2002. I get the feeling =
that i should have waited for ccamp's WG Last Call Event regarding this =
draft, or my comment won't be analysed... or not (confused)... i get =
this feeling from the "no comments were received in the two week window =
soliciting comments" phrase on your last mail.
	IMHO the Last Call Event isn't a MUST, but with all the burocracy we =
see everyday (not here) it makes me wonder. Anyway, could someone (to =
free Kireeti from the "answer to moron" task) confirm to me that, =
besides the pathetic content, my comment will get the slightest =
attention of the WG? Thanks in advance,

Jorge Pinto

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Sexta-feira, 6 de Dezembro de 2002 6:59
To: [email-masked]
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-09.txt

Hi All,

On Wed, 4 Dec 2002 [email-masked] wrote:

> 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		: OSPF Extensions in Support of Generalized MPLS
> 	Author(s)	: K. Kompella, Y. Rekhter
> 	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
> 	Pages		: 12
> 	Date		: 2002-12-3
>
> This document specifies encoding of extensions to the OSPF routing
> protocol in support of Generalized Multi-Protocol Label Switching.

The CCAMP WG Last Call for draft-ietf-ccamp-ospf-gmpls-extensions-08.txt
and for draft-ietf-ccamp-gmpls-routing-05.txt ended Aug 28, 2002; the
authors only got one comment on the former (a typo).  The new version
announced above fixes the typo, makes some minor formatting changes,
and spruces up the Security Considerations (essentially copied from
the OSPF TE doc).  The latter document is unchanged.

The OSPF WG was notified on Sept 30, 2002 that the above documents
finished CCAMP WG Last Call; no comments were received in the two
week window soliciting comments.

These documents will now be forwarded to the IESG as standards track
documents requesting an IETF Last Call.

Kireeti.

Delivery-date: Thu, 05 Dec 2002 23:00:08 -0800
Date: Thu, 5 Dec 2002 22:58:34 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: <[email-masked]>
cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-09.txt

Hi All,

On Wed, 4 Dec 2002 [email-masked] wrote:

> 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		: OSPF Extensions in Support of Generalized MPLS
> 	Author(s)	: K. Kompella, Y. Rekhter
> 	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
> 	Pages		: 12
> 	Date		: 2002-12-3
>
> This document specifies encoding of extensions to the OSPF routing
> protocol in support of Generalized Multi-Protocol Label Switching.

The CCAMP WG Last Call for draft-ietf-ccamp-ospf-gmpls-extensions-08.txt
and for draft-ietf-ccamp-gmpls-routing-05.txt ended Aug 28, 2002; the
authors only got one comment on the former (a typo).  The new version
announced above fixes the typo, makes some minor formatting changes,
and spruces up the Security Considerations (essentially copied from
the OSPF TE doc).  The latter document is unchanged.

The OSPF WG was notified on Sept 30, 2002 that the above documents
finished CCAMP WG Last Call; no comments were received in the two
week window soliciting comments.

These documents will now be forwarded to the IESG as standards track
documents requesting an IETF Last Call.

Kireeti.

Delivery-date: Thu, 05 Dec 2002 22:41:09 -0800
Date: Thu, 5 Dec 2002 22:39:36 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Peter Ashwood-Smith <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "'John Drake'" <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.tx

Hi Peter, Hamid,

On Thu, 5 Dec 2002, Peter Ashwood-Smith wrote:

> Basically it describes what to many of us is obvious behavior for GMPLS.
> After all the ER is optional in GMPLS anyway.

Well, it's clear from some of the discussion both here and elsewhere
that it's not quite so obvious, so it's good to have it written down.

> We should have described this behavior as part of GMPLS in the first place
> so it clearly corrects an omission.

Sounds fine.

Kireeti.

Delivery-date: Thu, 05 Dec 2002 22:32:52 -0800
Date: Thu, 5 Dec 2002 22:31:22 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
cc: <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi Zhi,

On Tue, 3 Dec 2002, Lin, Zhi-Wei (Zhi) wrote:

> Hi all,
>
> Actually the work been done in the ITU-T deals specifically with the overlay, at least the application that operators have identified as been important to them. These documents are planned to be consented at the Jan ITU-T meeting (G.7713.x series). ITU-T has communicated to the IETF regarding this work for some time now (I'm bad at remembering dates but you can probably trace back the emails or the liaison statements).

I'm probably confused, but I recall the issue that the liaison statement
raised as being "call and connection separation".  Perhaps that's the
same as overlay; if so, it would be useful to clarify that.

> In addition, I have submitted two I-Ds, one on requirements and another on protocol extensions needed to support the overlay. It is my understanding that the protocol extensions document has passed through IESG review and sent off to the RFC editors already?
>
> http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rqts-00.txt
>
> http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-04.txt

My understanding was that these documents were to be standards track;
I learned at in Atlanta that their status was changed to informational.
It would have been friendly to state the change on the mailing list for
everyone's benefit.

In any case, as they are to be informational, I think it makes sense
that the IETF pursue its own standards track documents for overlay mode
if it sees fit (i.e., a chartered work item, and rough consensus).  The
CCAMP WG has been careful (with help from delegates from the ITU :-))
not to tread on the ITU's standards jurisdiction in the course of
developing IETF standards; however in this case, the IETF is extending
(or clarifying) its own protocols, and this issue doesn't arise.  One
might ask if the ITU is treading on the IETF's toes in this matter,
but it's a bit late for that.

Zhi, you didn't actually indicate an opinion on the swallow draft.
I will assume you don't have one unless I get mail otherwise.

Thanks,
Kireeti.

Delivery-date: Thu, 05 Dec 2002 22:09:48 -0800
Date: Thu, 5 Dec 2002 22:07:32 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: <[email-masked]>
cc: <[email-masked]>
Subject: Re: =?euc-kr?B?W8i4vcVdIFdHIENvbnNlbnN1cyBDYWxsOiBkcmFmdC1zd2FsbG93?= =?euc-kr?B?LWdtcGxzLW92ZXJsYXktMDAudHh0?=

Hi,

On Wed, 4 Dec 2002 [email-masked] wrote:

> I think it doesn't matter about the CCAMP WG
> whether OIF is a standardzation body or not,

It is important to set the record straight, especially if this is
used in support of arguments that affect CCAMP.

> and ITU-T prefer the overlay model to the peer model.

I don't see where this statement comes from.  Are you asserting
this, or are you speaking on behalf of the ITU?

> The important thing is what the CCAMP's mission is.
> If the CCAMP WG handles only the peer model,
> my answer to agree to the above document as a WG document is no.
> Otherwise, yes.

The CCAMP charter does not mention overlay or peer.  Signaling
is definitely in CCAMP's charter.  Moreover, the second work item,
namely "- Define signalling and measurement protocols that are
independent of each other" etc. clearly indicates that CCAMP is
chartered to show how signaling can be done independently of routing.
This ID shows how.

> I think that the CCAMP WG covers the control plane in the optical networks.

Point of clarification: CCAMP covers a COMMON control plane, which may
be specialized to optical networks.

> The control plane could be configured using the overlay model,
> the peer model or something that we may not be familiar with.
> In that sense, I think the above document have to be considered a WG
> document.

Okay, noted.

Thanks,
Kireeti.

Delivery-date: Thu, 05 Dec 2002 17:14:32 -0800
Date: Fri, 06 Dec 2002 02:13:15 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Greg Bernstein <[email-masked]>
Cc: "'John Drake'" <[email-masked]>, [email-masked], "'Razdan, Rajender'" <[email-masked]>, "'Jonathan Lang'" <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, "'ccamp '" <[email-masked]>
Subject: Re: J0/J1 encoding issues

i agree with john concerning its analysis of the situation and 
it gets even more difficult to solve when i see the following 
(from G.831, i have emphasized the MAY in this paragraph):

"The remainder of the API characters that follow the country code shall
be a
matter for the organization to whom the country code has been assigned,
provided
that uniqueness is guaranteed. These characters **MAY** be any
alphanumeric
characters as defined in ITU-T T.50 (International Reference Version -
7-bit
coded character set for information interchange)." 

and this is what it is said in G.7714.1:

"This recommendation adds a third format, which is identified 
by placing a non-E.164 and non-alphabetic character in the 
first byte of the message. [...] The remaining 14 bytes can 
be used for carrying the information required by G.7714, namely 
the control entity ID and SNTP-ID. 

As per IETF RFC2045, Base64 encoding provides a relatively 
efficient method to represent 6-bits of information in a 
printable character. This yields 3 nibbles or 12 bits for 
every 2 printable characters."

thus i think here G.7714.1 "moves" the printability requirement
in another dimension here it is not the printability referred
in the previous e-mail exchanges

but as far as i know characters are not printed on the wire, 
and the control entity ID nor the SNTP-ID is in the list 
mentioned in G.831 concerning the information to be exchanged 
within the pattern thus draft-lang-ccamp-lmp-bootstrap follows 
the same principle except it doesn't deliver the way to "print" 
the character since imho a purely internal system issue.

thus the only difference is that G.7714.1 requires the changes 
of the existing applications since it delivers the older ones
as well (or say it at follows it brings a new application that 
covers the previous ones - defined in G.831 - and the one which 
is defined in the bootstrap just delivers an application for 
the sake of what it intends to deliver), this said it is also 
mentioned in G.831 "the access point identifier should not 
change while the access point remains in existence;" thus i 
don't see here any strict incompatibility with respect to the 
bootstrap procedure if one desires to send the pattern only 
for discovery purposes and keep the existing applications for 
steady state use of the link.

thus, i would like a have clarification here because imho the
requirements that would be provided by responsible entities
concerning the sonet/sdh overhead encoding and related should
apply equivalently to any solution that are trying to deliver
a solution for sending an in-band pattern,

thanks,
- dimitri.

Greg Bernstein wrote:
> 
> Printable doesn't usually include control characters of which there are
> a fair amount in T.50.
> If you want the widest compatibility (i.e., all those existing ADMs too)
> you need readable/typeable characters. That way folks don't need to
> change the embedded software on existing equipment. Hence why a base64
> encoding is so nice.  This is was also a thrust in the LCP
> Identification extension (RFC1570).
> 
> Greg B.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John Drake
> Sent: Wednesday, December 04, 2002 6:36 PM
> To: [email-masked]'
> Cc: Razdan, Rajender; Jonathan Lang; 'Brungard, Deborah A, ALASO ';
> 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> Jonathan S,
> 
> Okay, now you've really confused me.
> 
> In this e-mail, you seem to be saying that any T.50 character is valid
> in
> J0/J1/J2.  However, in your earlier e-mail, which is included way down
> at
> the bottom of this e-mail, you say "The requirements for J0/J1/J2 (found
> in G.707) state the trace message payload must utilize the printable
> characters
> defined in T.50".
> 
> Which is the real requirement?
> 
> If it is the former, then there is no issue with
> draft-lang-ccamp-lmp-bootstrap.
> I.e., T.50 defines all possible 7 bit values and
> draft-lang-ccamp-lmp-bootstrap
> specifies that 7 bits of information are to be carried in each octet, so
> by
> definition every possible seven bit value is a valid T.50 character.
> 
> If it is the latter, then it doesn't sound as though the latest draft
> G.7714.1
> is any more conformant than draft-lang-ccamp-lmp-bootstrap is.
> 
> Thanks,
> 
> John
> 
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2002 8:49 AM
> To: John Drake
> Cc: Razdan, Rajender; Jonathan Lang; 'Brungard, Deborah A, ALASO ';
> 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> John,
> 
> There are a number of T.50 characters that are non-E.164 and
> non-alphabetic.  The use of a non-E.164 and non-alphabetic character in
> the format defined by draft G.7714.1 is to provide backward
> compatability with the country-specific and carrier-specific encodings
> described in G.831.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> >
> > Rajender,
> >
> > Why don't you send a pointer to the draft, so that any interested
> party
> can
> > take a look at it and decide for themselves?
> >
> > As I understand it, the  version presented at the Experts Meeting in
> Ottawa
> > did not comply with T.50 requirements, and it is only the newest draft
> > version that attempts to address the T.50 requirements.  It does so by
> > re-defining current Jx processing with a new format that "uses a
> non-E.164
> > and non-alphabetic character in the first byte of the message".
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Razdan, Rajender [mailto:[email-masked]]
> > Sent: Monday, November 25, 2002 8:55 AM
> > To: John Drake; [email-masked]
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: RE: J0/J1 encoding issues
> >
> > John,
> >
> >     I don't subscribe to the ccamp mailing list, and so haven't had a
> chance
> > to comment on the LMP drafts till now. The discussion on J0/J1 issues
> was
> > forwarded to me by Jonathan Sadler. As the editor of Draft G.7714.1, I
> was
> > quite distressed to read about your understanding that none of the
> work
> > aimed
> > at G.7714.1 is compatible with the T.50 requirement. I don't know how
> you
> > got
> > that absolutely wrong impression. In fact, compatibility with the T.50
> > requirement, as dictated by ITU Rec. G.707, has been the most
> important
> > consideration for us in our defining J0/J1/J2 discovery mechanisms.
> The
> > current
> > draft of G.7714.1 clearly states this. I FULLY agree with Jonathan
> Sadler
> > that
> > the LMP work should also be consistent with this requirement.
> >
> > Regards,
> > Rajender Razdan
> >
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Monday, November 25, 2002 11:24 AM
> > To: [email-masked]
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: RE: J0/J1 encoding issues
> >
> > Jonathan,
> >
> > The various Test transport mechanisms that are currently defined in
> > draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to input
> from
> > various carriers and organizations such as the OIF.  The fact that the
> > individual carriers have different requirements for the contents of
> the
> > various SDH/SONET overheads is also consistent with my reading of
> Deborah's
> > recent e-mail on this topic.
> >
> > Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
> > allows the transport of T.50 characters, I think we're done wrt
> > draft-ietf-ccamp-lmp-test-sonet-sdh.
> >
> > Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding that none of
> the
> > work aimed at G.7714.1 is compatible with the T.50 requirement.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Thursday, November 21, 2002 8:23 PM
> > To: John Drake
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> >
> > John -
> >
> > I think you forgot what my original message said.  It stated:
> >
> > > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > > have restrictions not only on the length of a trace message and on
> > > > the bits usable in a octet, but also on whether the payload in the
> > > > message uses printable ASCII characters.
> > > >
> > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > message payload must utilize the printable characters defined in
> > > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh
> &
> > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > consistant with this requirement.
> >
> > I fail to see what is incorrect with the above.
> >
> > While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
> > J0/J1/J2 that fall within the requirements of G.707, it also includes
> > methods that don't.  This situation SHOULD be resolved to provide the
> > greatest amount of interoperability while reducing the number of trace
> > methods that need to be implemented.
> >
> > I'm glad to see we agree on the fact that
> draft-lang-ccamp-lmp-bootstrap
> > only provides methods that fall outside the requirements of G.707.
> This
> > situation MUST be resolved.
> >
> > Jonathan Sadler
> >
> > John Drake wrote:
> > >
> > > Wouldn't it be more precise to say that it is an issue with
> > > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Thursday, November 21, 2002 12:49 PM
> > > To: John Drake
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: Re: J0/J1 encoding issues
> > >
> > > John -
> > >
> > > draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> > > Therefore, it is an issue.
> > >
> > > Jonathan Sadler
> > >
> > > John Drake wrote:
> > > >
> > > > Is it the case that if one chooses to use J0/J1/J2 Trace
> Correlation,
> > then
> > > > Jonathan Sadler's issue is a non-issue?
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Lang
> > > > Sent: Thursday, November 21, 2002 8:56 AM
> > > > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > > > 'ccamp '
> > > > Subject: FW: J0/J1 encoding issues
> > > >
> > > > Deborah,
> > > >   Thanks for the note. The option that Jonathan mentioned is one
> of a
> > > couple
> > > > options we define for Jx. We defined other options to
> > > > interwork with existing equipment without requiring any changes to
> > > > existing encodings (this would support both C1 and T.50
> requirements).
> > > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > > Correlation. We welcome additional comments from you and others at
> > > > T1X1.5/ITU.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > -----Original Message-----
> > > > From: Brungard, Deborah A, ALASO
> > > > To: [email-masked]; ccamp
> > > > Sent: 11/21/2002 5:22 AM
> > > > Subject: RE: J0/J1 encoding issues
> > > >
> > > > As Jonathan says, the current G.707 is using T.50. And there's
> more.
> > > > Example, for J0, one currently needs to support:
> > > > - previously defined C1 (repeating one-byte)
> > > > - T.50 (with format of G.707)
> > > > - no J0 (for equipment not supporting).
> > > >
> > > > So already we have defined multiple applications for this byte.
> Not to
> > > > say, there will be not any new ones. Even ITU knows, it never is
> > > > final;-)
> > > >
> > > > For supporting LMP's use, we need to understand the scenarios of
> use
> > > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > > inter-operator, applied for equipment installation verification or
> > > > service connection verification, etc. And hardware implications.
> > > >
> > > > Actually, G.831 defines multiple uses depending if inter or intra
> -
> > > > including for intra-operator, support of routing/path set-up (and
> G.831
> > > > was done years ago).
> > > >
> > > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5,
> contribute
> the
> > > > proposal for the meeting and we can start the discussion. The next
> ITU-T
> > > > meeting is in January. If the LMP editors need help on our T1X1.5
> > > > process, just ask.
> > > >
> > > > Deborah
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > Sent: Monday, November 18, 2002 7:59 PM
> > > > To: ccamp
> > > > Subject: J0/J1 encoding issues
> > > >
> > > > All -
> > > >
> > > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > > have restrictions not only on the length of a trace message and on
> > > > the bits usable in a octet, but also on whether the payload in the
> > > > message uses printable ASCII characters.
> > > >
> > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > message payload must utilize the printable characters defined in
> > > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh
> &
> > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > consistant with this requirement.
> > > >
> > > > This message is being sent to document this issue.  It is not a
> > > > statement that no other issues exist -- I expect that the
> appropriate
> > > > experts in the ITU will review the rest of these two drafts and
> > > > provide appropriate comment.
> > > >
> > > > Jonathan Sadler
> >
> > (I disclaim the disclaimer that follows this message.)
> > ===========================================================
> > The information contained in this message may be privileged
> > and confidential and protected from disclosure.  If the
> > reader of this message is not the intended recipient, or an
> > employee or agent responsible for delivering this message to
> > the intended recipient, you are hereby notified that any
> > reproduction, dissemination or distribution of this
> > communication is strictly prohibited. If you have received
> > this communication in error, please notify us immediately by
> > replying to the message and deleting it from your computer.
> >
> > Thank you.
> > Tellabs
> > ===========================================================
> ===========================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ===========================================================

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Thu, 05 Dec 2002 13:36:37 -0800
From: "Peter Ashwood-Smith" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'John Drake'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.tx
Date: Thu, 5 Dec 2002 16:12:51 -0500

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

------_=_NextPart_001_01C29CA1.45E60388
Content-Type: text/plain
[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

We (Hamid and I) see no problem with this becoming a working group document.

Basically it describes what to many of us is obvious behavior for GMPLS.
After all the ER is optional in GMPLS anyway.

We should have described this behavior as part of GMPLS in the first place
so it clearly corrects an omission.

Peter Ashwood-Smith
Hamid Ould-Brahim

------_=_NextPart_001_01C29CA1.45E60388
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.tx</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">We (Hamid and I) see no problem with =
this becoming a working group document.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Basically it describes what to many of =
us is obvious behavior for GMPLS. After all the ER is optional in GMPLS =
anyway.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">We should have described this behavior =
as part of GMPLS in the first place so it clearly corrects an =
omission.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Peter Ashwood-Smith</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Hamid Ould-Brahim</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C29CA1.45E60388--

Delivery-date: Thu, 05 Dec 2002 10:06:09 -0800
To: Yangguang Xu <[email-masked]>
cc: [email-masked], "'Ccamp (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: make-before-break in Gmpls 
Date: Thu, 05 Dec 2002 12:21:38 -0500
From: Curtis Villamizar <[email-masked]>

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <[email-masked]>, Yangguang Xu writes:
> Curtis,
> 
> > The ingress would need to know if bandwidth was shareable when doing a
> > reroute.  Otherwise, it may pick a path for which the RSVP signaling
> > always fails for no apparent reason.  That the RSVP signaling would
> > fail would not be apparent from the TE-LSDB before the signaling.
> > Reroute by trial and error is not a good option.
> > 
> > Is there a way for the ingress to know on which "links" bandwidth is
> > shareable?  Should it simply be assumed that bandwidth is not
> > shareable on any TDM, LSC, and FSC links?
> > 
> 
> You raised some good points here. For TDM, LSC and FSC, external resources
> (link/port) can be in two states. If a internal cross connection is performed
> ,
> the associated external resource is committed and thus not sharable anymore.
> Otherwise, it is sharable. So we can treat any non-committed resource as
> sharable. The rest are not sharable.
> 
> Then the complication is when a non-committed resource gets committed, the re
> st
> paths sharing the resource need to be re-arranged in order to guarantee the S
> LA
> in case of double failures. How does FRR handle this?

The answer to your question "How does FRR handle this?" is "not very
well at the moment but there is potential to do better".  While
seemingly flipant its an accurate answer.  I'll provide detail below.

There are two uses for SE, make-before-break and FRR.  I don't mean to
dodge your question, but I'd like to discuss make-before-break first,
then FRR.

Unlike FRR, make-before-break reroute from the ingress is done with
full bandwidth reservations (reserved and commited) and results in no
excess bandwidth being reserved and then wasted.  The new LSP is
reserved on a slightly different path but is able to share bandwidth
with the LSP it is replacing on any links in common in order to
accomplish a smooth transition.  It is important for the ingress to
know if this type of sharing is possible at all links for which both
the old and new LSP have in common and for which not enough bandwidth
is available for both the old and new without sharing.

Currently FRR cannot accurately account for bandwidth that can be
shared among backups that are not expected to fail at the same time
(do not protect any common SRLG).  This leaves two options for
deployment, reserve/commit full bandwidth on the backups or don't
reserve/commit full bandwidth on the backups.  In the former case far
more bandwidth is reserved than will ever be needed.  This might be OK
on a network that was massively overprovisioned.  In the latter case,
there is a chance that when the failures occur, the backups paths will
be congested (for packet links) or if the reservation must be
increased to "commit" the resource, then that operation will fail.

Practitioners seem to be opting for zero bandwidth reservations which
are increased to a full bandwidth reservations when the PLR puts the
backup into use.  This is not a good solution for packet networks.  It
is even less attractive for TDM, LSC and FSC.

Various methods to provide bandwidth reservation sharing have been
made going back as for as 1999 (afaik, maybe earlier as well).  Some
involve signaling the link, node, or set of SRLGs that a backup will
be using, and puts the intellegence to determine the potential for
sharing at each link.  One involves simply advertising the amount of
shareable bandwidth and sharable bandwidth used and puts the
intellegence at each PLR.

The issue of how backup bandwidth is shared, and therefore your
question of "How does FRR handle this?" is tangential to the issue of
whether TDM, LSC and FSC can share resources that are reserved and
committed by more than one LSP for which only one of those LSPs will
use the resource at one time and will use the entire resource to the
exclusion of the others.  It is "in principle" possible for TDM, LSC
and FSC (with the prior caveat regarding same-color or wavelegth
conversion).  If the ingress (or PLR for FRR) is to make an accurate
decision, then it needs to either know whether the sharing is possible
before attempting to setup an LSP, or it must assume that TDM, LSC and
FSC cannot support sharing.  IMHO traffic layout by trial and error is
not an option.

Curtis

> Thanks,
> 
> Yangguang

Delivery-date: Thu, 05 Dec 2002 08:48:04 -0800
To: [email-masked]
cc: Manoj Agiwal <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: make-before-break in Gmpls 
Date: Thu, 05 Dec 2002 10:11:23 -0500
From: Curtis Villamizar <[email-masked]>

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <[email-masked]>, [email-masked] wri
tes:
> hi,
> 
> i think this issue concerning "se style" has been discussed
> some time ago but let's try here to give a bit more details,
> lsp's in gmpls are control plane entities mapping data plane
> ones, merging here does get sense if and only if the data
> plane would deliver the same capability, since the soft-
> provisioning that we can expect in shared meshed restoration
> is purely a control plane driven mechanism the corresponding
> entity doesn't occur at the data plane level and in particular
> for tdm, lsc and fsc lsp's, once committed you find out the 
> ff style as used today, as such there is no today something
> like you seem to assume as setup of an lsp "split" it when 
> a recovery lsp is needed and then "merge" it back when the
> recovery lsp find back the working lsp path, then next even
> if the methods that are under definition may be thought as
> similar to the frr ones, the following for instance wouldn't
> strictly apply (see fast-reroute):
> 
> "When using the sender-template-specific approach, the protected
> LSPs and the backup paths SHOULD use the Shared Explicit (SE)
> style. This allows bandwidth sharing between multiple backup
> paths. The backup paths and the protected LSP MAY be merged by the
> Detour Merge Points, when the ERO from the MP to the egress is the
> same on each LSP to be merged, as specified in [RSVP-TE]."
> 
> this because for non-packet networks do soft-provisioning 
> means let the capability to share the bandwidth on a control
> plane view of the resource basis otherwise just provision 
> it (commit it) since having a dedicated soft-provisioning 
> on a per lsp basis just means be dedicated at the data plane 
> level (if we assume a consistent usage of the mechanisms), 
> and on the other side have merging (not multiplexing) of 
> lsc or tdm at the data plane level is impossible (afaik) 
> thus the fact that one knows that the requested lsp is for 
> recovery purposes (link protection tlv s bit set) and its 
> resources have to allocated within a pool but not committed 
> (ie reserved) something which is needed in any case, do
> the job here.  
> 
> hope this clarifies a bit,
> - dimitri.

This doesn't seem to me to clear it up.

In make-before-break, sharing bandwidth means that you will use one or
the other LSP, but never both.  Same with FRR - the primary or detour
is used, but not both at the same time.  Such a merge is at least in
principle possible for TDM, LSC, and FSC (although LSC required either
same wavelength or wavelength shifting or OEO).  I said "in
principle".  Therefore in principle, SE could be used for TDM, LSC,
and FSC.  In practice, this may not (ever) be true.

The ingress would need to know if bandwidth was shareable when doing a
reroute.  Otherwise, it may pick a path for which the RSVP signaling
always fails for no apparent reason.  That the RSVP signaling would
fail would not be apparent from the TE-LSDB before the signaling.
Reroute by trial and error is not a good option.

Is there a way for the ingress to know on which "links" bandwidth is
shareable?  Should it simply be assumed that bandwidth is not
shareable on any TDM, LSC, and FSC links?

Curtis

> Manoj Agiwal wrote:
> > 
> > Hi ,
> >          The gmpls architecture documents says
> > "GMPLS does not add anything new. Elegant re-routing is possible with the
> > concept of "make-before-break" whereby an old path is still used while a ne
> w
> > path is set up by avoiding double reservation of resources. Then, the node
> > performing the re-routing can swap on the new path and close the old path.
> > This feature is supported with RSVP-TE (using shared explicit filters) and
> > CR-LDP (using the action indicator flag).
> >           Will this feature will hold good for optical networks as well ,
> > where we have TDM , LSC  LSPs. This would require use of
> >      SE style in optical networks . Does signaling has to take care of not
> > reserving extra resources ( bandwidth / time slot )
> >     across the common path of the two LSPs , what will happen at the nodes
> > where the two routes diverge and converge .
> >     Is it expected that the signal will get multicast to both the routes ,
> > and at the node where the route converge the signal
> >     is selected from the better of the two paths till the rerouted LSP is
> > torn down .
> > Regards,
> > Manoj
> 
> -- 
> Papadimitriou Dimitri 
> E-mail : [email-masked] 
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> 

Delivery-date: Thu, 05 Dec 2002 07:57:15 -0800
Date: Thu, 05 Dec 2002 10:54:41 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: [email-masked]
CC: "'Ccamp (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: make-before-break in Gmpls

Curtis,

> The ingress would need to know if bandwidth was shareable when doing a
> reroute.  Otherwise, it may pick a path for which the RSVP signaling
> always fails for no apparent reason.  That the RSVP signaling would
> fail would not be apparent from the TE-LSDB before the signaling.
> Reroute by trial and error is not a good option.
> 
> Is there a way for the ingress to know on which "links" bandwidth is
> shareable?  Should it simply be assumed that bandwidth is not
> shareable on any TDM, LSC, and FSC links?
> 

You raised some good points here. For TDM, LSC and FSC, external resources
(link/port) can be in two states. If a internal cross connection is performed,
the associated external resource is committed and thus not sharable anymore.
Otherwise, it is sharable. So we can treat any non-committed resource as
sharable. The rest are not sharable.

Then the complication is when a non-committed resource gets committed, the rest
paths sharing the resource need to be re-arranged in order to guarantee the SLA
in case of double failures. How does FRR handle this?

Thanks,

Yangguang

Delivery-date: Thu, 05 Dec 2002 04:05:31 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: J0/J1 encoding issues
Date: Thu, 5 Dec 2002 12:03:04 -0000 

Thanks Maarten,

It's also worth saying that the principle Maarten is stating here (ie an
ability to uniquely identify a data-plane trail termination source) should
be available to be used in *all* technologies in all 3 network classes, be
they cnls, co pkt-sw or co cct-sw.
Note - In cnls this is a default given anyway, ie each/every pkt contains a
unique (to network it is in)  source identifier.

And this is precisely why Y.1711 specifies a TTSI (Trail Termination Source
Identifier) in the CV (Connectivity Verification) pkt.  For exmaple, this
allows fast squelching of traffic if an LSP misconnection occurs.....though
this not the only automatic defect detection/handling aspect that has to be
considered.

regards, Neil

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: 05 December 2002 10:01
> To: John Drake
> Cc: 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> 
> John,
> 
> Here is a copy of the text of section 3/G.831 which defines 
> the Access Point
> Identifier that is transmitted in the Trail Trace Identifiers 
> (J0, J1, J2 in
> SDH):
> 
> ================ section 3/G.831 =====================================
> 
> 3	SDH access point identification
> 
> An essential requirement for successful management of SDH 
> networks incorporating
> features such as point-to-point and point-to-multipoint paths 
> is a unique means
> of identifying significant points in the network, e.g. access 
> points. The
> features of Access Point Identifiers (APIs) are:
> 
> - each access point identifier must be globally unique in its 
> layer network;
> - where it may be expected that the access point may be 
> required for path
>   set-up across an inter-operator boundary, the access point 
> identifier
>   must be available to other network operators;
> - the access point identifier should not change while the access point
>   remains in existence;
> - the access point identifier should be able to identify the country
>   and network operator which is responsible for routing to 
> and from the
>   access point;
> - the set of all access point identifiers belonging to a single
>   administrative layer network should form a single access point
>   identification scheme;
> - the scheme of access point identifiers for each administrative
>   layer network can be independent from the scheme in any other
>   administrative layer network.
> 
> It is recommended that the VC-11, VC-12, VC-2, VC-2-xc, VC-3, 
> VC-4 and VC-4-xc
> should each have the access point identification scheme bases 
> on a tree-like
> format to aid routing control search algorithms. The access 
> point identifier
> should be globally unambiguous.
> 
> The API shall begin with either the country code as defined 
> in ITU-T E.164 (one,
> two or three numeric characters) or, the three alphabetic 
> character country code
> as defined in ISO 3166.
> 
> The remainder of the API characters that follow the country 
> code shall be a
> matter for the organization to whom the country code has been 
> assigned, provided
> that uniqueness is guaranteed. These characters may be any 
> alphanumeric
> characters as defined in ITU-T T.50 (International Reference 
> Version - 7-bit
> coded character set for information interchange).
> 
> The alphanumeric character set consists of the characters "a" 
> to "z", "A" to
> "Z", and "0" to "9".
> In the case where the API uses less than fifteen characters, 
> the API will be
> padded (extended) with the T.50 "NUL" character to get a 
> fifteen byte character
> string.
>  
> For interworking with equipment developed prior to this version of the
> Recommendation that may use the T.50 space as a padding 
> character, new equipment
> should be able to generate T.50 "SPACE" padding characters as 
> an option.
> 
> A similar access and test point identification scheme is 
> required for the
> section layer to support point-to-point and 
> point-to-multipoint paths and wide
> area multiplexors as used in satellite subnetworks.
> 
> The byte allocations for the transmission of the access point 
> identifier at the
> section layer, higher?order path layer and lower-order path 
> layer are given in
> ITU-T G.707.
> 
> ================= end of section 3/G.831 =============================
> 
> Furthermore, there is the ANSI specification in "Structure 
> and Representation of
> Trace
> Message Formats for the North American Telecommunications 
> System T1.269-2000". 
> This standard specifies the National Segment portion of the API.
> 
> 
> As you can see G.831 restricts the character set to the 
> alfanumeric symbols
> a..z, A..Z and 0..9 with NUL (or SPACE) padding at the end.
> 
> Regards,
> 
> Maarten
> PS. Older SDH equipment developed before the first version of 
> G.831 (08/96) was
> often less restrictive in the supported character set, and 
> allowed other
> printable and non-printable characters. This caused a lot of 
> headaches when
> trying to discover why there was a Trace Identfier Mismatch 
> (TIM) alarm; the
> Expected Trace Identifier and the Received Trace Identifier 
> looked the same on
> the GUI. Only when the GUI supported a HEX presentation mode, 
> it was possible to
> discover the non-printable characters that were causing the mismatch.
> 
> Regards,
> 
> Maarten
> 
> John Drake wrote:
> > 
> > Jonathan S,
> > 
> > Okay, now you've really confused me.
> > 
> > In this e-mail, you seem to be saying that any T.50 
> character is valid in
> > J0/J1/J2.  However, in your earlier e-mail, which is 
> included way down at
> > the bottom of this e-mail, you say "The requirements for 
> J0/J1/J2 (found
> > in G.707) state the trace message payload must utilize the printable
> > characters
> > defined in T.50".
> > 
> > Which is the real requirement?
> > 
> > If it is the former, then there is no issue with
> > draft-lang-ccamp-lmp-bootstrap.
> > I.e., T.50 defines all possible 7 bit values and
> > draft-lang-ccamp-lmp-bootstrap
> > specifies that 7 bits of information are to be carried in 
> each octet, so by
> > definition every possible seven bit value is a valid T.50 character.
> > 
> > If it is the latter, then it doesn't sound as though the 
> latest draft
> > G.7714.1
> > is any more conformant than draft-lang-ccamp-lmp-bootstrap is.
> > 
> > Thanks,
> > 
> > John
> > 
> > 
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Tuesday, November 26, 2002 8:49 AM
> > To: John Drake
> > Cc: Razdan, Rajender; Jonathan Lang; 'Brungard, Deborah A, ALASO ';
> > 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> > 
> > John,
> > 
> > There are a number of T.50 characters that are non-E.164 and
> > non-alphabetic.  The use of a non-E.164 and non-alphabetic 
> character in
> > the format defined by draft G.7714.1 is to provide backward
> > compatability with the country-specific and 
> carrier-specific encodings
> > described in G.831.
> > 
> > Jonathan Sadler
> > 
> > John Drake wrote:
> > >
> > > Rajender,
> > >
> > > Why don't you send a pointer to the draft, so that any 
> interested party
> > can
> > > take a look at it and decide for themselves?
> > >
> > > As I understand it, the  version presented at the Experts 
> Meeting in
> > Ottawa
> > > did not comply with T.50 requirements, and it is only the 
> newest draft
> > > version that attempts to address the T.50 requirements.  
> It does so by
> > > re-defining current Jx processing with a new format that 
> "uses a non-E.164
> > > and non-alphabetic character in the first byte of the message".
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Razdan, Rajender [mailto:[email-masked]]
> > > Sent: Monday, November 25, 2002 8:55 AM
> > > To: John Drake; [email-masked]
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: RE: J0/J1 encoding issues
> > >
> > > John,
> > >
> > >     I don't subscribe to the ccamp mailing list, and so 
> haven't had a
> > chance
> > > to comment on the LMP drafts till now. The discussion on 
> J0/J1 issues was
> > > forwarded to me by Jonathan Sadler. As the editor of 
> Draft G.7714.1, I was
> > > quite distressed to read about your understanding that 
> none of the work
> > > aimed
> > > at G.7714.1 is compatible with the T.50 requirement. I 
> don't know how you
> > > got
> > > that absolutely wrong impression. In fact, compatibility 
> with the T.50
> > > requirement, as dictated by ITU Rec. G.707, has been the 
> most important
> > > consideration for us in our defining J0/J1/J2 discovery 
> mechanisms. The
> > > current
> > > draft of G.7714.1 clearly states this. I FULLY agree with 
> Jonathan Sadler
> > > that
> > > the LMP work should also be consistent with this requirement.
> > >
> > > Regards,
> > > Rajender Razdan
> > >
> > > -----Original Message-----
> > > From: John Drake [mailto:[email-masked]]
> > > Sent: Monday, November 25, 2002 11:24 AM
> > > To: [email-masked]
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: RE: J0/J1 encoding issues
> > >
> > > Jonathan,
> > >
> > > The various Test transport mechanisms that are currently 
> defined in
> > > draft-ietf-ccamp-lmp-test-sonet-sdh were added in 
> response to input from
> > > various carriers and organizations such as the OIF.  The 
> fact that the
> > > individual carriers have different requirements for the 
> contents of the
> > > various SDH/SONET overheads is also consistent with my reading of
> > Deborah's
> > > recent e-mail on this topic.
> > >
> > > Since one of the transport mechanisms, the J0/J1/J2 trace 
> correlation,
> > > allows the transport of T.50 characters, I think we're done wrt
> > > draft-ietf-ccamp-lmp-test-sonet-sdh.
> > >
> > > Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding 
> that none of the
> > > work aimed at G.7714.1 is compatible with the T.50 requirement.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Thursday, November 21, 2002 8:23 PM
> > > To: John Drake
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: Re: J0/J1 encoding issues
> > >
> > > John -
> > >
> > > I think you forgot what my original message said.  It stated:
> > >
> > > > > As mentioned at the CCAMP meeting, the SDH trace 
> bytes (J0/J1/J2)
> > > > > have restrictions not only on the length of a trace 
> message and on
> > > > > the bits usable in a octet, but also on whether the 
> payload in the
> > > > > message uses printable ASCII characters.
> > > > >
> > > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > > message payload must utilize the printable characters 
> defined in
> > > > > T.50.  Two current LMP drafts 
> (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > > consistant with this requirement.
> > >
> > > I fail to see what is incorrect with the above.
> > >
> > > While draft-ietf-ccamp-lmp-test-sonet-sdh does describe 
> methods for
> > > J0/J1/J2 that fall within the requirements of G.707, it 
> also includes
> > > methods that don't.  This situation SHOULD be resolved to 
> provide the
> > > greatest amount of interoperability while reducing the 
> number of trace
> > > methods that need to be implemented.
> > >
> > > I'm glad to see we agree on the fact that 
> draft-lang-ccamp-lmp-bootstrap
> > > only provides methods that fall outside the requirements 
> of G.707.  This
> > > situation MUST be resolved.
> > >
> > > Jonathan Sadler
> > >
> > > John Drake wrote:
> > > >
> > > > Wouldn't it be more precise to say that it is an issue with
> > > > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > > > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > Sent: Thursday, November 21, 2002 12:49 PM
> > > > To: John Drake
> > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > Subject: Re: J0/J1 encoding issues
> > > >
> > > > John -
> > > >
> > > > draft-lang-ccamp-lmp-bootstrap does not support Trace 
> Correlation.
> > > > Therefore, it is an issue.
> > > >
> > > > Jonathan Sadler
> > > >
> > > > John Drake wrote:
> > > > >
> > > > > Is it the case that if one chooses to use J0/J1/J2 
> Trace Correlation,
> > > then
> > > > > Jonathan Sadler's issue is a non-issue?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > John
> > > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Lang
> > > > > Sent: Thursday, November 21, 2002 8:56 AM
> > > > > To: 'Brungard, Deborah A, ALASO '; 
> [email-masked] ';
> > > > > 'ccamp '
> > > > > Subject: FW: J0/J1 encoding issues
> > > > >
> > > > > Deborah,
> > > > >   Thanks for the note. The option that Jonathan 
> mentioned is one of a
> > > > couple
> > > > > options we define for Jx. We defined other options to
> > > > > interwork with existing equipment without requiring 
> any changes to
> > > > > existing encodings (this would support both C1 and 
> T.50 requirements).
> > > > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > > > Correlation. We welcome additional comments from you 
> and others at
> > > > > T1X1.5/ITU.
> > > > >
> > > > > Thanks,
> > > > > Jonathan
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brungard, Deborah A, ALASO
> > > > > To: [email-masked]; ccamp
> > > > > Sent: 11/21/2002 5:22 AM
> > > > > Subject: RE: J0/J1 encoding issues
> > > > >
> > > > > As Jonathan says, the current G.707 is using T.50. 
> And there's more.
> > > > > Example, for J0, one currently needs to support:
> > > > > - previously defined C1 (repeating one-byte)
> > > > > - T.50 (with format of G.707)
> > > > > - no J0 (for equipment not supporting).
> > > > >
> > > > > So already we have defined multiple applications for 
> this byte. Not to
> > > > > say, there will be not any new ones. Even ITU knows, 
> it never is
> > > > > final;-)
> > > > >
> > > > > For supporting LMP's use, we need to understand the 
> scenarios of use
> > > > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > > > inter-operator, applied for equipment installation 
> verification or
> > > > > service connection verification, etc. And hardware 
> implications.
> > > > >
> > > > > Actually, G.831 defines multiple uses depending if 
> inter or intra -
> > > > > including for intra-operator, support of routing/path 
> set-up (and
> > G.831
> > > > > was done years ago).
> > > > >
> > > > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 
> 5, contribute
> > the
> > > > > proposal for the meeting and we can start the 
> discussion. The next
> > ITU-T
> > > > > meeting is in January. If the LMP editors need help 
> on our T1X1.5
> > > > > process, just ask.
> > > > >
> > > > > Deborah
> > > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > > Sent: Monday, November 18, 2002 7:59 PM
> > > > > To: ccamp
> > > > > Subject: J0/J1 encoding issues
> > > > >
> > > > > All -
> > > > >
> > > > > As mentioned at the CCAMP meeting, the SDH trace 
> bytes (J0/J1/J2)
> > > > > have restrictions not only on the length of a trace 
> message and on
> > > > > the bits usable in a octet, but also on whether the 
> payload in the
> > > > > message uses printable ASCII characters.
> > > > >
> > > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > > message payload must utilize the printable characters 
> defined in
> > > > > T.50.  Two current LMP drafts 
> (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > > consistant with this requirement.
> > > > >
> > > > > This message is being sent to document this issue.  
> It is not a
> > > > > statement that no other issues exist -- I expect that 
> the appropriate
> > > > > experts in the ITU will review the rest of these two 
> drafts and
> > > > > provide appropriate comment.
> > > > >
> > > > > Jonathan Sadler
> > >
> > > (I disclaim the disclaimer that follows this message.)
> > > ============================================================
> > > The information contained in this message may be privileged
> > > and confidential and protected from disclosure.  If the
> > > reader of this message is not the intended recipient, or an
> > > employee or agent responsible for delivering this message to
> > > the intended recipient, you are hereby notified that any
> > > reproduction, dissemination or distribution of this
> > > communication is strictly prohibited. If you have received
> > > this communication in error, please notify us immediately by
> > > replying to the message and deleting it from your computer.
> > >
> > > Thank you.
> > > Tellabs
> > > ============================================================
> > ============================================================
> > The information contained in this message may be privileged
> > and confidential and protected from disclosure.  If the
> > reader of this message is not the intended recipient, or an
> > employee or agent responsible for delivering this message to
> > the intended recipient, you are hereby notified that any
> > reproduction, dissemination or distribution of this
> > communication is strictly prohibited. If you have received
> > this communication in error, please notify us immediately by
> > replying to the message and deleting it from your computer.
> > 
> > Thank you.
> > Tellabs
> > ============================================================
> 

Delivery-date: Thu, 05 Dec 2002 02:02:57 -0800
Cc: "'ccamp '" <[email-masked]>
Date: Thu, 05 Dec 2002 11:00:53 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
Original-CC: "'ccamp '" <[email-masked]>
Subject: Re: J0/J1 encoding issues

This is a multi-part message in MIME format.
--------------A541BE76293356E943AD0648
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

Here is a copy of the text of section 3/G.831 which defines the Access Point
Identifier that is transmitted in the Trail Trace Identifiers (J0, J1, J2 in
SDH):

================ section 3/G.831 =====================================

3	SDH access point identification

An essential requirement for successful management of SDH networks incorporating
features such as point-to-point and point-to-multipoint paths is a unique means
of identifying significant points in the network, e.g. access points. The
features of Access Point Identifiers (APIs) are:

- each access point identifier must be globally unique in its layer network;
- where it may be expected that the access point may be required for path
  set-up across an inter-operator boundary, the access point identifier
  must be available to other network operators;
- the access point identifier should not change while the access point
  remains in existence;
- the access point identifier should be able to identify the country
  and network operator which is responsible for routing to and from the
  access point;
- the set of all access point identifiers belonging to a single
  administrative layer network should form a single access point
  identification scheme;
- the scheme of access point identifiers for each administrative
  layer network can be independent from the scheme in any other
  administrative layer network.

It is recommended that the VC-11, VC-12, VC-2, VC-2-xc, VC-3, VC-4 and VC-4-xc
should each have the access point identification scheme bases on a tree-like
format to aid routing control search algorithms. The access point identifier
should be globally unambiguous.

The API shall begin with either the country code as defined in ITU-T E.164 (one,
two or three numeric characters) or, the three alphabetic character country code
as defined in ISO 3166.

The remainder of the API characters that follow the country code shall be a
matter for the organization to whom the country code has been assigned, provided
that uniqueness is guaranteed. These characters may be any alphanumeric
characters as defined in ITU-T T.50 (International Reference Version - 7-bit
coded character set for information interchange).

The alphanumeric character set consists of the characters "a" to "z", "A" to
"Z", and "0" to "9".
In the case where the API uses less than fifteen characters, the API will be
padded (extended) with the T.50 "NUL" character to get a fifteen byte character
string.
 
For interworking with equipment developed prior to this version of the
Recommendation that may use the T.50 space as a padding character, new equipment
should be able to generate T.50 "SPACE" padding characters as an option.

A similar access and test point identification scheme is required for the
section layer to support point-to-point and point-to-multipoint paths and wide
area multiplexors as used in satellite subnetworks.

The byte allocations for the transmission of the access point identifier at the
section layer, higher?order path layer and lower-order path layer are given in
ITU-T G.707.

================= end of section 3/G.831 =============================

Furthermore, there is the ANSI specification in "Structure and Representation of
Trace
Message Formats for the North American Telecommunications System T1.269-2000". 
This standard specifies the National Segment portion of the API.

As you can see G.831 restricts the character set to the alfanumeric symbols
a..z, A..Z and 0..9 with NUL (or SPACE) padding at the end.

Regards,

Maarten
PS. Older SDH equipment developed before the first version of G.831 (08/96) was
often less restrictive in the supported character set, and allowed other
printable and non-printable characters. This caused a lot of headaches when
trying to discover why there was a Trace Identfier Mismatch (TIM) alarm; the
Expected Trace Identifier and the Received Trace Identifier looked the same on
the GUI. Only when the GUI supported a HEX presentation mode, it was possible to
discover the non-printable characters that were causing the mismatch.

Regards,

Maarten

John Drake wrote:
> 
> Jonathan S,
> 
> Okay, now you've really confused me.
> 
> In this e-mail, you seem to be saying that any T.50 character is valid in
> J0/J1/J2.  However, in your earlier e-mail, which is included way down at
> the bottom of this e-mail, you say "The requirements for J0/J1/J2 (found
> in G.707) state the trace message payload must utilize the printable
> characters
> defined in T.50".
> 
> Which is the real requirement?
> 
> If it is the former, then there is no issue with
> draft-lang-ccamp-lmp-bootstrap.
> I.e., T.50 defines all possible 7 bit values and
> draft-lang-ccamp-lmp-bootstrap
> specifies that 7 bits of information are to be carried in each octet, so by
> definition every possible seven bit value is a valid T.50 character.
> 
> If it is the latter, then it doesn't sound as though the latest draft
> G.7714.1
> is any more conformant than draft-lang-ccamp-lmp-bootstrap is.
> 
> Thanks,
> 
> John
> 
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2002 8:49 AM
> To: John Drake
> Cc: Razdan, Rajender; Jonathan Lang; 'Brungard, Deborah A, ALASO ';
> 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> John,
> 
> There are a number of T.50 characters that are non-E.164 and
> non-alphabetic.  The use of a non-E.164 and non-alphabetic character in
> the format defined by draft G.7714.1 is to provide backward
> compatability with the country-specific and carrier-specific encodings
> described in G.831.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> >
> > Rajender,
> >
> > Why don't you send a pointer to the draft, so that any interested party
> can
> > take a look at it and decide for themselves?
> >
> > As I understand it, the  version presented at the Experts Meeting in
> Ottawa
> > did not comply with T.50 requirements, and it is only the newest draft
> > version that attempts to address the T.50 requirements.  It does so by
> > re-defining current Jx processing with a new format that "uses a non-E.164
> > and non-alphabetic character in the first byte of the message".
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Razdan, Rajender [mailto:[email-masked]]
> > Sent: Monday, November 25, 2002 8:55 AM
> > To: John Drake; [email-masked]
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: RE: J0/J1 encoding issues
> >
> > John,
> >
> >     I don't subscribe to the ccamp mailing list, and so haven't had a
> chance
> > to comment on the LMP drafts till now. The discussion on J0/J1 issues was
> > forwarded to me by Jonathan Sadler. As the editor of Draft G.7714.1, I was
> > quite distressed to read about your understanding that none of the work
> > aimed
> > at G.7714.1 is compatible with the T.50 requirement. I don't know how you
> > got
> > that absolutely wrong impression. In fact, compatibility with the T.50
> > requirement, as dictated by ITU Rec. G.707, has been the most important
> > consideration for us in our defining J0/J1/J2 discovery mechanisms. The
> > current
> > draft of G.7714.1 clearly states this. I FULLY agree with Jonathan Sadler
> > that
> > the LMP work should also be consistent with this requirement.
> >
> > Regards,
> > Rajender Razdan
> >
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Monday, November 25, 2002 11:24 AM
> > To: [email-masked]
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: RE: J0/J1 encoding issues
> >
> > Jonathan,
> >
> > The various Test transport mechanisms that are currently defined in
> > draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to input from
> > various carriers and organizations such as the OIF.  The fact that the
> > individual carriers have different requirements for the contents of the
> > various SDH/SONET overheads is also consistent with my reading of
> Deborah's
> > recent e-mail on this topic.
> >
> > Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
> > allows the transport of T.50 characters, I think we're done wrt
> > draft-ietf-ccamp-lmp-test-sonet-sdh.
> >
> > Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding that none of the
> > work aimed at G.7714.1 is compatible with the T.50 requirement.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Thursday, November 21, 2002 8:23 PM
> > To: John Drake
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> >
> > John -
> >
> > I think you forgot what my original message said.  It stated:
> >
> > > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > > have restrictions not only on the length of a trace message and on
> > > > the bits usable in a octet, but also on whether the payload in the
> > > > message uses printable ASCII characters.
> > > >
> > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > message payload must utilize the printable characters defined in
> > > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > consistant with this requirement.
> >
> > I fail to see what is incorrect with the above.
> >
> > While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
> > J0/J1/J2 that fall within the requirements of G.707, it also includes
> > methods that don't.  This situation SHOULD be resolved to provide the
> > greatest amount of interoperability while reducing the number of trace
> > methods that need to be implemented.
> >
> > I'm glad to see we agree on the fact that draft-lang-ccamp-lmp-bootstrap
> > only provides methods that fall outside the requirements of G.707.  This
> > situation MUST be resolved.
> >
> > Jonathan Sadler
> >
> > John Drake wrote:
> > >
> > > Wouldn't it be more precise to say that it is an issue with
> > > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Thursday, November 21, 2002 12:49 PM
> > > To: John Drake
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: Re: J0/J1 encoding issues
> > >
> > > John -
> > >
> > > draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> > > Therefore, it is an issue.
> > >
> > > Jonathan Sadler
> > >
> > > John Drake wrote:
> > > >
> > > > Is it the case that if one chooses to use J0/J1/J2 Trace Correlation,
> > then
> > > > Jonathan Sadler's issue is a non-issue?
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Lang
> > > > Sent: Thursday, November 21, 2002 8:56 AM
> > > > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > > > 'ccamp '
> > > > Subject: FW: J0/J1 encoding issues
> > > >
> > > > Deborah,
> > > >   Thanks for the note. The option that Jonathan mentioned is one of a
> > > couple
> > > > options we define for Jx. We defined other options to
> > > > interwork with existing equipment without requiring any changes to
> > > > existing encodings (this would support both C1 and T.50 requirements).
> > > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > > Correlation. We welcome additional comments from you and others at
> > > > T1X1.5/ITU.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > -----Original Message-----
> > > > From: Brungard, Deborah A, ALASO
> > > > To: [email-masked]; ccamp
> > > > Sent: 11/21/2002 5:22 AM
> > > > Subject: RE: J0/J1 encoding issues
> > > >
> > > > As Jonathan says, the current G.707 is using T.50. And there's more.
> > > > Example, for J0, one currently needs to support:
> > > > - previously defined C1 (repeating one-byte)
> > > > - T.50 (with format of G.707)
> > > > - no J0 (for equipment not supporting).
> > > >
> > > > So already we have defined multiple applications for this byte. Not to
> > > > say, there will be not any new ones. Even ITU knows, it never is
> > > > final;-)
> > > >
> > > > For supporting LMP's use, we need to understand the scenarios of use
> > > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > > inter-operator, applied for equipment installation verification or
> > > > service connection verification, etc. And hardware implications.
> > > >
> > > > Actually, G.831 defines multiple uses depending if inter or intra -
> > > > including for intra-operator, support of routing/path set-up (and
> G.831
> > > > was done years ago).
> > > >
> > > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute
> the
> > > > proposal for the meeting and we can start the discussion. The next
> ITU-T
> > > > meeting is in January. If the LMP editors need help on our T1X1.5
> > > > process, just ask.
> > > >
> > > > Deborah
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > Sent: Monday, November 18, 2002 7:59 PM
> > > > To: ccamp
> > > > Subject: J0/J1 encoding issues
> > > >
> > > > All -
> > > >
> > > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > > have restrictions not only on the length of a trace message and on
> > > > the bits usable in a octet, but also on whether the payload in the
> > > > message uses printable ASCII characters.
> > > >
> > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > message payload must utilize the printable characters defined in
> > > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > consistant with this requirement.
> > > >
> > > > This message is being sent to document this issue.  It is not a
> > > > statement that no other issues exist -- I expect that the appropriate
> > > > experts in the ITU will review the rest of these two drafts and
> > > > provide appropriate comment.
> > > >
> > > > Jonathan Sadler
> >
> > (I disclaim the disclaimer that follows this message.)
> > ============================================================
> > The information contained in this message may be privileged
> > and confidential and protected from disclosure.  If the
> > reader of this message is not the intended recipient, or an
> > employee or agent responsible for delivering this message to
> > the intended recipient, you are hereby notified that any
> > reproduction, dissemination or distribution of this
> > communication is strictly prohibited. If you have received
> > this communication in error, please notify us immediately by
> > replying to the message and deleting it from your computer.
> >
> > Thank you.
> > Tellabs
> > ============================================================
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
--------------A541BE76293356E943AD0648
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies;NA&CPSE
adr:;;Larenseweg 50;Hilversum;;1221 XL;Netherlands
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
fn:Maarten Vissers
end:vcard

--------------A541BE76293356E943AD0648--

Delivery-date: Wed, 04 Dec 2002 19:33:08 -0800
From: "Greg Bernstein" <[email-masked]>
To: "'John Drake'" <[email-masked]>, <[email-masked]>
Cc: "'Razdan, Rajender'" <[email-masked]>, "'Jonathan Lang'" <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, "'ccamp '" <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Wed, 4 Dec 2002 19:31:32 -0800

Printable doesn't usually include control characters of which there are
a fair amount in T.50.
If you want the widest compatibility (i.e., all those existing ADMs too)
you need readable/typeable characters. That way folks don't need to
change the embedded software on existing equipment. Hence why a base64
encoding is so nice.  This is was also a thrust in the LCP
Identification extension (RFC1570).

Greg B.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of John Drake
Sent: Wednesday, December 04, 2002 6:36 PM
To: [email-masked]'
Cc: Razdan, Rajender; Jonathan Lang; 'Brungard, Deborah A, ALASO ';
'ccamp '
Subject: RE: J0/J1 encoding issues

Jonathan S,

Okay, now you've really confused me.

In this e-mail, you seem to be saying that any T.50 character is valid
in
J0/J1/J2.  However, in your earlier e-mail, which is included way down
at
the bottom of this e-mail, you say "The requirements for J0/J1/J2 (found
in G.707) state the trace message payload must utilize the printable
characters
defined in T.50".

Which is the real requirement?

If it is the former, then there is no issue with
draft-lang-ccamp-lmp-bootstrap.
I.e., T.50 defines all possible 7 bit values and
draft-lang-ccamp-lmp-bootstrap
specifies that 7 bits of information are to be carried in each octet, so
by
definition every possible seven bit value is a valid T.50 character.

If it is the latter, then it doesn't sound as though the latest draft
G.7714.1
is any more conformant than draft-lang-ccamp-lmp-bootstrap is.

Thanks,

John

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Tuesday, November 26, 2002 8:49 AM
To: John Drake
Cc: Razdan, Rajender; Jonathan Lang; 'Brungard, Deborah A, ALASO ';
'ccamp '
Subject: Re: J0/J1 encoding issues

John, 

There are a number of T.50 characters that are non-E.164 and
non-alphabetic.  The use of a non-E.164 and non-alphabetic character in
the format defined by draft G.7714.1 is to provide backward
compatability with the country-specific and carrier-specific encodings
described in G.831.

Jonathan Sadler

John Drake wrote:
> 
> Rajender,
> 
> Why don't you send a pointer to the draft, so that any interested
party
can
> take a look at it and decide for themselves?
> 
> As I understand it, the  version presented at the Experts Meeting in
Ottawa
> did not comply with T.50 requirements, and it is only the newest draft
> version that attempts to address the T.50 requirements.  It does so by
> re-defining current Jx processing with a new format that "uses a
non-E.164
> and non-alphabetic character in the first byte of the message".
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Razdan, Rajender [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 8:55 AM
> To: John Drake; [email-masked]
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> John,
> 
>     I don't subscribe to the ccamp mailing list, and so haven't had a
chance
> to comment on the LMP drafts till now. The discussion on J0/J1 issues
was
> forwarded to me by Jonathan Sadler. As the editor of Draft G.7714.1, I
was
> quite distressed to read about your understanding that none of the
work
> aimed
> at G.7714.1 is compatible with the T.50 requirement. I don't know how
you
> got
> that absolutely wrong impression. In fact, compatibility with the T.50
> requirement, as dictated by ITU Rec. G.707, has been the most
important
> consideration for us in our defining J0/J1/J2 discovery mechanisms.
The
> current
> draft of G.7714.1 clearly states this. I FULLY agree with Jonathan
Sadler
> that
> the LMP work should also be consistent with this requirement.
> 
> Regards,
> Rajender Razdan
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 11:24 AM
> To: [email-masked]
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> Jonathan,
> 
> The various Test transport mechanisms that are currently defined in
> draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to input
from
> various carriers and organizations such as the OIF.  The fact that the
> individual carriers have different requirements for the contents of
the
> various SDH/SONET overheads is also consistent with my reading of
Deborah's
> recent e-mail on this topic.
> 
> Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
> allows the transport of T.50 characters, I think we're done wrt
> draft-ietf-ccamp-lmp-test-sonet-sdh.
> 
> Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding that none of
the
> work aimed at G.7714.1 is compatible with the T.50 requirement.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 8:23 PM
> To: John Drake
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> John -
> 
> I think you forgot what my original message said.  It stated:
> 
> > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > have restrictions not only on the length of a trace message and on
> > > the bits usable in a octet, but also on whether the payload in the
> > > message uses printable ASCII characters.
> > >
> > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > message payload must utilize the printable characters defined in
> > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh
&
> > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > consistant with this requirement.
> 
> I fail to see what is incorrect with the above.
> 
> While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
> J0/J1/J2 that fall within the requirements of G.707, it also includes
> methods that don't.  This situation SHOULD be resolved to provide the
> greatest amount of interoperability while reducing the number of trace
> methods that need to be implemented.
> 
> I'm glad to see we agree on the fact that
draft-lang-ccamp-lmp-bootstrap
> only provides methods that fall outside the requirements of G.707.
This
> situation MUST be resolved.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> >
> > Wouldn't it be more precise to say that it is an issue with
> > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > draft-ietf-ccamp-lmp-test-sonet-sdh?
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Thursday, November 21, 2002 12:49 PM
> > To: John Drake
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> >
> > John -
> >
> > draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> > Therefore, it is an issue.
> >
> > Jonathan Sadler
> >
> > John Drake wrote:
> > >
> > > Is it the case that if one chooses to use J0/J1/J2 Trace
Correlation,
> then
> > > Jonathan Sadler's issue is a non-issue?
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Jonathan Lang
> > > Sent: Thursday, November 21, 2002 8:56 AM
> > > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > > 'ccamp '
> > > Subject: FW: J0/J1 encoding issues
> > >
> > > Deborah,
> > >   Thanks for the note. The option that Jonathan mentioned is one
of a
> > couple
> > > options we define for Jx. We defined other options to
> > > interwork with existing equipment without requiring any changes to
> > > existing encodings (this would support both C1 and T.50
requirements).
> > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > Correlation. We welcome additional comments from you and others at
> > > T1X1.5/ITU.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > -----Original Message-----
> > > From: Brungard, Deborah A, ALASO
> > > To: [email-masked]; ccamp
> > > Sent: 11/21/2002 5:22 AM
> > > Subject: RE: J0/J1 encoding issues
> > >
> > > As Jonathan says, the current G.707 is using T.50. And there's
more.
> > > Example, for J0, one currently needs to support:
> > > - previously defined C1 (repeating one-byte)
> > > - T.50 (with format of G.707)
> > > - no J0 (for equipment not supporting).
> > >
> > > So already we have defined multiple applications for this byte.
Not to
> > > say, there will be not any new ones. Even ITU knows, it never is
> > > final;-)
> > >
> > > For supporting LMP's use, we need to understand the scenarios of
use
> > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > inter-operator, applied for equipment installation verification or
> > > service connection verification, etc. And hardware implications.
> > >
> > > Actually, G.831 defines multiple uses depending if inter or intra
-
> > > including for intra-operator, support of routing/path set-up (and
G.831
> > > was done years ago).
> > >
> > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5,
contribute
the
> > > proposal for the meeting and we can start the discussion. The next
ITU-T
> > > meeting is in January. If the LMP editors need help on our T1X1.5
> > > process, just ask.
> > >
> > > Deborah
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Monday, November 18, 2002 7:59 PM
> > > To: ccamp
> > > Subject: J0/J1 encoding issues
> > >
> > > All -
> > >
> > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > have restrictions not only on the length of a trace message and on
> > > the bits usable in a octet, but also on whether the payload in the
> > > message uses printable ASCII characters.
> > >
> > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > message payload must utilize the printable characters defined in
> > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh
&
> > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > consistant with this requirement.
> > >
> > > This message is being sent to document this issue.  It is not a
> > > statement that no other issues exist -- I expect that the
appropriate
> > > experts in the ITU will review the rest of these two drafts and
> > > provide appropriate comment.
> > >
> > > Jonathan Sadler
> 
> (I disclaim the disclaimer that follows this message.)
> ===========================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ===========================================================
===========================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
===========================================================

Delivery-date: Wed, 04 Dec 2002 18:37:38 -0800
From: John Drake <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "Razdan, Rajender" <[email-masked]>, Jonathan Lang <[email-masked]>, "'Brungard, Deborah A, ALASO '" <[email-masked]>, 'ccamp ' <[email-masked]>
Subject: RE: J0/J1 encoding issues
Date: Wed, 4 Dec 2002 18:35:33 -0800 

Jonathan S,

Okay, now you've really confused me.

In this e-mail, you seem to be saying that any T.50 character is valid in
J0/J1/J2.  However, in your earlier e-mail, which is included way down at
the bottom of this e-mail, you say "The requirements for J0/J1/J2 (found
in G.707) state the trace message payload must utilize the printable
characters
defined in T.50".

Which is the real requirement?

If it is the former, then there is no issue with
draft-lang-ccamp-lmp-bootstrap.
I.e., T.50 defines all possible 7 bit values and
draft-lang-ccamp-lmp-bootstrap
specifies that 7 bits of information are to be carried in each octet, so by
definition every possible seven bit value is a valid T.50 character.

If it is the latter, then it doesn't sound as though the latest draft
G.7714.1
is any more conformant than draft-lang-ccamp-lmp-bootstrap is.

Thanks,

John

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: Tuesday, November 26, 2002 8:49 AM
To: John Drake
Cc: Razdan, Rajender; Jonathan Lang; 'Brungard, Deborah A, ALASO ';
'ccamp '
Subject: Re: J0/J1 encoding issues

John, 

There are a number of T.50 characters that are non-E.164 and
non-alphabetic.  The use of a non-E.164 and non-alphabetic character in
the format defined by draft G.7714.1 is to provide backward
compatability with the country-specific and carrier-specific encodings
described in G.831.

Jonathan Sadler

John Drake wrote:
> 
> Rajender,
> 
> Why don't you send a pointer to the draft, so that any interested party
can
> take a look at it and decide for themselves?
> 
> As I understand it, the  version presented at the Experts Meeting in
Ottawa
> did not comply with T.50 requirements, and it is only the newest draft
> version that attempts to address the T.50 requirements.  It does so by
> re-defining current Jx processing with a new format that "uses a non-E.164
> and non-alphabetic character in the first byte of the message".
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Razdan, Rajender [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 8:55 AM
> To: John Drake; [email-masked]
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> John,
> 
>     I don't subscribe to the ccamp mailing list, and so haven't had a
chance
> to comment on the LMP drafts till now. The discussion on J0/J1 issues was
> forwarded to me by Jonathan Sadler. As the editor of Draft G.7714.1, I was
> quite distressed to read about your understanding that none of the work
> aimed
> at G.7714.1 is compatible with the T.50 requirement. I don't know how you
> got
> that absolutely wrong impression. In fact, compatibility with the T.50
> requirement, as dictated by ITU Rec. G.707, has been the most important
> consideration for us in our defining J0/J1/J2 discovery mechanisms. The
> current
> draft of G.7714.1 clearly states this. I FULLY agree with Jonathan Sadler
> that
> the LMP work should also be consistent with this requirement.
> 
> Regards,
> Rajender Razdan
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 11:24 AM
> To: [email-masked]
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> Jonathan,
> 
> The various Test transport mechanisms that are currently defined in
> draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to input from
> various carriers and organizations such as the OIF.  The fact that the
> individual carriers have different requirements for the contents of the
> various SDH/SONET overheads is also consistent with my reading of
Deborah's
> recent e-mail on this topic.
> 
> Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
> allows the transport of T.50 characters, I think we're done wrt
> draft-ietf-ccamp-lmp-test-sonet-sdh.
> 
> Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding that none of the
> work aimed at G.7714.1 is compatible with the T.50 requirement.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 8:23 PM
> To: John Drake
> Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> John -
> 
> I think you forgot what my original message said.  It stated:
> 
> > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > have restrictions not only on the length of a trace message and on
> > > the bits usable in a octet, but also on whether the payload in the
> > > message uses printable ASCII characters.
> > >
> > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > message payload must utilize the printable characters defined in
> > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > consistant with this requirement.
> 
> I fail to see what is incorrect with the above.
> 
> While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
> J0/J1/J2 that fall within the requirements of G.707, it also includes
> methods that don't.  This situation SHOULD be resolved to provide the
> greatest amount of interoperability while reducing the number of trace
> methods that need to be implemented.
> 
> I'm glad to see we agree on the fact that draft-lang-ccamp-lmp-bootstrap
> only provides methods that fall outside the requirements of G.707.  This
> situation MUST be resolved.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> >
> > Wouldn't it be more precise to say that it is an issue with
> > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > draft-ietf-ccamp-lmp-test-sonet-sdh?
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[email-masked]]
> > Sent: Thursday, November 21, 2002 12:49 PM
> > To: John Drake
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> >
> > John -
> >
> > draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> > Therefore, it is an issue.
> >
> > Jonathan Sadler
> >
> > John Drake wrote:
> > >
> > > Is it the case that if one chooses to use J0/J1/J2 Trace Correlation,
> then
> > > Jonathan Sadler's issue is a non-issue?
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Jonathan Lang
> > > Sent: Thursday, November 21, 2002 8:56 AM
> > > To: 'Brungard, Deborah A, ALASO '; [email-masked] ';
> > > 'ccamp '
> > > Subject: FW: J0/J1 encoding issues
> > >
> > > Deborah,
> > >   Thanks for the note. The option that Jonathan mentioned is one of a
> > couple
> > > options we define for Jx. We defined other options to
> > > interwork with existing equipment without requiring any changes to
> > > existing encodings (this would support both C1 and T.50 requirements).
> > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > Correlation. We welcome additional comments from you and others at
> > > T1X1.5/ITU.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > -----Original Message-----
> > > From: Brungard, Deborah A, ALASO
> > > To: [email-masked]; ccamp
> > > Sent: 11/21/2002 5:22 AM
> > > Subject: RE: J0/J1 encoding issues
> > >
> > > As Jonathan says, the current G.707 is using T.50. And there's more.
> > > Example, for J0, one currently needs to support:
> > > - previously defined C1 (repeating one-byte)
> > > - T.50 (with format of G.707)
> > > - no J0 (for equipment not supporting).
> > >
> > > So already we have defined multiple applications for this byte. Not to
> > > say, there will be not any new ones. Even ITU knows, it never is
> > > final;-)
> > >
> > > For supporting LMP's use, we need to understand the scenarios of use
> > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > inter-operator, applied for equipment installation verification or
> > > service connection verification, etc. And hardware implications.
> > >
> > > Actually, G.831 defines multiple uses depending if inter or intra -
> > > including for intra-operator, support of routing/path set-up (and
G.831
> > > was done years ago).
> > >
> > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5, contribute
the
> > > proposal for the meeting and we can start the discussion. The next
ITU-T
> > > meeting is in January. If the LMP editors need help on our T1X1.5
> > > process, just ask.
> > >
> > > Deborah
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[email-masked]]
> > > Sent: Monday, November 18, 2002 7:59 PM
> > > To: ccamp
> > > Subject: J0/J1 encoding issues
> > >
> > > All -
> > >
> > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > have restrictions not only on the length of a trace message and on
> > > the bits usable in a octet, but also on whether the payload in the
> > > message uses printable ASCII characters.
> > >
> > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > message payload must utilize the printable characters defined in
> > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > consistant with this requirement.
> > >
> > > This message is being sent to document this issue.  It is not a
> > > statement that no other issues exist -- I expect that the appropriate
> > > experts in the ITU will review the rest of these two drafts and
> > > provide appropriate comment.
> > >
> > > Jonathan Sadler
> 
> (I disclaim the disclaimer that follows this message.)
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Wed, 04 Dec 2002 15:41:01 -0800
From: "Lever Wang" <[email-masked]>
To: "Loa Andersson" <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Wed, 4 Dec 2002 15:36:37 -0800

I also support this draft.  

But I am not clear on one point:

Does it support both "Public UNI" and "Private UNI" models, so for CPE 
which does not need routing/topology reachability information at all, it 
can also signal into a provider's IP network?

Lever Wang
DeriveIt, LLC

----- Original Message ----- 
From: "Loa Andersson" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 04, 2002 9:11 AM
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

> sure thing - this is useful
> 
> /Loa
> 
> Kireeti Kompella wrote:
> > Hi,
> > 
> > This is a call for consensus to make the above document a CCAMP WG
> > document.  This call will end Dec 17, 2002.
> > 
> > Please indicate your opinion by replying to this email.
> > 
> > Thanks,
> > Kireeti.
> > 
> > 
> > 
> > 
> 
> 
> -- 
> Loa Andersson
> 
> Mobile          +46 739 81 21 64
> Email           [email-masked]
> 
> 
> 
> 
> 

Delivery-date: Wed, 04 Dec 2002 12:16:54 -0800
Date: Wed, 04 Dec 2002 15:15:09 -0500
From: Srini Datari <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

The Internet Draft draft-swallow-gmpls-overlay-00.txt should be a
CCAMP WG document.

Srini Datari.

Kireeti Kompella wrote:

> Hi,
>
> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
>
> Please indicate your opinion by replying to this email.
>
> Thanks,
> Kireeti.

Delivery-date: Wed, 04 Dec 2002 11:19:13 -0800
From: "Gray, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Wed, 4 Dec 2002 14:16:55 -0500 

The Internet Draft draft-swallow-gmpls-overlay-00.txt should be a 
CCAMP WG document.

> Hi,
>
> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
>
> Please indicate your opinion by replying to this email.
>
> Thanks,
> Kireeti.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

Delivery-date: Wed, 04 Dec 2002 10:18:53 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: IETF Sub-IP area: request for input
Date: Wed, 4 Dec 2002 19:17:26 +0100 

FYI. Discussion and reactions to IETF mailing list, 
[email-masked] please.

Thanks,
Bert 

-----Original Message-----
From: The IESG [mailto:[email-masked]]
Sent: woensdag 4 december 2002 17:09
Subject: IETF Sub-IP area: request for input

IETF SUB-IP area

 The IESG announced in November of 2000 that a new SUB-IP temporary
 pseudo-area would be formed as a part of an effort to develop a 
 "systematic approach to dealing with what we used to describe as 
 "sub-IP" technologies." At the time the IESG said:

 "Over the years the boundary between 'wires' and IP protocols has 
 become harder to define and the interaction has become more intertwined. 
 For example, what appear as 'wires' or 'circuits' in a virtual network 
 may in fact be routed datagrams in an underlying IP network. The 
 topology of dynamic underlying networks such as ATM and soon switched 
 optical networks can interact with IP-level traffic engineering and 
 routing. Additionally, with IETF technologies such as MPLS we are  
 defining a whole new class of 'wires'." 
 (http://www.ietf.org/IESG/STATEMENTS/new-area.txt)

 After the December 2000 IETF meeting and taking into account the 
 discussion at that meeting the IESG formed a "temporary" SUB-IP Area. 
 IN the announcement of this action the IESG said:

 "It is temporary because the IESG believes that this concentrated 
 sub-IP effort will likely be of short duration, on the order of a year 
 or two. We feel that much of the work will be done by then, and the 
 working groups closed. Any working groups that have not finished when 
 the IESG determines that the area should be closed will be moved into 
 existing the IETF areas where they seem to have the best fit." and "The 
 IESG expects to review the development process and charters, however; 
 if we conclude that this expectation is incorrect, we will need to make 
 this area more formal. At that point, the nominating committee will be 
 asked to supply dedicated area directors." 
 (http://www.ietf.org/IESG/STATEMENTS/sub_area.txt)

 Although the SUB-IP working groups have made considerable progress 
 (with 7 RFCs published, another 12 IDs approved for publication, 9 IDs 
 under IESG consideration and an additional 11 IDs having been passed to 
 the ADs for their evaluation) their work is not yet done (with 53 
 working group IDs currently in progress). It does appear that some of 
 the working groups could finish the work in their charters over the next 
 6 months but it could be a lot longer for others.

 Because the end is in sight for some of the working groups and since the
 IESG had generally assumed that the area would be a temporary one and 
 the second anniversary of the creation of the SUB-IP area is next spring,
 analysis was started in the IESG to figure out which areas would be the
 best ones for the SUB-IP working groups to move to so that they could
 continue their work.

 As part of that analysis a SUB-IP area session was held during the IETF
 meeting in Atlanta where this topic was discussed.

 There was a spirited discussion during the session on the best path
 forward. The opinions ranged from following the distribution of
 working groups, to doing so with some specific changes to keeping the
 working groups in a separate SUB-IP area. A sense of the room was
 taken at the end of the discussion and that sense was very strongly
 that the SUB-IP Area should become a "long-term" (the description that
 was used during the consensus call) one and that the nomcom be asked
 to nominate a person (or persons) to become director(s) of the SUB-IP
 area.

 To help provide more information as input for the IESG discussion we 
 would like to continue the discussion started in Atlanta on the mailing 
 list. It is our intention to keep the discussion on the future of the 
 SUB-IP area open, but short-lived, because it would be a very good idea 
 to let the nomcom know ASAP what the future holds as they need to know 
 what expertise is needed in the ADs for the existing areas and if they 
 need to search for additional people.

 The IESG aim is to be able to let the nomcom know what the future of 
 the SUB-IP work is by the end of the day of Thursday Dec 12th. That 
 date was chosen because it is the date of the next IESG teleconference 
 yet it provides some time for a public discussion.

 The options seem to be:
                 1/ move WGs (back) to permanent areas: migrate the SUB-IP 
 working groups to other IETF areas sometime soon, likely before next 
 summer and close the SUB-IP area. Also, reconstitute the SUB-IP (and/or 
 other) directorates to ensure the continued coordination between the 
 remaining WGs.

                 2/ establish a long-term area: decide that the SUB-IP 
 area will be a long-term one, clearly define its charter, and ask the 
 nomcom to select one or two people to be Area Directors

                 3/ status quo: continue the SUB-IP Area as a temporary, 
 ad-hoc effort, much as it has been, with the IESG selecting two sitting 
 ADs to continue the effort that Bert & Scott have been doing. But maybe 
 give more responsibility to the working group's technical advisors, 
 normally the AD from the area where the working group might otherwise 
 live.

 Data points for the discussion:

 DP1. It does look like a number of the SUB-IP working groups will be
 finishing up their main work in the next year and be ready to be closed
 until it is time to revise the RFCs based on experience or to advance 
 them on the standards track. The groups that should be finishing up 
 include ipo, gsmp and tewg. That would leave mpls, ppvpn and ccamp.

 DP2. WGs in SUB-IP or the work pursued in them came from existing
 well-established areas, i.e., tewg came from OPS, gsmp, mpls (with ccamp
 and ppvpn as its derivatives) came from RTG.

 DP3. There's still a need for technical oversight from permanent areas, 
 so some WGs have a technical advisor--normally the AD from the area 
 where the working group might otherwise live (e.g. CCAMP, and PPVPN 
 with a RTG AD as the TA).

 DP4. SUB-IP directorate was very useful when the area was just created. 
 It is currently passive and WGs continue operating just fine.

 DP5. The sense of the SUB-IP session in Atlanta was that the SUB-IP 
 Area was working and there is no compelling reason to break it up. 
 There is a need to clarify the charters of some of the working groups 
 so that the different groups understand what the division of tasks are 
 but it is hard to identify what problem would be solved by breaking up 
 the area.

 DP6. Extensions to specific IETF technologies should be done in the 
 working groups responsible for those technologies based on requirements 
 provided by other working groups. For example, extensions to OSPF 
 should be done by the OSPF working group based on input from other 
 working groups or individuals rather than being done someplace else.

 Discussions about the options:

 1/ Move WGs (back) to permanent areas and close the area

 For:

 Each WG within SUB-IP definitely has a strong feature that maps it to a
 given permanent area [1]. The property that logically holds them together
 in SUB-IP now is the need for coordination wrt the technologies that are
 normally considered below the IP layer. While this was indeed necessary
 right after SUB-IP creation, DP4 suggests that the goal has been achieved
 and the focus is shifting back to coordination with permanent areas (e.g.,
 DP3, as well as the fact that RTG WGs are already dealing with SUB-IP
 related extensions). DP1 suggests that there will be about three active 
 WGs within a year; at least two of them can be argued to belong in RTG 
 area (where they originally came from, see DP2), so it wouldn't make a 
 lot of sense to have two separate areas overlapping so considerably. 
 PPVPN does not map strongly to any area, however it doesn't map strongly 
 to SUB-IP either (MPLS is just one possible encapsulation method)

 Against:

 DP5 suggests that the feeling in the room was against closing the area,
 though there was also some support for the idea that moving MPLS and 
 CCAMP to RTG would be a fine idea if the area were to be closed. The 
 feeling was that the area has been working and that there is no strong 
 argument that there is a need to change things at this time.

 2/ Establish a long-term area

 For:

 DP5 suggests that the community believes this is a good idea. See also 
 the "Against" for option 1. In addition the opinion was expressed that 
 having a specific area with specifically assigned management, 
 knowledgeable in the field, would be an advantage. In addition, new 
 SUP-IP work may develop in the future and it would be good to have a 
 home for it.

 Against:

 See "For" arguments for option 1 above. Also, there was an assumption 
 when the area was formed that it would be temporary and the size of the 
 IESG is near max effective size. It is also expected that if the nomcom
 needs to find an AD(s) for SUB-IP, the set of required skills would
 be extremely similar to those needed for the RTG area, which again 
 brings up the question of whether it makes sense to have two areas 
 with so similar expertise scopes.

 3/ Status quo

 For:

 DP5 suggests that the way the area operates is fine and does not need
 fixing at this time. As DP1 predicts, there may not be many active
 SUB-IP working groups within a year and it may be best to wait until
 a few of the working groups finish their work and close before deciding 
 on the long term direction for this work. The IESG would decide which 
 ADs would be asked to manage the area in March.

 Against:

   A decision has to be made sooner or later, delaying the decision will 
 not make it any easier to make.

 The IESG would like to hear from the community on this topic - please
 direct your comments to the [email-masked] list.

 The IESG will discuss the matter in its next telechat on December 12.

 --------------------------------------------------
 [1] possible WG to area mappings:

         - IPO has the IP-over-foo property, which is usually addressed 
 in INT,

         - GSMP came from RTG

         - MPLS (aside from the fact that it came from RTG) deals with a
 technology that is arguably another IP forwarding paradigm and relies
 heavily on regular routing functionality and/or protocols.

         - CCAMP works on a generalized version of MPLS, which could map 
 it to RTG as well

         - TEWG came from O&M

         - PPVPN: suggestions have been made of INT, because its tunneling 
 which is closest to INT, RTG because some of the suggested discovery and 
 VPN routing mechanisms, and TSV, because its related to PWE3 (in TSV 
 because of congestion control worries)

Delivery-date: Wed, 04 Dec 2002 09:17:28 -0800
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
To: "Kireeti Kompella <kireeti" <[email-masked]>
Cc: "<ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 4 Dec 2002 18:15:27 +0100

I think that this is a useful document and it shall became a WG document.

Diego.

----------------------------------------------------------------
Diego Caviglia
Optical Network - ASON strategy
E-mail: [email-masked]
Tel: +39 0 10 6003 808
Via A. Negrone 1A 16153 Genoa (Italy)
----------------------------------------------------------------
Fatti non foste a viver come bruti
ma per seguir virtute e canoscenza

Dante Alighieri Inferno Canto XXVI

Kireeti Kompella <[email-masked]>@ops.ietf.org on 03/12/2002 20.39.02

Sent by:  [email-masked]

To:   <[email-masked]>
cc:

Subject:  WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi,

This is a call for consensus to make the above document a CCAMP WG
document.  This call will end Dec 17, 2002.

Please indicate your opinion by replying to this email.

Thanks,
Kireeti.

Delivery-date: Wed, 04 Dec 2002 09:14:18 -0800
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: Overlay draft and OIF history...
Date: Wed, 4 Dec 2002 12:13:19 -0500

This is a multi-part message in MIME format.

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

I consider the Swallow overlay draft appropriate for development in this =
WG.

Wrt NSAPs, see RFC1888

Adrian
  ----- Original Message -----=20
  From: Greg Bernstein=20
  To: [email-masked]=20
  Sent: Wednesday, December 04, 2002 11:09 AM
  Subject: Overlay draft and OIF history...

  Hi all, it's great to see a draft and this much support for a UNI =
model which seems necessary when offering support out to the edge of =
"connection oriented services". =20

  =20

  This is very similar to the original OIF UNI work, until a huge issue =
arose over supported address types.  The initial thrust was for only IP =
address types (v4 and v6).  However this didn't fly with a bunch of =
folks with installed networks using NSAPs.  However it was never really =
clear, to me, that NSAPs were needed, i.e., the optical control plane =
was to be IP based and any other "addresses" could be viewed as "names" =
and translated when and if necessary.  Note that all previous SONET/SDH =
standards specified OSI stacks on the "in band" data communications =
channels (if you were wondering how we got into this mess).

  =20

  This is an area that could use a bit of thinking since from the ITU-T =
perspective other (non IP) address are desirable.  And it would be nice =
to harmonize the work at the various standards bodies.

  =20

  Greg B.

  =20

  Greg Bernstein, Grotto-Networking

  =20

------=_NextPart_000_0332_01C29B8E.88426870
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:[email-masked]" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>P.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
P.MsoPlainText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN-LEFT: 0in; =
MARGIN-RIGHT: 0in; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
LI.MsoPlainText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN-LEFT: 0in; =
MARGIN-RIGHT: 0in; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
DIV.MsoPlainText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN-LEFT: 0in; =
MARGIN-RIGHT: 0in; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: =
personal-compose; mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; =
mso-bidi-font-size: 10.0pt; mso-ascii-font-family: Arial; =
mso-hansi-font-family: Arial; mso-bidi-font-family: Arial
}
SPAN.SpellE {
	mso-style-name: ""; mso-spl-e: yes
}
SPAN.GramE {
	mso-style-name: ""; mso-gram-e: yes
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--></HEAD>
<BODY bgColor=3D#ffffff lang=3DEN-US link=3Dblue style=3D"tab-interval: =
.5in"=20
vLink=3Dpurple>
<DIV><FONT face=3DCourier size=3D2>I consider the Swallow overlay draft =
appropriate=20
for development in this WG.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Wrt NSAPs, see RFC1888</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[email-masked]"=20
  title=[email-masked]>Greg Bernstein</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:[email-masked]"=20
  title=[email-masked]>[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, December 04, =
2002 11:09=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Overlay draft and OIF=20
  history...</DIV>
  <DIV><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt">Hi all, it&#8217;s great =
to see a draft=20
  and this much support for a UNI model which seems necessary when =
offering=20
  support out to the edge of &#8220;connection oriented =
services&#8221;.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt">This is very similar to =
the=20
  original OIF UNI work, until a huge issue arose over supported address =
types.=20
  <SPAN style=3D"mso-spacerun: yes">&nbsp;</SPAN>The initial thrust was =
for only=20
  IP address types (v4 and v6).<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
  </SPAN>However this didn&#8217;t fly with a bunch of folks with =
installed networks=20
  using <SPAN class=3DSpellE>NSAPs</SPAN>.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>However it was never really clear, to me, that <SPAN=20
  class=3DSpellE>NSAPs</SPAN> were needed, i.e., the optical control =
plane was to=20
  be IP based and any other &#8220;addresses&#8221; could be viewed as =
&#8220;names&#8221; and=20
  translated when and if necessary.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>Note that all previous SONET/SDH standards specified OSI stacks =
on the=20
  &#8220;in band&#8221; data communications channels (if you were =
wondering how we got into=20
  this mess).<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt">This is an area that =
could use a=20
  bit of thinking since from the ITU-T <SPAN =
class=3DGramE>perspective</SPAN>=20
  other (non IP) address are desirable.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>And it would be nice to harmonize the work at the various =
standards=20
  bodies.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt">Greg=20
  B.<o:p></o:p></SPAN></FONT></P>
  <DIV=20
  style=3D"BORDER-BOTTOM: windowtext 1pt solid; BORDER-LEFT: medium =
none; BORDER-RIGHT: medium none; BORDER-TOP: medium none; =
PADDING-BOTTOM: 1pt; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; PADDING-TOP: =
0in; mso-border-bottom-alt: solid windowtext .75pt">
  <P class=3DMsoNormal=20
  style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; =
BORDER-RIGHT: medium none; BORDER-TOP: medium none; PADDING-BOTTOM: 0in; =
PADDING-LEFT: 0in; PADDING-RIGHT: 0in; PADDING-TOP: 0in; =
mso-border-bottom-alt: solid windowtext .75pt; mso-padding-alt: 0in 0in =
1.0pt 0in"><FONT=20
  face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-FAMILY: Arial; FONT-SIZE: 10pt">Greg Bernstein,=20
  Grotto-Networking<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML=
>

------=_NextPart_000_0332_01C29B8E.88426870--

Delivery-date: Wed, 04 Dec 2002 09:12:54 -0800
Date: Wed, 04 Dec 2002 18:11:27 +0100
From: Loa Andersson <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

sure thing - this is useful

/Loa

Kireeti Kompella wrote:
> Hi,
> 
> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
> 
> Please indicate your opinion by replying to this email.
> 
> Thanks,
> Kireeti.
> 
> 
> 
> 

-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           [email-masked]

Delivery-date: Wed, 04 Dec 2002 09:12:26 -0800
Date: Wed, 04 Dec 2002 12:10:33 -0500
From: David Charlap <[email-masked]>
To: IETF CCAMP List <[email-masked]>
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Kireeti Kompella wrote:
> 
> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
> 
> Please indicate your opinion by replying to this email.

Looks good to me.

The draft doesn't seem to change the behavior of any protocols, but it 
does clarify the correct behavior when used to create an overlay network.

I think this draft would be useful as an informational document.

I vote for WG acceptance.

-- David

Delivery-date: Wed, 04 Dec 2002 08:53:39 -0800
Date: Wed, 04 Dec 2002 11:52:44 -0500
To: [email-masked], Ron Bonica <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: New CCAMP charter
Cc: [email-masked]

Hi Kireeti and Ron,

Will you propose a draft for the new CCAMP charter, in particular some text 
to cover multi-area TE, ... ?

Thanks.

JP.

Delivery-date: Wed, 04 Dec 2002 08:49:41 -0800
Date: Wed, 04 Dec 2002 11:45:17 -0500
To: Ayan Banerjee <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: GMPLS in overlay mode
Cc: [email-masked]

         I think this document is very practical and useful.

         --Tom

>-----Original Message-----
>From: Kireeti Kompella [mailto:[email-masked]]
>Sent: Tuesday, December 03, 2002 11:38 AM
>To: Stephen Trowbridge
>Cc: Yangguang Xu; [email-masked]
>Subject: GMPLS in overlay mode
>
>
>Hi Steve,
>
>On Tue, 3 Dec 2002, Stephen Trowbridge wrote:
>
> > > c) the IETF has every right to "bring up" topics that other forums may
> > >         or may not already have discussed, lengthily or otherwise,
> > >         especially when it concerns protocols that the IETF developed.
> >
> > As I recall the OIF discussion, vendors were split over the proposal,
> > and operators indicated strongly that their needs were better addressed by
> > the ongoing UNI and NNI work.
>
>That's useful information.  However, it does not mean that we shouldn't
>discuss it in the IETF; nor on the other hand does it mean that we (the
>IETF/CCAMP WG) cannot learn from the OIF experience.
>
> > Certainly it would make sense for IETF to take up a proposal that another
> > standards body had rejected IF they are trying to address a different
>market
> > or application for which this proposal might be an appropriate solution.
>
>Let me re-iterate: the OIF is *not* a standards body.
>
>Furthermore, if I understood the authors correctly, there *are* addressing
>a different application.
>
> > When I suggested that a requirements document might be the correct first
> > step here during the meeting, one of the authors described this as a
>stalling
> > tactic. What I had in mind was to use this as a time saving tactic:
>
>The "overlay" document essentially describes a *mode* of using GMPLS.
>There are no major extensions; there are a few procedural changes.  It
>is basically a clarification document that says that GMPLS (which many
>just assume can only be used in "peer" mode) can in fact be used in
>an overlay context.
>
>A call for consensus to make this a WG document should indicate whether
>folks think this is useful or not.
>
>Kireeti.

Delivery-date: Wed, 04 Dec 2002 08:40:35 -0800
content-class: urn:content-classes:message
Subject: RE: Overlay draft and OIF history...
Date: Wed, 4 Dec 2002 16:43:21 -0000
From: "Jorge Pinto" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C29BB4.41393370
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On a personal note, one GOOD reason to use NSAPs is that if you use the
Network Entity Title format, for instance, not only you're able to
imediateley identify the ethernet MAC address of the Network Element
you're trying to reach, you have a much larger Address space than in IP
(v4, which is what everyone will have for many years to come), it's
intrinsicaly more secure since not every "jack" has an Osi stack
implementation to hack your network, and last but not least... it's what
ITU recommends (try saying to an operator that your NE ONLY talks IP).
But IP is gaining, and we, vendors using/supporting OSI, are taking
notice of that, and are already installing OSI2IP and IP2OSI layers...
for the Control Plane flavor of the month...
About the "names" transalation suggestion... my guess is that you got to
be joking :-).
Best regards,
=20
Jorge Pinto
Siemens IC R&D ON
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Greg Bernstein
Sent: Quarta-feira, 4 de Dezembro de 2002 16:10
To: [email-masked]
Subject: Overlay draft and OIF history...

Hi all, it's great to see a draft and this much support for a UNI model
which seems necessary when offering support out to the edge of
"connection oriented services". =20
=20
This is very similar to the original OIF UNI work, until a huge issue
arose over supported address types.  The initial thrust was for only IP
address types (v4 and v6).  However this didn't fly with a bunch of
folks with installed networks using NSAPs.  However it was never really
clear, to me, that NSAPs were needed, i.e., the optical control plane
was to be IP based and any other "addresses" could be viewed as "names"
and translated when and if necessary.  Note that all previous SONET/SDH
standards specified OSI stacks on the "in band" data communications
channels (if you were wondering how we got into this mess).
=20
This is an area that could use a bit of thinking since from the ITU-T
perspective other (non IP) address are desirable.  And it would be nice
to harmonize the work at the various standards bodies.
=20
Greg B.
=20
Greg Bernstein, Grotto-Networking
=20

------_=_NextPart_001_01C29BB4.41393370
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:[email-masked]" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in =
1.25in; mso-header-margin: .5in; mso-footer-margin: .5in; =
mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
P.MsoPlainText {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
LI.MsoPlainText {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
DIV.MsoPlainText {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: =
personal-compose; mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; =
mso-bidi-font-size: 10.0pt; mso-ascii-font-family: Arial; =
mso-hansi-font-family: Arial; mso-bidi-font-family: Arial
}
SPAN.SpellE {
	mso-style-name: ""; mso-spl-e: yes
}
SPAN.GramE {
	mso-style-name: ""; mso-gram-e: yes
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--></HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: .5in" vLink=3Dpurple =
link=3Dblue>
<DIV><SPAN class=3D255352916-04122002><FONT face=3DArial color=3D#0000ff =
size=3D2>On a=20
personal note, one GOOD reason to use NSAPs is that if you use the =
Network=20
Entity Title format, for instance, not only you're able to=20
imediateley&nbsp;identify the ethernet MAC address of the Network =
Element you're=20
trying to reach, you have a much larger Address space than in IP (v4, =
which is=20
what everyone will have for many years to come), it's intrinsicaly more =
secure=20
since not every "jack" has an Osi stack implementation to hack your =
network, and=20
last but not least... it's what ITU recommends (try saying to an =
operator that=20
your NE&nbsp;ONLY talks IP).</FONT></SPAN></DIV>
<DIV><SPAN class=3D255352916-04122002><FONT face=3DArial color=3D#0000ff =
size=3D2>But IP=20
is gaining, and we, vendors&nbsp;using/supporting OSI, are taking notice =
of=20
that, and are already installing OSI2IP and IP2OSI layers... for the =
Control=20
Plane flavor of the month...</FONT></SPAN></DIV>
<DIV><SPAN class=3D255352916-04122002><FONT face=3DArial color=3D#0000ff =
size=3D2>About=20
the "names" transalation suggestion... my guess is that you got to be =
joking=20
:-).</FONT></SPAN></DIV>
<DIV><SPAN class=3D255352916-04122002><FONT face=3DArial color=3D#0000ff =
size=3D2>Best=20
regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D255352916-04122002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D255352916-04122002><FONT face=3DArial color=3D#0000ff =
size=3D2>Jorge=20
Pinto</FONT></SPAN></DIV>
<DIV><SPAN class=3D255352916-04122002><FONT face=3DArial color=3D#0000ff =

size=3D2>Siemens IC R&amp;D ON</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>Greg=20
  Bernstein<BR><B>Sent:</B> Quarta-feira, 4 de Dezembro de 2002=20
  16:10<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Overlay =
draft and=20
  OIF history...<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi all, it's great to =
see a draft=20
  and this much support for a UNI model which seems necessary when =
offering=20
  support out to the edge of "connection oriented services".<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This is very similar to =
the=20
  original OIF UNI work, until a huge issue arose over supported address =
types.=20
  <SPAN style=3D"mso-spacerun: yes">&nbsp;</SPAN>The initial thrust was =
for only=20
  IP address types (v4 and v6).<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
  </SPAN>However this didn't fly with a bunch of folks with installed =
networks=20
  using <SPAN class=3DSpellE>NSAPs</SPAN>.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>However it was never really clear, to me, that <SPAN=20
  class=3DSpellE>NSAPs</SPAN> were needed, i.e., the optical control =
plane was to=20
  be IP based and any other "addresses" could be viewed as "names" and=20
  translated when and if necessary.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>Note that all previous SONET/SDH standards specified OSI stacks =
on the=20
  "in band" data communications channels (if you were wondering how we =
got into=20
  this mess).<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This is an area that =
could use a=20
  bit of thinking since from the ITU-T <SPAN =
class=3DGramE>perspective</SPAN>=20
  other (non IP) address are desirable.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>And it would be nice to harmonize the work at the various =
standards=20
  bodies.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Greg=20
  B.<o:p></o:p></SPAN></FONT></P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 1pt; BORDER-LEFT: medium =
none; PADDING-TOP: 0in; BORDER-BOTTOM: windowtext 1pt solid; =
mso-border-bottom-alt: solid windowtext .75pt">
  <P class=3DMsoNormal=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium =
none; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; =
mso-border-bottom-alt: solid windowtext .75pt; mso-padding-alt: 0in 0in =
1.0pt 0in"><FONT=20
  face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Greg Bernstein,=20
  Grotto-Networking<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML=
>

------_=_NextPart_001_01C29BB4.41393370--

Delivery-date: Wed, 04 Dec 2002 08:40:03 -0800
From: Ayan Banerjee <[email-masked]>
To: [email-masked]
Subject: RE: GMPLS in overlay mode
Date: Wed, 4 Dec 2002 08:39:04 -0800 

I beleive that this is useful.

Thanks,
Ayan

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 11:38 AM
To: Stephen Trowbridge
Cc: Yangguang Xu; [email-masked]
Subject: GMPLS in overlay mode

Hi Steve,

On Tue, 3 Dec 2002, Stephen Trowbridge wrote:

> > c) the IETF has every right to "bring up" topics that other forums may
> >         or may not already have discussed, lengthily or otherwise,
> >         especially when it concerns protocols that the IETF developed.
>
> As I recall the OIF discussion, vendors were split over the proposal,
> and operators indicated strongly that their needs were better addressed by
> the ongoing UNI and NNI work.

That's useful information.  However, it does not mean that we shouldn't
discuss it in the IETF; nor on the other hand does it mean that we (the
IETF/CCAMP WG) cannot learn from the OIF experience.

> Certainly it would make sense for IETF to take up a proposal that another
> standards body had rejected IF they are trying to address a different
market
> or application for which this proposal might be an appropriate solution.

Let me re-iterate: the OIF is *not* a standards body.

Furthermore, if I understood the authors correctly, there *are* addressing
a different application.

> When I suggested that a requirements document might be the correct first
> step here during the meeting, one of the authors described this as a
stalling
> tactic. What I had in mind was to use this as a time saving tactic:

The "overlay" document essentially describes a *mode* of using GMPLS.
There are no major extensions; there are a few procedural changes.  It
is basically a clarification document that says that GMPLS (which many
just assume can only be used in "peer" mode) can in fact be used in
an overlay context.

A call for consensus to make this a WG document should indicate whether
folks think this is useful or not.

Kireeti.

Delivery-date: Wed, 04 Dec 2002 08:39:18 -0800
Date: Wed, 04 Dec 2002 11:37:17 -0500
To: Kireeti Kompella <[email-masked]>
From: "Andrew G. Malis" <[email-masked]>
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Cc: <[email-masked]>

Kireeti,

I would just like to add my voice to the support for making this a WG draft 
- I expect this will be a very useful deployment scenario.

Cheers,
Andy

-------

At 12/3/2002 11:39 AM -0800, Kireeti Kompella wrote:
>Hi,
>
>This is a call for consensus to make the above document a CCAMP WG
>document.  This call will end Dec 17, 2002.
>
>Please indicate your opinion by replying to this email.
>
>Thanks,
>Kireeti.

Delivery-date: Wed, 04 Dec 2002 08:12:03 -0800
From: "Greg Bernstein" <[email-masked]>
To: <[email-masked]>
Subject: Overlay draft and OIF history...
Date: Wed, 4 Dec 2002 08:09:36 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C29B6C.7CEB64D0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi all, it's great to see a draft and this much support for a UNI model
which seems necessary when offering support out to the edge of =
"connection
oriented services". =20
=20
This is very similar to the original OIF UNI work, until a huge issue =
arose
over supported address types.  The initial thrust was for only IP =
address
types (v4 and v6).  However this didn't fly with a bunch of folks with
installed networks using NSAPs.  However it was never really clear, to =
me,
that NSAPs were needed, i.e., the optical control plane was to be IP =
based
and any other "addresses" could be viewed as "names" and translated when =
and
if necessary.  Note that all previous SONET/SDH standards specified OSI
stacks on the "in band" data communications channels (if you were =
wondering
how we got into this mess).
=20
This is an area that could use a bit of thinking since from the ITU-T
perspective other (non IP) address are desirable.  And it would be nice =
to
harmonize the work at the various standards bodies.
=20
Greg B.
=20
Greg Bernstein, Grotto-Networking
=20

------=_NextPart_000_0003_01C29B6C.7CEB64D0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

------=_NextPart_000_0003_01C29B6C.7CEB64D0--

Delivery-date: Wed, 04 Dec 2002 07:06:02 -0800
content-class: urn:content-classes:message
Subject: comments on draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
Date: Wed, 4 Dec 2002 15:07:10 -0000
From: "Jorge Pinto" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hello OSPF for GMPLS fans,

I have some comments regarding Bandwidth advertisments as intended on =
draft-ietf-ccamp-ospf-gmpls-extensions-09.txt.

Although there are many different issues that i would like to comment on =
this document, i will refrain myself to a discussion only on the =
"unreserved LSP bandwidth" advertisment... (yes, i'm testing the =
open-mindness of this list).

In technologies that do not allow over-booking (SDH/SONET is my prime =
concern), the Max LSP bandwidth, the reserved LSP bandwidth at each =
priority 'p' and the external (i'll explain what "external" means... =
later on) bandwidth are the true descriptors of allocated Bandwidth =
resources for a link.
The unreserved LSP bandwidth at priority 'p' is a definition dependent =
on the pre-emption of lower-priority LSPs, and does not account for =
"external" (not exactly legacy) resource usage. If you take the =
following example you'll see what i'm getting at (i'm sorry if your =
mailer is not using a constant-width font):
Max LSP BW=3D100 (as in "GMPLS manages it all")

LSP Prio|LSP Res BW|LSP UnRes BW
  0     |     0    |    100 (it can pre-empt all of the other lower =
prios!)        =20
  1     |     2    |    98
  2     |     0    |    98  (it takes into account only 'p' priorities < =
2)
  3     |    10    |    88
  4     |     0    |    88
  5     |     0    |    88
  6     |     0    |    88
  7     |    10    |    78  (which is the "no-preemption" available BW)

Now, consider that it would be VERY nice to have GMPLS as an add-on to =
many already depployed Network Managment Systems, and even if GMPLS is =
used in a large extent, there will be a considerenly large number of =
resources that GMPLS will NOT manage (but will have to account for, for =
inter-operability with non-GMPLS managment). This is what i'm =
considering the external BW allocated (note that the numeric values may =
not even match at both ends of a link).
Evindentely, by cross-matching of Network-Element and GMPLS MIBs one can =
compute the external bandwidth allocated per interface and the LSP =
BWs... i'm still waiting for this "external BW" metric to be included on =
the TE LSAs (since it may reduce the Available GMPLS BW, regardless of =
how large the Max LSP BW is set to).

However, i agree that the LSP unreserved BW is an easy method to account =
for GMPLS resource usage... but it is incomplete.
IMHO, it should be evident that there will always be the requirement of =
some operators to have "sacro-saint" paths that GMPLS respects and =
cannot manage, and the Max LSP bandwidth allowed is basically a initial =
configuration value (not a rule).
The other reason why the Unreserved BW is not sufficient is that it =
works under the priciple of pre-emption (as demonstrated on the =
example). However, we should accomodate the possibility (tested by us) =
of alternative routing strategies that only resort to pre-emption of =
lower priorities resources, iff "everything else fails". I should also =
say that this strategy is already demonstrated and proofed, and it could =
well fall on the definition of a "proprietary CSPF-TE", something that =
ccamp actually advises.
On the conceptual point of view, i think it is best to advertise what BW =
the Interface actually has allocated (LSP reserved BW at each prio, Max =
LSP Bw and externally allocated BW) than the estimate of how much BW =
could an LSP at priority 'p' WOULD be able to reserve, on the absense of =
non-GMPLS management entities.

To keep the mail short, but still open to a broader discussion,

Best regards,

Jorge Pinto
Siemens IC R&D ON
mail: [email-masked]
phone: (+351) 21 417 8147
I-want-you-to-think-I'm-very-smart-quote "If NT is the answer, you did =
not understand the question..."

Delivery-date: Wed, 04 Dec 2002 05:13:18 -0800
From: Apratim Mukherjee <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Source IP Address in GMPLS messages
Date: Wed, 4 Dec 2002 01:57:50 -0600

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi

    These are the lines from RFC 2961 for refresh reduction .
"The source IP address of an Srefresh message is an address of the node that
generates the message. The source IP address MUST match the address
associate with the MESSAGE_ID objects when they were included in a standard
RSVP message. As previously mentioned, the source address associated with a
MESSAGE_ID object is represented in a per RSVP message type specific
fashion. For messages with RSVP_HOP objects, such as Path and Resv messages,
the address is found in the RSVP_HOP object."

In a gmpls network , for a node with multiple interfaces say with address
a1,a2,a3 and a node ip a,if the node is sending address a1 as the address in
the control channel part of PHOP in Path message , does the above lines make
it a MUST for that node to also send a1 as the source IP for the SRefresh
message corresponding to that Path message ? ( This is assuming that it is
NOT using 'a' as the source IP , in which case we dont have a problem )
Or should we be ready to get the Path message with 'a1' as the ip address in
the control channel part of PHop and subsequently , the SRefresh
corresponding to this path message with say a2 or even 'a' as the node ip ?

Thanks a lot ,
Apratim 

Delivery-date: Wed, 04 Dec 2002 04:39:34 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
Date: Wed, 04 Dec 2002 07:35:12 -0500

--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		: OSPF Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella, Y. Rekhter
	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
	Pages		: 12
	Date		: 2002-12-3
	
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-09.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-ospf-gmpls-extensions-09.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-ospf-gmpls-extensions-09.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-ospf-gmpls-extensions-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-ospf-gmpls-extensions-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 04 Dec 2002 02:36:26 -0800
Date: Wed, 04 Dec 2002 11:38:35 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Vikram Anantha <[email-masked]>
CC: [email-masked]
Subject: Re: GMPLS Protection and Restoration Design Team - Report

hi, i thought i had already responded to the first point 
on dynamic restoration issue (in brief it is within the 
scope), please refer to my previous e-mail, now concerning 
the difference between a scheme and type, first it is 
orthogonal to previous point and secondly i suggest you 
take at the section 5.4 where the definition is provided 
"Section 4.6 of [CCAMP-TERM] defines the basic recovery 
types. [..] a recovery scheme is defined as the combination 
between different ingress-egress node pairs of a set of 
identical recovery types." take it here as a structural
way to describe shared meshed recovery; 

hope this clarifies,
- dimitri.

Vikram Anantha wrote:
> 
> [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>[email-masked] and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
> 
> Hi all,
> This is my second attempt at trying to contribute to the protection and
> restoration documents. It appears that the ccamp mailing list thinks my
> mail is a virus and filters it out. Maybe I need to ratchet up my
> rhetoric to fit in :).
> 
> Part of my confusion is probably trying to understand the scope of the
> terminology document
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-term
> inology-01.txt and the analysis document
> http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-reco
> very-analysis-03.txt.
> 
> Section 5.5 of the analysis document talks about "Restoration Schemes"
> and mentions Dynamic LSP Restoration like you pointed out. However
> Section 4.6 of the terminology document talks about "Recovery Types" and
> only mentions M:N type where M and N are pre-established. So maybe
> Section 4.6 needs a new "Recovery Type" a M:N where N is dynamically
> calculated?
> 
> Also on closer reading of TEWG's RFC 3386, I realized that this RFC
> definitely does not preclude dynamic restoration. It allows for it in
> the path and local restoration sections. So I will stop posting this to
> both mailing lists.
> 
> Thanks,
> 
> Vik
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, November 13, 2002 9:41 PM
> To: Vikram Anantha
> Cc: [email-masked]; [email-masked]
> Subject: Re: GMPLS Protection and Restoration Design Team - Report
> 
> hi
> 
> from the ccamp wg effort perspective, i think that the
> section 5.5.2 Dynamic LSP Restoration in the analysis
> i-d addresses your concern, it was not within the scope
> to preclude such capability, thus may i ask here what has
> in the current set of ccamp i-d implied such deduction,
> this may help us for further clarification
> 
> thanks,
> - dimitri.
> 
> Vikram Anantha wrote:
> >
> > It appears that the drafts produced by the TEWG design team and the
> > GMPLS protection and restoration design team refer mainly to
> > protection/restoration schemes where the protection capacity is either
> 
> > pre-calculated or is pre-established. This precludes dynamic
> > restoration schemes like "dynamic mesh restoration".
> >
> > IMHO this needs to be spelled out. If it has already been spelt out, I
> > would appreciate a pointer to it. This would also be inline with the
> > "Expected Document # 3" mentioned below.
> >
> > Vik
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Monday, November 11, 2002 7:39 AM
> > To: [email-masked]
> > Subject: GMPLS Protection and Restoration Design Team - Report
> >
> > ccamp'ers,
> >
> > Here below the report of the GMPLS protection and restoration design
> > team:
> >
> > Team goals were defined as follows:
> >
> > Starting point Protection & Restoration produced by the TEWG Design
> > Team. The produced functionality should satisfy these requirements;
> > content that goes beyond these requirements or doesn't meet some of
> > them should be called out so that the wg can re-evaluate.
> >
> > Expected documents:
> >
> > 1. Produce a terminology document, delivering a decoder ring to
> >    translate to terminology in current drafts as well as the TE
> >    WG document.
> >
> > 2. Produce an (interim) analysis document, comparing and contrasting
> >    approaches (i.e., the above drafts, published and ongoing work
> >    at the ITU/T1-X1/...)
> >
> >    note: from this perspective a decoder table on the current
> >    methodologies/mechanisms may be additionally delivered in (1)
> >
> > 3. Produce a functional spec delineating
> >
> >    - What's in scope, out of scope, what's for future study, which
> >    of the TEWG reqts have been met, which not, and what goes beyond.
> >
> >    - This document should detail the overall approach objects/
> >    procedures/... needed in a protocol-independent fashion
> >
> >    note: point one will be translated by delineating content and
> >    definition included in (1)
> >
> > 4. Produce protocol specification
> >
> >    4.1 Produce a document detailing the changes for RSVP-TE
> >
> >    4.2 Produce a document detailing the changes for OSFP-TE and
> > IS-IS-TE
> >
> > Timeline:
> >
> > - Ietf53 (march'02) both were discussed in minneapolis 1. (i.e.
> >   the terminology i-d) had become upon community agreement wg
> >   i-d
> >
> >   note: nearly on time with the initially expected timeline for
> >   this first step
> >
> > - Ietf54 (july'02) decision upon closing content to be
> >   included in the analysis i-d two weeks after the meeting
> >
> >   => A version -02.txt of the analysis i-d had been submitted
> >      end of august. Also a functional specification has been
> >      delivered at the same time (had not been submitted on time
> >      to be discussed during ietf54 meeting)
> >
> >   note: compared to the initially expected timeline, this was
> >   delayed by one ietf meeting
> >
> > - Ietf55 (nov'02) decision upon analysis and signalling
> >   functional specification to be discussed, once agreed
> >   work on 4.1 and 4.2 should started first discussion to
> >   be expected for Ietf56 (stabilizing protocol specification
> >   should be achievable during '03 time it would be take
> >   greatly depends upon the what's in/what's out/what's for
> >   the next step decision)
> >
> >   note: compared to the initially expected timeline, this was
> >   delayed by two ietf meetings
> >
> > Intermediate Conclusion:
> >
> > - Still some work to be produced in particular with respect
> >   to the protocol specification (expectation within a year
> >   for a first phase)
> >
> > - Delay can be explained in several ways 1) over time, the
> >   more we get into the details the more time it took to
> >   described and analyze the situation - as such the fact
> >   the scope is closed now will help in achieving a tolerable
> >   complexity level and allow for a first phase completion 2)
> >   the timeline was probably too tight in order to allow for
> >   any delay which has been accumulated after ietf'53
> >
> > See we in atlanta,
> >
> > thanks,
> > - dimitri (for the p&r dt).
> 
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 03 Dec 2002 23:28:13 -0800
Date: Wed, 04 Dec 2002 08:26:41 +0100
To: Kireeti Kompella <[email-masked]>
From: Monique Morrow <[email-masked]>
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Cc: <[email-masked]>

I support this as a CCAMP WG Doc.

//Monique

>Hi,
>
>This is a call for consensus to make the above document a CCAMP WG
>document.  This call will end Dec 17, 2002.
>
>Please indicate your opinion by replying to this email.
>
>Thanks,
>Kireeti.

Delivery-date: Tue, 03 Dec 2002 23:12:21 -0800
content-class: urn:content-classes:message
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Wed, 4 Dec 2002 02:10:03 -0500
From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>

> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
>=20
> Please indicate your opinion by replying to this email.

I support this as a CCAMP WG document.

Jerry Ash

Delivery-date: Tue, 03 Dec 2002 20:44:54 -0800
Date: Tue, 03 Dec 2002 23:42:24 -0500
To: John Drake <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, [email-masked]
From: Zafar Ali <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

--=====================_9260696==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

At 03:42 PM 12/3/2002 -0800, John Drake wrote:
>It should be a working group document

I second that opinion. I would also like to add that from day 1, GMPLS was=
=20
NOT design to address a particular service model only. Hence, it will be=20
unfair if someone says that GMPLS is ONLY limited to define a full-peer=20
model. In this regard, I would like to cite an already available=20
understanding stated in the GMPLS Architecture Draft=20
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-03.t=
xt,=20

"It (GMPLS) does not restrict the way that the layers work together.=20
Different models can be applied: e.g. overlay, augmented or integrated.=20
Moreover, each pair of contiguous layer may work jointly in a different=20
way, resulting in a number of possible combinations, at the discretion of=20
manufacturers and operators."

So, clearly the draft falls within the scope of IETF CCAMP/ GMPLS and=20
should be pursued further as a WG document for further discussions.

Re: overlap with OIF. The current OIF UNI specification defines a UNI=20
interface between a client SDH/SONET equipment and an SDH/SONET network,=20
each belonging to a distinct administrative authority (strict UNI with low=
=20
trust boundary). The draft addresses the case where there is a strong trust=
=20
between the Router and Optical (OXC based) network.

Thanks

Regards=85 Zafar

>-----Original Message-----
>From: Kireeti Kompella [mailto:[email-masked]]
>Sent: Tuesday, December 03, 2002 11:39 AM
>To: [email-masked]
>Subject: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
>
>
>Hi,
>
>This is a call for consensus to make the above document a CCAMP WG
>document.  This call will end Dec 17, 2002.
>
>Please indicate your opinion by replying to this email.
>
>Thanks,
>Kireeti.

--=====================_9260696==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<font size=3D3>At 03:42 PM 12/3/2002 -0800, John Drake wrote:<br>
<blockquote type=3Dcite cite>It should be a working group
document</font></blockquote><br>
<font size=3D3>I second that opinion. I would also like to add that from
day 1, GMPLS was NOT design to address a particular service model only.
Hence, it will be unfair if someone says that GMPLS is ONLY limited to
define a full-peer model. In this regard, I would like to cite an already
available understanding stated in the GMPLS Architecture Draft
<a=
 href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architec=
ture-03.txt" eudora=3D"autourl">http://www.ietf.org/internet-drafts/draft-ie=
tf-ccamp-gmpls-architecture-03.txt</a>,&nbsp;
<br>
<br>
&quot;It (GMPLS) does not restrict the way that the layers work together.
Different models can be applied: e.g. overlay, augmented or integrated.
Moreover, each pair of contiguous layer may work jointly in a different
way, resulting in a number of possible combinations, at the discretion of
manufacturers and operators.&quot;&nbsp; <br>
<br>
So, clearly the draft falls within the scope of IETF CCAMP/ GMPLS and
should be pursued further as a WG document for further discussions.=20
<br>
<br>
Re: overlap with OIF. The current OIF UNI specification defines a UNI
interface between a client SDH/SONET equipment and an SDH/SONET network,
each belonging to a distinct administrative authority (strict UNI with
low trust boundary). The draft addresses the case where there is a strong
trust between the Router and Optical (OXC based) network. <br>
<br>
Thanks<br>
<br>
Regards=85 Zafar <br>
<br>
<br>
<blockquote type=3Dcite cite>-----Original Message-----<br>
From: Kireeti Kompella
[<a href=3D"mailto:[email-masked]"=
 eudora=3D"autourl">mailto:[email-masked]</a>]<br>
Sent: Tuesday, December 03, 2002 11:39 AM<br>
To: [email-masked]<br>
Subject: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt<br>
<br>
<br>
Hi,<br>
<br>
This is a call for consensus to make the above document a CCAMP WG<br>
document.&nbsp; This call will end Dec 17, 2002.<br>
<br>
Please indicate your opinion by replying to this email.<br>
<br>
Thanks,<br>
Kireeti.</font></blockquote></html>

--=====================_9260696==_.ALT--

Delivery-date: Tue, 03 Dec 2002 18:06:14 -0800
Content-Class: urn:content-classes:message
Subject: RE: GMPLS Protection and Restoration Design Team - Report
Date: Tue, 3 Dec 2002 17:52:23 -0800
From: "Vikram Anantha" <[email-masked]>
To: "Vikram Anantha" <[email-masked]>, <[email-masked]>

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi all,
This is my second attempt at trying to contribute to the protection and
restoration documents. It appears that the ccamp mailing list thinks my
mail is a virus and filters it out. Maybe I need to ratchet up my
rhetoric to fit in :).

Part of my confusion is probably trying to understand the scope of the
terminology document
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-term
inology-01.txt and the analysis document
http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-reco
very-analysis-03.txt.

Section 5.5 of the analysis document talks about "Restoration Schemes"
and mentions Dynamic LSP Restoration like you pointed out. However
Section 4.6 of the terminology document talks about "Recovery Types" and
only mentions M:N type where M and N are pre-established. So maybe
Section 4.6 needs a new "Recovery Type" a M:N where N is dynamically
calculated?

Also on closer reading of TEWG's RFC 3386, I realized that this RFC
definitely does not preclude dynamic restoration. It allows for it in
the path and local restoration sections. So I will stop posting this to
both mailing lists.

Thanks,

Vik

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]=20
Sent: Wednesday, November 13, 2002 9:41 PM
To: Vikram Anantha
Cc: [email-masked]; [email-masked]
Subject: Re: GMPLS Protection and Restoration Design Team - Report

hi

from the ccamp wg effort perspective, i think that the=20
section 5.5.2 Dynamic LSP Restoration in the analysis=20
i-d addresses your concern, it was not within the scope=20
to preclude such capability, thus may i ask here what has=20
in the current set of ccamp i-d implied such deduction,=20
this may help us for further clarification

thanks,
- dimitri.

Vikram Anantha wrote:
>=20
> It appears that the drafts produced by the TEWG design team and the
> GMPLS protection and restoration design team refer mainly to=20
> protection/restoration schemes where the protection capacity is either

> pre-calculated or is pre-established. This precludes dynamic=20
> restoration schemes like "dynamic mesh restoration".
>=20
> IMHO this needs to be spelled out. If it has already been spelt out, I
> would appreciate a pointer to it. This would also be inline with the=20
> "Expected Document # 3" mentioned below.
>=20
> Vik
>=20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, November 11, 2002 7:39 AM
> To: [email-masked]
> Subject: GMPLS Protection and Restoration Design Team - Report
>=20
> ccamp'ers,
>=20
> Here below the report of the GMPLS protection and restoration design
> team:
>=20
> Team goals were defined as follows:
>=20
> Starting point Protection & Restoration produced by the TEWG Design
> Team. The produced functionality should satisfy these requirements;=20
> content that goes beyond these requirements or doesn't meet some of=20
> them should be called out so that the wg can re-evaluate.
>=20
> Expected documents:
>=20
> 1. Produce a terminology document, delivering a decoder ring to
>    translate to terminology in current drafts as well as the TE
>    WG document.
>=20
> 2. Produce an (interim) analysis document, comparing and contrasting
>    approaches (i.e., the above drafts, published and ongoing work
>    at the ITU/T1-X1/...)
>=20
>    note: from this perspective a decoder table on the current
>    methodologies/mechanisms may be additionally delivered in (1)
>=20
> 3. Produce a functional spec delineating
>=20
>    - What's in scope, out of scope, what's for future study, which
>    of the TEWG reqts have been met, which not, and what goes beyond.
>=20
>    - This document should detail the overall approach objects/
>    procedures/... needed in a protocol-independent fashion
>=20
>    note: point one will be translated by delineating content and
>    definition included in (1)
>=20
> 4. Produce protocol specification
>=20
>    4.1 Produce a document detailing the changes for RSVP-TE
>=20
>    4.2 Produce a document detailing the changes for OSFP-TE and
> IS-IS-TE
>=20
> Timeline:
>=20
> - Ietf53 (march'02) both were discussed in minneapolis 1. (i.e.
>   the terminology i-d) had become upon community agreement wg
>   i-d
>=20
>   note: nearly on time with the initially expected timeline for
>   this first step
>=20
> - Ietf54 (july'02) decision upon closing content to be
>   included in the analysis i-d two weeks after the meeting
>=20
>   =3D> A version -02.txt of the analysis i-d had been submitted
>      end of august. Also a functional specification has been
>      delivered at the same time (had not been submitted on time
>      to be discussed during ietf54 meeting)
>=20
>   note: compared to the initially expected timeline, this was
>   delayed by one ietf meeting
>=20
> - Ietf55 (nov'02) decision upon analysis and signalling
>   functional specification to be discussed, once agreed
>   work on 4.1 and 4.2 should started first discussion to
>   be expected for Ietf56 (stabilizing protocol specification
>   should be achievable during '03 time it would be take
>   greatly depends upon the what's in/what's out/what's for
>   the next step decision)
>=20
>   note: compared to the initially expected timeline, this was
>   delayed by two ietf meetings
>=20
> Intermediate Conclusion:
>=20
> - Still some work to be produced in particular with respect
>   to the protocol specification (expectation within a year
>   for a first phase)
>=20
> - Delay can be explained in several ways 1) over time, the
>   more we get into the details the more time it took to
>   described and analyze the situation - as such the fact
>   the scope is closed now will help in achieving a tolerable
>   complexity level and allow for a first phase completion 2)
>   the timeline was probably too tight in order to allow for
>   any delay which has been accumulated after ietf'53
>=20
> See we in atlanta,
>=20
> thanks,
> - dimitri (for the p&r dt).

--=20
Papadimitriou Dimitri=20
E-mail : [email-masked]=20
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 03 Dec 2002 17:40:31 -0800
Date: Wed, 04 Dec 2002 02:44:00 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: "Varma, Eve L (Eve)" <[email-masked]>
Cc: John Drake <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

hi at least to settle the two first ones, for the third
please clarify (i give it a try):

- application space: as said, overlaid control planes 
  where lsr and oxc's topologies inter-connection do 
  not require a high trust relationship (a typical 
  case lsr and oxc coming from different vendors 
  within the same administrative entity) 

- associated requirement: from the protocol viewpoint
  (i don't think we should enter into another level of
  discussion here) minimize the changes wrt to the 
  existing g/mpls signalling and ease of integration
  into existing routers and lsr -  

- distinguishing characteristics: would you please
  tell us with respect to what in the ietf scope ?
  but if i assume you mean here "capabilities" wrt
  to the oif solution, then from capability viewpoint 
  it allows for the use of fast notification, end-
  to-end recovery with soft-provisioning (and edge-
  to-edge) in addition to route pinning, this for 
  features i see as the most interesting ones, and
  if i assume "protocol differences" i would say
  nearly nothing wrt to the current gmpls def's.  

thanks,
- dimitri.

"Varma, Eve L (Eve)" wrote:
> 
> Hi all,
> 
> I do not believe it should be a WG document.  Clarification
> of the applications space, associated requirements, and
> distinguishing characteristics is really called for.
> 
> Best regards,
> Eve
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Tuesday, December 03, 2002 6:43 PM
> To: 'Kireeti Kompella'; [email-masked]
> Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> It should be a working group document
> 
> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Tuesday, December 03, 2002 11:39 AM
> To: [email-masked]
> Subject: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> Hi,
> 
> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
> 
> Please indicate your opinion by replying to this email.
> 
> Thanks,
> Kireeti.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 03 Dec 2002 17:36:02 -0800
Date: Wed, 04 Dec 2002 02:38:38 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Manoj Agiwal <[email-masked]>
Cc: "'Ccamp (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: make-before-break in Gmpls

hi,

i think this issue concerning "se style" has been discussed
some time ago but let's try here to give a bit more details,
lsp's in gmpls are control plane entities mapping data plane
ones, merging here does get sense if and only if the data
plane would deliver the same capability, since the soft-
provisioning that we can expect in shared meshed restoration
is purely a control plane driven mechanism the corresponding
entity doesn't occur at the data plane level and in particular
for tdm, lsc and fsc lsp's, once committed you find out the 
ff style as used today, as such there is no today something
like you seem to assume as setup of an lsp "split" it when 
a recovery lsp is needed and then "merge" it back when the
recovery lsp find back the working lsp path, then next even
if the methods that are under definition may be thought as
similar to the frr ones, the following for instance wouldn't
strictly apply (see fast-reroute):

"When using the sender-template-specific approach, the protected
LSPs and the backup paths SHOULD use the Shared Explicit (SE)
style. This allows bandwidth sharing between multiple backup
paths. The backup paths and the protected LSP MAY be merged by the
Detour Merge Points, when the ERO from the MP to the egress is the
same on each LSP to be merged, as specified in [RSVP-TE]."

this because for non-packet networks do soft-provisioning 
means let the capability to share the bandwidth on a control
plane view of the resource basis otherwise just provision 
it (commit it) since having a dedicated soft-provisioning 
on a per lsp basis just means be dedicated at the data plane 
level (if we assume a consistent usage of the mechanisms), 
and on the other side have merging (not multiplexing) of 
lsc or tdm at the data plane level is impossible (afaik) 
thus the fact that one knows that the requested lsp is for 
recovery purposes (link protection tlv s bit set) and its 
resources have to allocated within a pool but not committed 
(ie reserved) something which is needed in any case, do
the job here.  

hope this clarifies a bit,
- dimitri.

Manoj Agiwal wrote:
> 
> Hi ,
>          The gmpls architecture documents says
> "GMPLS does not add anything new. Elegant re-routing is possible with the
> concept of "make-before-break" whereby an old path is still used while a new
> path is set up by avoiding double reservation of resources. Then, the node
> performing the re-routing can swap on the new path and close the old path.
> This feature is supported with RSVP-TE (using shared explicit filters) and
> CR-LDP (using the action indicator flag).
>           Will this feature will hold good for optical networks as well ,
> where we have TDM , LSC  LSPs. This would require use of
>      SE style in optical networks . Does signaling has to take care of not
> reserving extra resources ( bandwidth / time slot )
>     across the common path of the two LSPs , what will happen at the nodes
> where the two routes diverge and converge .
>     Is it expected that the signal will get multicast to both the routes ,
> and at the node where the route converge the signal
>     is selected from the better of the two paths till the rerouted LSP is
> torn down .
> Regards,
> Manoj

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 03 Dec 2002 16:43:23 -0800
From: "Varma, Eve L (Eve)" <[email-masked]>
To: John Drake <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Tue, 3 Dec 2002 19:42:36 -0500 

Hi all,

I do not believe it should be a WG document.  Clarification
of the applications space, associated requirements, and
distinguishing characteristics is really called for. 

Best regards,
Eve   

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 6:43 PM
To: 'Kireeti Kompella'; [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

It should be a working group document

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 11:39 AM
To: [email-masked]
Subject: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi,

This is a call for consensus to make the above document a CCAMP WG
document.  This call will end Dec 17, 2002.

Please indicate your opinion by replying to this email.

Thanks,
Kireeti.

Delivery-date: Tue, 03 Dec 2002 15:44:25 -0800
From: John Drake <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Tue, 3 Dec 2002 15:42:36 -0800 

It should be a working group document

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 11:39 AM
To: [email-masked]
Subject: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi,

This is a call for consensus to make the above document a CCAMP WG
document.  This call will end Dec 17, 2002.

Please indicate your opinion by replying to this email.

Thanks,
Kireeti.

Envelope-to: [email-masked]
Delivery-date: Tue, 03 Dec 2002 14:26:07 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Oliver Nicolson" <[email-masked]>, <[email-masked]>, "Calient - Jonathan Lang" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-ieft-ccamp-lmp-wdm-01.txt comments
Date: Tue, 3 Dec 2002 17:24:49 -0500

> -- Section 2.4.1 defines a LINK GROUP CHANNEL_STATUS object.  For
> consistency with LMP, a corresponding LINK GROUP CHANNEL_STATUS_REQUEST
> object would be useful.

I think the point is that you report the channel group status of all channels
groups on a TE link, or all channels groups on all TE links.
Do you believe there is a need to (request a) report on a single channel group?

Cheers,
Adrian

Delivery-date: Tue, 03 Dec 2002 14:18:45 -0800
Date: Tue, 03 Dec 2002 23:21:38 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Cc: Ashok Narayanan <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

in order for the ccamp wg to have a clear understanding
a clarification is needed here, the code-point extension
document which had been submitted for ason purposes had 
been discussed during the yokohama meeting, the consensus
was to put it back and then first come with a requirement
document (i refer here to the yokohama meeting discussions)
which is a good idea in order for the ietf ccamp wg to have
a decoder ring concerning the ason application needs... and
then start to think about extensions...

... but as far as i understand it the needs from the itu-t 
were so urgent they couldn't wait about a ccamp community 
discussion on the relevance of these proposed extensions, 
and so went the decision (don't ask me who is behind this?) 
to push it as an individual submission in order to accelerate 
the process of receivng the code-points

... it is sometime good to remember how things happened, but
in any case, the conclusion is that within the "overlay class
of application" we have now clearly one solution when both
side (the edge and the core node) have a lower trust relationship 
(one can refer to it as public uni) and one solution when 
they have a higher trust relationship (one can refer it as 
private uni), each of them have different applicability scope.

ps: i should also mention that the user community needs for 
public switched connections using the oif public uni is 
afaik somehow low and doesn't in any case preclude the 
definition of another solution

thanks,
- dimitri.

"Lin, Zhi-Wei (Zhi)" wrote:
> 
> Hi all,
> 
> Actually the work been done in the ITU-T deals specifically with the overlay, at least the application that operators have identified as been important to them. These documents are planned to be consented at the Jan ITU-T meeting (G.7713.x series). ITU-T has communicated to the IETF regarding this work for some time now (I'm bad at remembering dates but you can probably trace back the emails or the liaison statements).
> 
> In addition, I have submitted two I-Ds, one on requirements and another on protocol extensions needed to support the overlay. It is my understanding that the protocol extensions document has passed through IESG review and sent off to the RFC editors already?
> 
> http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rqts-00.txt
> 
> http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
> 
> You can see the status of the ...rsvpte-04 document from the IESG status tracker
> https://datatracker.ietf.org/public/pidtracker.cgi
> 
> Zhi
> 
> -----Original Message-----
> From: Ashok Narayanan [mailto:[email-masked]]
> Sent: Tuesday, December 03, 2002 3:30 PM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> I would vote that this should be considered in some guise or other in
> the WG. It answers a specific set of questions in a certain way - "how
> can I do GMPLS-style optical signaling without exposing so much peering
> information". AFAIK there aren't CCAMP WG documents that deal with this
> issue in a specific manner.
> 
> -Ashok
> 
> On Tue, 2002-12-03 at 14:39, Kireeti Kompella wrote:
> > Hi,
> >
> > This is a call for consensus to make the above document a CCAMP WG
> > document.  This call will end Dec 17, 2002.
> >
> > Please indicate your opinion by replying to this email.
> >
> > Thanks,
> > Kireeti.
> >
> >

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 03 Dec 2002 14:15:22 -0800
From: Oliver Nicolson <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  Calient - Jonathan Lang <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: draft-ieft-ccamp-lmp-wdm-01.txt comments
Date: Tue, 3 Dec 2002 15:59:24 -0000

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Andre, Jonathan,

A couple of comments about draft-ieft-ccamp-lmp-wdm-01.txt:

-- Link Groups and Shared Risk Link Groups are similar in that a data link
may have arbitrary numbers of either.  However, the subobject data
structures used to transfer this information are different: Link Groups are
stored in a variable number of fixed length subobjects, SRLG identifiers are
stored in a single variable length subobject.  For consistency, could you
consider making both Link Group types use the variable length subobject
approach?

-- Section 2.4.1 defines a LINK GROUP CHANNEL_STATUS object.  For
consistency with LMP, a corresponding LINK GROUP CHANNEL_STATUS_REQUEST
object would be useful.

Regards,

Oliver
___________________________________________________
Oliver Nicolson
Data Connection Ltd.
Tel:	+44 20 8366 1177	Mail:	[email-masked]
Fax:	+44 20 8363 1039	Web:	www.dataconnection.com

Delivery-date: Tue, 03 Dec 2002 13:07:41 -0800
From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
To: Ashok Narayanan <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Tue, 3 Dec 2002 16:06:04 -0500 

Hi all,

Actually the work been done in the ITU-T deals specifically with the overlay, at least the application that operators have identified as been important to them. These documents are planned to be consented at the Jan ITU-T meeting (G.7713.x series). ITU-T has communicated to the IETF regarding this work for some time now (I'm bad at remembering dates but you can probably trace back the emails or the liaison statements).

In addition, I have submitted two I-Ds, one on requirements and another on protocol extensions needed to support the overlay. It is my understanding that the protocol extensions document has passed through IESG review and sent off to the RFC editors already?

http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rqts-00.txt

http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-04.txt

You can see the status of the ...rsvpte-04 document from the IESG status tracker
https://datatracker.ietf.org/public/pidtracker.cgi

Zhi

-----Original Message-----
From: Ashok Narayanan [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 3:30 PM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

I would vote that this should be considered in some guise or other in
the WG. It answers a specific set of questions in a certain way - "how
can I do GMPLS-style optical signaling without exposing so much peering
information". AFAIK there aren't CCAMP WG documents that deal with this
issue in a specific manner.

-Ashok

On Tue, 2002-12-03 at 14:39, Kireeti Kompella wrote:
> Hi,
> 
> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
> 
> Please indicate your opinion by replying to this email.
> 
> Thanks,
> Kireeti.
> 
> 

Envelope-to: [email-masked]
Delivery-date: Tue, 03 Dec 2002 12:54:25 -0800
Message-Id: <[email-masked]>
To: Kireeti Kompella <[email-masked]>
cc: Stephen Trowbridge <[email-masked]>, Yangguang Xu <[email-masked]>, [email-masked], [email-masked]
Subject: Re: GMPLS in overlay mode 
Date: Tue, 03 Dec 2002 15:29:03 -0500
From: George Swallow <[email-masked]>

> > > c) the IETF has every right to "bring up" topics that other forums may
> > >         or may not already have discussed, lengthily or otherwise,
> > >         especially when it concerns protocols that the IETF developed.
> >
> > As I recall the OIF discussion, vendors were split over the proposal,
> > and operators indicated strongly that their needs were better addressed by
> > the ongoing UNI and NNI work.
> 
> That's useful information.  However, it does not mean that we shouldn't
> discuss it in the IETF; nor on the other hand does it mean that we (the
> IETF/CCAMP WG) cannot learn from the OIF experience.

Percisely.  Just because a particular set up users do not find a
that a particular approach does not meet their needs does not mean
that the approach is not useful to some other set.  In this particular
case I have had *no* EFTs for the OIF-UNI (code has been available for
over a year).  I have a number of EFTs using GMPLS signalling without
GMPLS routing which is essentially what the draft is about.  It simply
clarifies some things that have been hacked so that we have a standard
approach.  

> > Certainly it would make sense for IETF to take up a proposal that another
> > standards body had rejected IF they are trying to address a different market
> > or application for which this proposal might be an appropriate solution.
> 
> Let me re-iterate: the OIF is *not* a standards body.
> 
> Furthermore, if I understood the authors correctly, there *are* addressing
> a different application.

The OIF-UNI assumes a very low trust model.  The internals of the
network *must* be hidden.  Addressing must be seperable.  Requests for
a specific path are not allowed.

In a setting where the boundry between an edge-node and a core-node
has a higher trust level, you can permit more things.

> > When I suggested that a requirements document might be the correct first
> > step here during the meeting, one of the authors described this as a stalling
> > tactic. What I had in mind was to use this as a time saving tactic:
> 
> The "overlay" document essentially describes a *mode* of using GMPLS.
> There are no major extensions; there are a few procedural changes.  It
> is basically a clarification document that says that GMPLS (which many
> just assume can only be used in "peer" mode) can in fact be used in
> an overlay context.
> 
> A call for consensus to make this a WG document should indicate whether
> folks think this is useful or not.

I might add that the *useful* means
useful-for-some-segment-of-the-market and not just useful-for-me.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Tue, 03 Dec 2002 12:54:03 -0800
Subject: Re: Message Transmission in GMPLS
From: Ashok Narayanan <[email-masked]>
To: Manoj Agiwal <[email-masked]>
Cc: "'Ccamp (E-mail)" <[email-masked]>, "Gmpls-Ops (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Organization: Cisco Systems
Date: 03 Dec 2002 10:31:29 -0500

On Tue, 2002-12-03 at 03:56, Manoj Agiwal wrote:
> Hi ,
>       When RSVP messages are transmitted , what should be the source and
> destination IP addresses , should these IP addresses
>    be that of control plane or should these IP address be Node ID . Some
> vendors have chosen GRE tunnel to tunnel Signaling 
>    message across the control plane to the next node . The inside IP address
> being that of Nodes while routable address that of
>    control plane ethernet interface .
>       This can result in Interop Issues , IETF should enforce using one of
> the mechanism ,  or should the nodes be flexible enough
>     to expect both . Problem might come where the logic resolves around
> Source IP address from where the Signaling message 

Nodes should be flexible enough to accept both. The use of a stable
address (e.g. Router-ID or some shared GRE address) is better in that it
reduces messaging in the case of control channel failover. But it needs
routing. In any case, the receiving node should accept what it gets.

Source address is probably not as relevant for messages that carry HOP
objects (like a Path) as the reliable messaging peer is also extracted
from there. For messages that don't carry HOP objects the source address
may be important; but RFC2961 defines source address behaviour for ACK &
SREFRESH messages. 

With the exception of reliable messaging (perhaps), there should really
be no reason to have trouble with any source address of a message.

>     arrived .
> Regards ,
> Manoj
> 
> 

Delivery-date: Tue, 03 Dec 2002 12:53:55 -0800
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
From: Ashok Narayanan <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Organization: Cisco Systems
Date: 03 Dec 2002 15:30:08 -0500

I would vote that this should be considered in some guise or other in
the WG. It answers a specific set of questions in a certain way - "how
can I do GMPLS-style optical signaling without exposing so much peering
information". AFAIK there aren't CCAMP WG documents that deal with this
issue in a specific manner.

-Ashok

On Tue, 2002-12-03 at 14:39, Kireeti Kompella wrote:
> Hi,
> 
> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
> 
> Please indicate your opinion by replying to this email.
> 
> Thanks,
> Kireeti.
> 
> 

Delivery-date: Tue, 03 Dec 2002 11:59:38 -0800
Date: Tue, 03 Dec 2002 21:02:29 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

i agree to have this i-d as ccamp wg i-d, it covers
imho the need raised by overlaid control plane inter-
connection between lsr and oxc topologies belonging 
to the same administrative entity and this without
requiring any major extension required to the current 
gmpls signalling proposed standard this while allowing 
a much better integration (at least) from the client 
software side

thanks,
- dimitri.

Kireeti Kompella wrote:
> 
> Hi,
> 
> This is a call for consensus to make the above document a CCAMP WG
> document.  This call will end Dec 17, 2002.
> 
> Please indicate your opinion by replying to this email.
> 
> Thanks,
> Kireeti.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 03 Dec 2002 11:54:34 -0800
From: Jonathan Lang <[email-masked]>
To: 'Kireeti Kompella ' <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
Date: Tue, 3 Dec 2002 11:52:33 -0800 

I think this is a useful document and should be made a CCAMP WG document.

Thanks,
Jonathan

-----Original Message-----
From: Kireeti Kompella
To: [email-masked]
Sent: 12/3/2002 11:39 AM
Subject: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi,

This is a call for consensus to make the above document a CCAMP WG
document.  This call will end Dec 17, 2002.

Please indicate your opinion by replying to this email.

Thanks,
Kireeti.

Delivery-date: Tue, 03 Dec 2002 11:40:20 -0800
Date: Tue, 3 Dec 2002 11:39:02 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: <[email-masked]>
Subject: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

Hi,

This is a call for consensus to make the above document a CCAMP WG
document.  This call will end Dec 17, 2002.

Please indicate your opinion by replying to this email.

Thanks,
Kireeti.

Delivery-date: Tue, 03 Dec 2002 11:40:13 -0800
Date: Tue, 3 Dec 2002 11:38:13 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Stephen Trowbridge <[email-masked]>
cc: Yangguang Xu <[email-masked]>, <[email-masked]>
Subject: GMPLS in overlay mode

Hi Steve,

On Tue, 3 Dec 2002, Stephen Trowbridge wrote:

> > c) the IETF has every right to "bring up" topics that other forums may
> >         or may not already have discussed, lengthily or otherwise,
> >         especially when it concerns protocols that the IETF developed.
>
> As I recall the OIF discussion, vendors were split over the proposal,
> and operators indicated strongly that their needs were better addressed by
> the ongoing UNI and NNI work.

That's useful information.  However, it does not mean that we shouldn't
discuss it in the IETF; nor on the other hand does it mean that we (the
IETF/CCAMP WG) cannot learn from the OIF experience.

> Certainly it would make sense for IETF to take up a proposal that another
> standards body had rejected IF they are trying to address a different market
> or application for which this proposal might be an appropriate solution.

Let me re-iterate: the OIF is *not* a standards body.

Furthermore, if I understood the authors correctly, there *are* addressing
a different application.

> When I suggested that a requirements document might be the correct first
> step here during the meeting, one of the authors described this as a stalling
> tactic. What I had in mind was to use this as a time saving tactic:

The "overlay" document essentially describes a *mode* of using GMPLS.
There are no major extensions; there are a few procedural changes.  It
is basically a clarification document that says that GMPLS (which many
just assume can only be used in "peer" mode) can in fact be used in
an overlay context.

A call for consensus to make this a WG document should indicate whether
folks think this is useful or not.

Kireeti.

Delivery-date: Tue, 03 Dec 2002 07:49:52 -0800
Date: Tue, 03 Dec 2002 08:48:33 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: Yangguang Xu <[email-masked]>, [email-masked]
Subject: Re: IETF 55 - CCAMP Minutes

Kireeti,
> c) the IETF has every right to "bring up" topics that other forums may
>         or may not already have discussed, lengthily or otherwise,
>         especially when it concerns protocols that the IETF developed.

As I recall the OIF discussion, vendors were split over the proposal,
and operators indicated strongly that their needs were better addressed by
the ongoing UNI and NNI work.

Certainly it would make sense for IETF to take up a proposal that another
standards body had rejected IF they are trying to address a different market
or application for which this proposal might be an appropriate solution.

When I suggested that a requirements document might be the correct first
step here during the meeting, one of the authors described this as a stalling
tactic. What I had in mind was to use this as a time saving tactic:

If there is a market or application that is of interest to IETF that was not
of interest to OIF, then it should be no trouble to identify that market and
to write down the REQUIREMENTS for that market that are not met by base GMPLS
or the OIF solutions.

Asking for these requirements to be written down seems to be a good way, not only
to focus the work, but to eliminate the other possibility: if the market is the
SAME one considered by OIF with no new requirements, then perhaps the authors
are just forum shopping, trying to find a place where this proposal gets a more
welcome reception than it did at OIF. If this is the case, lets not waste our time
rehashing the same old arguments (with almost exactly the same participants).
Regards,
Steve

Delivery-date: Tue, 03 Dec 2002 07:29:33 -0800
From: Bala Rajagopalan <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked]
Cc: [email-masked]
Subject: RE: IETF 55 - CCAMP Minutes
Date: Tue, 3 Dec 2002 10:22:28 -0500 

Hello,

The P-UNI IETF draft submission was mentioned
and briefly discussed in the last (November) OIF
meeting.

The OIF position has been that the
ongoing E-NNI work subsumes the P-UNI functionality.
Hence, the P-UNI has not been taken up as a separate
work item.

Regards,

Bala

P.S: Without attributing any motive to Yuanguang's mail,
I agree with Kireeti's point (c). If there are technical
issues here, specifically those that relate to 
the inconsistencies in standards that Mark
alludes to, or the applications of different
models (e.g., P-UNI, UNI, E-NNI), we can discuss them. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 9:24 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: IETF 55 - CCAMP Minutes

In this case, I don't know what happened at the OIF.  Perhaps one of the 
primary OIF players speak up with the information.

Mark Loyd Jones
Sprint
Technology Planning & Integration
913-794-2139

-----Original Message-----
From: xuyg [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 8:11 AM
To: Mark.Jones
Cc: ccamp
Subject: Re: IETF 55 - CCAMP Minutes

Mark,

> I normally just monitor the CCAMP list, but this line of discussion
> concerns me. 

Me too, for these days.

Your points are well taken even I have no idea where they come from. 
Whatever,
would an objective summary of what happened in OIF help us to jump start 
the
discussion here? I don't want to miss valid reasons why OIF drop the 
idea, also
I wouldn't take them for granted.

You seem to know what happened, whould you please share with us so we 
can get
some real things done quickly?

Thanks,

Yangguang

Delivery-date: Tue, 03 Dec 2002 06:26:09 -0800
From: [email-masked]
Date: Tue, 3 Dec 2002 08:23:57 -0600
Subject: RE: IETF 55 - CCAMP Minutes
TO: [email-masked]
CC: [email-masked]

In this case, I don't know what happened at the OIF.  Perhaps one of the 
primary OIF players speak up with the information.

Mark Loyd Jones
Sprint
Technology Planning & Integration
913-794-2139

-----Original Message-----
From: xuyg [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 8:11 AM
To: Mark.Jones
Cc: ccamp
Subject: Re: IETF 55 - CCAMP Minutes

Mark,

> I normally just monitor the CCAMP list, but this line of discussion
> concerns me. 

Me too, for these days.

Your points are well taken even I have no idea where they come from. 
Whatever,
would an objective summary of what happened in OIF help us to jump start 
the
discussion here? I don't want to miss valid reasons why OIF drop the 
idea, also
I wouldn't take them for granted.

You seem to know what happened, whould you please share with us so we 
can get
some real things done quickly?

Thanks,

Yangguang

Delivery-date: Tue, 03 Dec 2002 06:14:52 -0800
Date: Tue, 03 Dec 2002 09:11:00 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies ,  Optical Networking Group, MV
To: [email-masked]
CC: [email-masked]
Subject: Re: IETF 55 - CCAMP Minutes

Mark,

> I normally just monitor the CCAMP list, but this line of discussion
> concerns me. 

Me too, for these days.

Your points are well taken even I have no idea where they come from. Whatever,
would an objective summary of what happened in OIF help us to jump start the
discussion here? I don't want to miss valid reasons why OIF drop the idea, also
I wouldn't take them for granted.

You seem to know what happened, whould you please share with us so we can get
some real things done quickly?

Thanks,

Yangguang

Delivery-date: Tue, 03 Dec 2002 02:20:08 -0800
From: Manoj Agiwal <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>
Cc: "'Ccamp (E-mail)" <[email-masked]>
Subject: RE: Message Transmission in GMPLS
Date: Tue, 3 Dec 2002 04:16:18 -0600 

Hi Kireeti ,

   PHOP / NHOP is not available in Summary Refresh message , In this
particular scenario ,
   the only thing which the user has is the source IP address of the
Srefresh message to identify
   the node from where the Srefresh message is received . 

   Therefore the source IP address plays an important role in identifying
the neighbor from
   where summary refresh messages are received .

   How is the neighbor identified in this particular scenario. 

   Again in Resv IF_IDNHOP message consists of two parts , The TLV part of
the NHOP is supposed 
   to carry the same information which the node has received in the
corresponding Path message 
   and the PHOP and LIH is supposed to carry the control plane IP address
and LIH , because
   of this Resv message is itself not able to identify from which neighbor
it came from , till
   we look into the control plane IP address , and in case if we have the
mapping that this   
   control plane IP address belongs to which neighbor , we can identify the
neighbor .

Manoj

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 2:45 PM
To: Manoj Agiwal
Cc: 'Ccamp (E-mail)
Subject: Re: Message Transmission in GMPLS

Hi Manoj,

On Tue, 3 Dec 2002, Manoj Agiwal wrote:

>       When RSVP messages are transmitted , what should be the source and
> destination IP addresses , should these IP addresses
>    be that of control plane or should these IP address be Node ID.

The main thing is that the destination IP address should ensure that
the rsvp message reaches the intended destination.  Read section 8.1.1
of the lsp hierarchy doc and section 10.2 of the generalized rsvp doc.

>       This can result in Interop Issues , IETF should enforce using one of
> the mechanism ,  or should the nodes be flexible enough
>     to expect both.

Remember that the dest IP address is to ensure that the rsvp message
reaches the correct nexthop (*in the control plane*); the source IP
address is mostly irrelevant.  The PHOP/NHOP MUST be set correctly so
that the reply goes where it's supposed to.

Kireeti.

Delivery-date: Tue, 03 Dec 2002 01:16:24 -0800
Date: Tue, 3 Dec 2002 01:14:53 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Manoj Agiwal <[email-masked]>
cc: "'Ccamp (E-mail)" <[email-masked]>
Subject: Re: Message Transmission in GMPLS

Hi Manoj,

On Tue, 3 Dec 2002, Manoj Agiwal wrote:

>       When RSVP messages are transmitted , what should be the source and
> destination IP addresses , should these IP addresses
>    be that of control plane or should these IP address be Node ID.

The main thing is that the destination IP address should ensure that
the rsvp message reaches the intended destination.  Read section 8.1.1
of the lsp hierarchy doc and section 10.2 of the generalized rsvp doc.

>       This can result in Interop Issues , IETF should enforce using one of
> the mechanism ,  or should the nodes be flexible enough
>     to expect both.

Remember that the dest IP address is to ensure that the rsvp message
reaches the correct nexthop (*in the control plane*); the source IP
address is mostly irrelevant.  The PHOP/NHOP MUST be set correctly so
that the reply goes where it's supposed to.

Kireeti.

Delivery-date: Tue, 03 Dec 2002 00:59:59 -0800
From: Manoj Agiwal <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>
Cc: "Gmpls-Ops (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Message Transmission in GMPLS
Date: Tue, 3 Dec 2002 02:56:44 -0600 

Hi ,
      When RSVP messages are transmitted , what should be the source and
destination IP addresses , should these IP addresses
   be that of control plane or should these IP address be Node ID . Some
vendors have chosen GRE tunnel to tunnel Signaling 
   message across the control plane to the next node . The inside IP address
being that of Nodes while routable address that of
   control plane ethernet interface .
      This can result in Interop Issues , IETF should enforce using one of
the mechanism ,  or should the nodes be flexible enough
    to expect both . Problem might come where the logic resolves around
Source IP address from where the Signaling message 
    arrived .
Regards ,
Manoj

Delivery-date: Tue, 03 Dec 2002 00:52:04 -0800
From: Manoj Agiwal <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "Gmpls-Ops (E-mail)" <[email-masked]>
Subject: make-before-break in Gmpls
Date: Tue, 3 Dec 2002 02:48:25 -0600 

Hi ,
         The gmpls architecture documents says 
"GMPLS does not add anything new. Elegant re-routing is possible with the
concept of "make-before-break" whereby an old path is still used while a new
path is set up by avoiding double reservation of resources. Then, the node
performing the re-routing can swap on the new path and close the old path.
This feature is supported with RSVP-TE (using shared explicit filters) and
CR-LDP (using the action indicator flag). 
          Will this feature will hold good for optical networks as well ,
where we have TDM , LSC  LSPs. This would require use of 
     SE style in optical networks . Does signaling has to take care of not
reserving extra resources ( bandwidth / time slot )
    across the common path of the two LSPs , what will happen at the nodes
where the two routes diverge and converge .
    Is it expected that the signal will get multicast to both the routes ,
and at the node where the route converge the signal
    is selected from the better of the two paths till the rerouted LSP is
torn down .
Regards,
Manoj

Delivery-date: Mon, 02 Dec 2002 18:44:42 -0800
Date: Mon, 02 Dec 2002 21:39:07 -0500
To: "Adrian Farrel" <[email-masked]>
From: "Bradford, Richard" <[email-masked]>
Subject: Re: Comments on draft-rbradfor-ccamp-lmp-lol-00.txt
Cc: "Bradford, Richard" <[email-masked]>, <[email-masked]>

--=====================_50206833==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:21 PM 11/18/2002 -0500, Adrian Farrel wrote:
>Richard,
>This looks like a useful draft.
>
>I have a few comments and nits in line (look for >>).
>Please let me know if you'd like me to clarify any of my points or provide 
>text.
>
>Cheers,
>Adrian
>
>
>
>CCAMP Working Group                    Richard Bradford
>Internet Draft                    Dimitri Papadimitriou
>Expires: April 2003                          Dan Tappan
>                                            October 2002
>
>
>     LMP Extensions for Link discovery Using Loss of Light
> >> I think you'll get asked to expand the acronym in the title
 >>>Changed.

>
>               draft-rbradfor-ccamp-lmp-lol-00.txt
>
>[SNIP]
>Abstract
>
>    This document proposes an enhanced mechanism for LMP link
>
> >> I think you'll get asked to expand the acronym in the abstract
 >>>Changed.

>
>    verification that is independent of the data encoding
>
> >> need to say that this is for use in verifying optical links

 >>>I've added: "It can be used for any point-to-point link, including both 
Optical Links and SONET/SDH Links."

>
>    type.  The general proposal is to use the transmission of
>    light by the sender and recognition of the presence or
>    absence of light by the receiver to identify port
>    mapping.  The proposal includes minor extensions to the
>    existing messages to implement this extension to the link
>    verification procedure.
>
>Bradford et al                                               [Page 1]
>
>Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002
>
>1. Introduction
>
> >> I'd suggest that section 1 is too long and the bulk of the
>    text should be moved to a new "Overview" section between
>    the current sections 2 and 3

 >>>Changed. the Introduction now focuses on current limitations and the 
second section focuses on the overview.

>
>    Optical networks are being developed to include optical
>    cross-connects, routers and DWDMs that are configured
>    with control channels and data links.  LMP was created to
>    provide, among other features, link discovery between
>
> >> and link verification

 >>>changed.

>
>    these devices.  Currently, LMP requires the ability to
>    terminate data in these links in order to perform this
>    link discovery. Many of these devices, such as DWDMs, do
>    not currently have these capabilities and the addition of
>    these capabilities could be expensive or even technically
>    unfeasible.  This memo defines extensions to the LMP Link
>    Verification Procedure to allow neighbors to determine
>    their interface mappings using the presence and absence
>    (a.k.a loss of light or LoL)loss of light on those
>
> >> /re-write
>    Verification Procedure to allow neighbors to determine
>    their interface mappings using the presence or absence
>    of received light on those
> >> /re-write off

 >>>changed.

>
>    interfaces, a capability that is simpler, does not
>    require optical/electrical conversion cheaper, and is
>
> >> add ", is"

 >>>removed cheaper

>    require optical/electrical conversion, is cheaper, and is
>
>    within the existing functional requirements of many of
>    these devices.  A common name for the signal indicating
>    presence and absence of light is Loss-of-Light, (LOL), so
>    that name is used throughout this document.  The proposed
>    mechanism provides a more scalable solution than the
>    existing link verification mechanisms.
>
>
>1.1.  Current Limitations
>
>    [LMP] Link Verification requires optical devices to
>    provide link termination of each port and provides a wide
>    variety of transport mechanisms for possible termination.
>    This requirement leads to several challengeshe LMP link
>
> >> typo

 >>>changed

>    This requirement leads to several challenges. The LMP link
>
>    termination requirement prevents adoption on devices
>    which do not already electrically terminate links and
>    presents difficult engineering challenges for
>    incorporation in many other devices. Another limitation
>    is the scalability of the current link verification
>    procedure. These are discussed in detail below.
>
>1.1.1 Link Termination.  Issues
>    This section raises issues of possible additional
>    complexity, performance impacts, reliability impacts
>    and potentially prohibitive cost issues which could
>    limit the applicability of LMP for certain devices. Many
>    of the issues are implementation specific and not all
>    issues affect all types of optical devices.
>
>    1)  First, X-transparent devices have no reason, other than
>
> >> do you need to explain x-transparent and X-aspect?
 >>>I think the altered DWDM example at the end of the paragraph should 
make it clear enough. I'll pass it by a few more eyes.

>
>      supporting LMP link verification, to terminate the X-aspect
>      of the data link. Support for such termination can greatly
>      increase the complexity, and cost, and power consumption of
>      some devices and the additional components could affect such
>      important aspects of a device as MTBF. A DWDM that is
>
>Bradford et al                                               [Page 2]
>
>Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002
>      electrically transparent, for example, would need to add the
>
> >> do you mean "optically" transparent?

 >>>Yes. I've reworded the entire paragraph. Let me know if this seems clearer.

 >>>First, X-transparent devices have no reason, other than supporting LMP 
link verification, to terminate the X-aspect of the data link. Support for 
such termination can greatly increase the complexity, and cost, and power 
consumption of some devices and the additional components could affect such 
important aspects of a device as MTBF.. For example, an optically 
transparent DWDM does not need the ability to decode the light signal, 
except to support LMP Link Verification.

>
>      ability to switch every port between its operational pass-
>      through mode and its termination mode.
>
>
>    2)  Second, the addition of link termination can increase
>      the signal loss through certain devices even when the link
>      is not terminated, due to the additional switching
>      requirement. An example of this is a DWDM, which normally
>      does not need to switch the incoming light to an internal
>      termination module. While this is very implementation
>      dependent, the ability to losslessly add this cabability
>
> >> typo
>    "capability"
 >>>changed.

>      could present a roadblock to support for link verification.
>    3) Third, an electrically transparent OXC would need to add
>      one or more termination modules and could and would lose the
>      switching capacity required for those termination modules
>      (e.g. a 16x16 port fabric mightwould need to have at least
>
> >> "mightwould" :-)
 >>>changed

>
>      one of those ports connected to the link termination module,
>      preventing its connection to an external interface).
>    4) Fourth, is the problem of supporting the "right" set of
>      termination capabilities. For example, a electrically
>
> >> "an" electrically

 >>>changed

>    but, again, do you mean optically transparent?
>    Actually, I think you mean that the data plane is transparent
>    to the control plane. That is, the control plane cannot
>    extract packets or overhead information from the data plane.
>    This is a superset of optically transparent.
>
>      transparent switch may be able to support connections
>      carrying SONET or Gigabit Ethernet. In addition, that switch
>      may be able to switch wavelengths, which are carrying
>      anything from OC483 through OC768 and beyond. It would be
>      costly and difficult to provide termination capabilities for
>      even a small subset of these transport mechanisms.
>
>1.1.2 Link Verification Scalability
>
>    1)  In addition to the above, the many of theexisting
>
> >> typo "the existing"
changed.

>
>      mechanisms for LMP LV calls for the link verification
>      initiator to send in-band messages from each port. If the
>      link-verification target switch is incapable of
>      simultaneously terminating all its ports, it must then cycle
>      through termination of its ports to find the interface
>      connected to each source. This does not scale well for large
>      switches. If a group of 512 port OXCs is connected together,
>      then each target switch will need to cycle through an
>      average of 256 ports before finding its mate. This requires
>      an average of 131,072 (256x512) combinations to try, a large
>      number, especially if the combinations must be tested
>      serially(i.e. one termination at a time).
>
> >> FWIW the average is less than this for point-to-point connectivity
>    in stable systems because you don't need to scan ports that are
>    already known to be connected
 >>>Yes, adding a single port is simpler. the worst case is the startup 
with a lot of ports, which should only happen once, (unless the node and 
its neighbors get hit by the same event, like a power hit).

>
>    The solution proposed in this document limits the
>    excessive link termination costs, both in terms of added
>    hardware and the potentially increased reduce optical
>    lossbudgets to support that hardware. It also provides a
>    mechanism that scales much better for large numbers of
>    interconnects.
>
>
>
>
>Bradford et al                                               [Page 3]
>
>Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002
>1.2.  Proposed Solution Overview and Benefits.
>
>    The solution must address the issue of link termination
>    compatibility as well as the scalability limitation of
>    the existing LMP link verification procedure.
>
>    The ability to switch light on for the transmit side of
>    an interface and the ability to detect the presence of
>    light on the receive side of an interface is already
>    present in many optical devices, regardless of the
>    optical encoding mechanisms used. A link verification
>    mechanism based on LOL puts a minimal requirement on an
>    interface and provides universal compatibility.
>
>    For scalability, the enhanced procedure allows testing of
>    all ports in parallel and without terminating the line.
>    This avoids the limitation of testing ports serially,
>    which requires terminating one source port at a time,
>    then the destination will need to terminate a line, wait
>    some interval which is greater than the inter-message
>    arrival time, and move to the next. This requires the
>    source to send on the order of n-squared messages. The
>    method described in this document reduces this to a
>    number on the order of ln(n) for large numbers of
>    interconnects. Note that the scalability problem is only
>    an issue for devices which cannot terminate multiple
>    ports simultaneously.
>
>    Here is an overview of the procedure. For brevity, the
>    initiator of link verification will be referred to as LV-
>    src and the destination node accepting the link
>    verification request will be referred to as LV-dst.
>
> >> You need to clarify "pattern". I think you should say
>    something like...
>    The LV-Src may set some of its ports to transmit light
>    and others to not transmit light. Given a well-known
>    ordering of ports, the ports may be represented as a
>    bit sequence with a zero bit representing no light and
>    a one representing a port transmitting light. The
>    resultant bit sequence represents the 'pattern' of
>    enabled interfaces.
> >> /end suggested text

 >>Added suggested text.

>
>    LV-Src sets the interfaces it is verifying to emit light
>    in a particular pattern and then sends that pattern to LV-
>    Dst over the control channel. LV-Dst looks for light on
>    all its available interfaces and reports back over the
>    control channel. Initially every one of LV-dst's
>    interfaces can be "possibly-connected" to all of LV-src's
>    interfaces, since no possibilities have yet been
>    eliminated. However, each time LV-Src changes the
>    combination light on its interfaces, some of LV-dst's
>    interfaces will not see the corresponding change, and
>    connectivity between those two ports will be eliminated
>    as a possibility.
>
>
> >> I would suggest moving all example material out to a new section
>    at the end of the draft. I don't think that you need to give the
>    comparison with port-by-port scalability again - you have already
>    covered this.
>
>    Using this mechanism, the port connectivity can be
>    established through a series of interface/light-emission
>    patterns. For an eight port example, the pattern 0xF0,
>    0x0F, 0xCC, and 0xAA, would be more than sufficient to
>    provide the mapping of eight ports to eight ports. These
>    4 messages will actually each require an acknowledgement,
>    totaling 8 messages. To verify eight-port connectivity
>
>Bradford et al                                               [Page 4]
>
>Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002
>
>
>    using the existing LMP Link verification procedure
>    requires the source to terminate each source port in
>    turn. For each source port, the destination must
>    terminate each potential destination until a test message
>    is received. On average, half the ports will need to be
>    tested before discovering the right one. This requires a
>    minimum of 8*4= 32 test messages, on average, and
>    probably many more, perhaps 64, since port termination
>    and waiting for a packet will typically require waiting
>    for more than a single packet transmission interval. For
>    eight ports, the number of test messages is reduced from
>    between 32 and 63 messages, to just 8. For 64 ports, this
>    method reduces the number of test messages from
>    (64*63)/2=2016 (or twice that), to 6+2=8 (or 16 including
>    acknowledgments..
>
>    Once LV-Src has completed its entire pattern, LV-Dst will
>    report which interfaces, if any, map to its local
>    interfaces.
>
>    The pattern of lights emissions must cause each interface
>    to change and must uniquely differentiate between all the
>    ports. The algorithm used in the above sequences is as
>    follows. For N ports. Pattern 1 = first N/2 ports on,
>    second N/2 ports off. Pattern 2 = First N/2 ports off
>    second N/2 on. Patterns 3-maximium, (where M= pattern #)
>    = Alternate on and off in groups of N/(2**(M-1)).
>
> >> You should stress that this is an example, but that the
>    behavior is entirely an implementation matter for the
>    LV-Src.

 >>Added

>
>
>2. Terminology
>
>    This document uses terminology from the MPLS architecture
>    document [MPLSArch] and the LMP Draft [LMP].
>
> >> if you move the bulk of the text in section 1 downwards, you
>    can add terminology for 'pattern' and for 'transparent'.

 >>> Moved Terminology section up.

>3. Link Verification Extensions.
>
>    The following extensions are needed to support this
>    method of Link Verification:
>
>      .  A new flag is defined to identify LOL in the Verify
>         Transport Mechanism field of the BEGIN_VERIFY object and the
>         Verify Transport Response field of the BEGIN_VERIFY_ACK
>         object. This field is defined across all LSP encoding types
>         and does not interfere with specification of the existing
>         transport mechanisms.
>      .  Extension of the Test Message to include the LOL Status.
>      .  Extension of the TestStatusSuccess message, which is
>         similar to the modified Test Message.
>
> >> "similar"? :-)
 >>>fixed

>    see my note in message format below
>    there is an asymmetry between the messages
>
>      .  Addition of a LOL_TEST_STATUS Object.
> >> Assume this is the object included in the previous two bullets?

 >>>move it before the reference.

>
>
>Bradford et al                                               [Page 5]
>
>Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002
>
>
>3.1.  LOL Link Verification Walkthrough
>
>    Here is a walkthrough of the procedure.  LV-src sends a
>    BeginVerify message indicating LOL as the transport
>    mechanism.  LV-dst responds with a BeginVerifyAck
>    message, selecting LOL as the transport mechanism.
>
>    LV-src sets its interfaces to emit light in pattern 1.
>    For example, where 8 ports are being verified, and where
>    a one represents "transmit light", the pattern of light
>    emissions could be represented by the eight bit number
>    0xF0.  LV-src then creates a test message, which includes
>    the light emission status and local-interface-id for
>    every interface being tested.
>
> >> So I have a question...
>    Can I do link verification without impacting existing traffic?

 >>>No the link must be idle. turning off the light source will disrupt 
traffic.

>    I don't suppose I can verify in-use links in this way, but what
>    if I want to do verification on those links that are not
>    currently active? Can I do this?
>    I think the text below for "stuck" ports handles this but we
>    should expose it explicitly.
>    Note discovery and verification are different in this question.
>
>
>    LV-dst, on receipt of a test message, records the status
>    of light for every port and if at least one port has
>    light it replies with a TestStatusSuccess message,
>    containing the the local Interface_ID for each port that
>
> >> typo "the the"

 >>>Fixed.

>
>    has light. Otherwise, it sends a TestStatusFailure
>    message indicating that no light was seen on any ports.
>
>    On receipt of a TestStatusSuccess message, the LV-src
>    sends a TestStatusAck message and changes the light
>    emission to the next pattern and continues the process.
>
>    When the LV-src has completed its test patterns and
>    received the TestStatusSucccess messages for those Test
>    Messages, it will send an EndVerify message to end the
>    process.
>
>    Using this mechanism, the port connectivity can be
>    established through a series of interface light-emission
>    patterns.
>
> >> Should we handle the case where the LV-Src believes it has collected
>    sufficient information to resolve the links but the LV-Dst believes
>    it needs more information?
>    This would probably reflect an implementation issue at Src or Dst,
>    but could be addressed in the EndVerify response allowing the Dst
>    to refuse EndVerify and to request a specific pattern.

 >>>Interesting. If we added a feature like that I think we'd have to add 
another mechanism, since an EndVerify is the LV-src has to end the process. 
It might want to use that under several circumstances. for example, if it 
was in the periodic re-verification of an idle port and a request to set up 
an LSP came in.

>
>
> >> Move example out?
>
>    For an eight port example, the pattern 0xF0,
>    0x0F, 0xCC, and 0xAA, would be sufficient to provide the
>    mapping of eight ports to eight ports using only four
>    patterns. For a switch with 64 ports the bitmap would
>    have to be enlarged to eight bytes, and could use the
>    patterns 0xFFFFFFFF00000000, 0x00000000FFFFFFFF,
>    0xFFFF0000FFFF0000, 0xFF00FF00FF00FF00,
>    0xF0F0F0F0F0F0F0F0, 0xCCCCCCCCCCCCCCCC,
>    0xAAAAAAAAAAAAAAAA - performing the mapping using only
>    seven patterns.
>
>[BIG SNIP]
>
>3.2 LOL support for multiple neighbors
>    A weakness in the LOL mechanism occurs when (a) multiple
>neighbors simultaneously use the mechanism to verify their
>ports and (b) multiple links between a pair of nodes are
>verified simultaneously.  This section describes the first
>weakness and an enhanced algorithm that can overcome this
>
> >> and the second weakness is described where?

 >>>Actually, both weaknesses are actually variations of the same problem. 
I'll fix the text.

>
>weakness.  Note that any given node may only be performing
>LOL link verification with one neighbor at a time.  The
>
>[SNIP]
>
>4. LMP LOL Message Definitions
>
>
>4.1.  Test Message (Msg Type = 10)
>
>    The LOL Test message is transmitted over the control
>channel and not the data link and is used to verify its
>physical connectivity. This is transmitted in the standard
>LMP UDP/IP packet with payload format as follows:
>
>      <Test Message> ::= <Common Header> <VERIFY_ID>
>           <MESSAGE_ID> <LOL_TEST_STATUS>
>
>
>
>
>4.2.  TestStatusSuccess Message (Msg Type = 11)
>
>        The TestStatusSuccess message is transmitted over the
>    control channel and is used to transmit the mapping
>    between the local Interface Id and the Interface Id that
>    was received in the Test messageTest Message once the
>    exchange of Test and TestStatusSuccess messages is
>    complete.
>
>    <TestStatusSuccess Message> ::= <Common Header>
>                     <LOCAL_LINK_ID> <MESSAGE_ID> <VERIFY_ID>
>                     <LOCAL_INTERFACE_ID1>
>                     <LOCAL_INTERFACE_ID2>. . .
>                     <LOCAL_INTERFACE_IDn>
>
> >> Why two different mechanisms?
>    If you put LOL_TEST_STATUS in this message you have symmetry
>    and don't have to worry about ordering of the LOCAL_INTERFACE_ID
>    objects.
 >>>Actually, that would be simpler. I don't recall exactly why they were 
different, perhaps to make the message shorter. Simplicity seems a better 
choice.

>
>    The above transmission order SHOULD be followed, but the
>    location of the VERIFY_ID in the message is unimportant.
>
> >> Surely the order of LOCAL_INTERFACE_IDs is very important

 >>>Yes, but I like the idea of using LO_TEST_STATUS.

>
>
>
>
>
>Bradford et al                                               [Page 10]
>
>Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002
>
>
>5. LMP Object Definitions
>
>
>
>5.1.  BEGIN_VERIFY Class modifications.
>
>    Verify Transport Mechanism:  16 bits
>
>       This defines the transport mechanism for the Test
>       Messages. The scope of this bit mask is restricted to
>       each link encoding type. The local node will set the
>       bits corresponding to the various mechanisms it can
>       support for transmitting LMP test
>
>       0x100 LOL: Loss Of Light and out-of-band Test
>       messages
>
> >> Why this choice of value? LMP-07 only defines 0x8000
 >>>It was based on an earlier draft. 0x4000?

>
>               Capable of supporting link verification
>               through the Presence and Loss of Light. In
>               this case, the Test messageTest Messages are
>               exchanged over the same IP control channel as
>               standard LMP control messages. The Test
>               messageTest Messages identify the Data
>               Link(s) where Light is being emitted.
>               TestStatusSuccess messages identify the Data
>               Link(s) where Light has been detected.
>
> >> The following paragraph is duplicate information.
>    Just refer to section 4.1
>
>The format of the Test message is as follows:
>
>              <Test Message> ::= <Common Header>
>                    <MESSAGE_ID> <VERIFY_ID>
>                    <LOL_TEST_STATUS>
>
>
>5.2.  LOL_TEST_STATUS Class
>
>    Class = 21
>
>
>Bradford et al                                               [Page 11]
>
>Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002
>
>
>
>  o    IPv4, C-Type = 1
>
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                       Interface Id (4 bytes)                  |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                         LOL Status                            |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                              :                                |
>  //                             :                               //
>  |                              :                                |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                       Interface Id (4 bytes)                  |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                         LOL Status                            |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>[SNIP]
>
>  LOL_Status: 32 bits
>
>   This indicates the status condition of a data channel.  The
>   following values are defined.  All other values are reserved.
>
>   1   Signal Okay (OK): Interface Sent or Detected Light
>   2   Signal Inconsistent: The Interface did sometimes
>         detected light, sometimes did not
>This Object contains one or more Interface Ids followed by an
>    LOL_Status field.
>
>
> >> Given that so few values are defined and that they are used as
>    counting integers not flags can we reduce the size of the field
>    and have some reserved bits?
>    I suggest that we don't need more than one byte for LOL_status.
>    Two if you are *really* pessimistic.

 >>>Good Idea.8 bits is plenty.

>
>Bradford et al                                               [Page 13]
>
>Internet Draft    draft-rbradfor-ccamp-lmp-lol-00.txt  September 2002
>
>
>
>6. Acknowledgments
>
>
>
>7. References
>
> >> Need to split into Normative and Informational references

 >>>done

>
>[SNIP]

--=====================_50206833==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 02:21 PM 11/18/2002 -0500, Adrian Farrel wrote:<br>
</font><blockquote type=cite cite><font face="courier" size=2>Richard,</font><font size=3><br>
</font><font face="courier" size=2>This looks like a useful
draft.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>I have a few comments and nits in line
(look for &gt;&gt;).</font><font size=3><br>
</font><font face="courier" size=2>Please let me know if you'd like me to
clarify any of my points or provide text.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>Cheers,</font><font size=3><br>
</font><font face="courier" size=2>Adrian</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</font><font face="courier" size=2>CCAMP Working
Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Richard Bradford<br>
Internet
Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Dimitri Papadimitriou<br>
Expires: April
2003&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Dan Tappan<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
October 2002</font><font size=3><br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp; LMP Extensions for
Link discovery Using Loss of Light<br>
&gt;&gt; I think you'll get asked to expand the acronym in the
title</font></blockquote>&gt;&gt;&gt;Changed.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
draft-rbradfor-ccamp-lmp-lol-00.txt</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>[SNIP]<br>
Abstract</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; This document proposes an
enhanced mechanism for LMP link</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; I think you'll get asked to
expand the acronym in the
abstract</font></blockquote>&gt;&gt;&gt;Changed.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; verification that is
independent of the data encoding</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; need to say that this is for
use in verifying optical links</font></blockquote><br>
&gt;&gt;&gt;I've added:
&quot;<font face="Times New Roman, Times" size=2>It can be used for any
point-to-point link, including both Optical Links and SONET/SDH
Links.&quot;<br>
<br>
</font><blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; type.&nbsp; The general
proposal is to use the transmission of<br>
&nbsp;&nbsp; light by the sender and recognition of the presence or<br>
&nbsp;&nbsp; absence of light by the receiver to identify port<br>
&nbsp;&nbsp; mapping.&nbsp; The proposal includes minor extensions to
the<br>
&nbsp;&nbsp; existing messages to implement this extension to the
link<br>
&nbsp;&nbsp; verification procedure.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>Bradford et
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 1]<br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September
2002</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>1.
Introduction</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; I'd suggest that section 1 is
too long and the bulk of the<br>
&nbsp;&nbsp; text should be moved to a new &quot;Overview&quot; section
between<br>
&nbsp;&nbsp; the current sections 2 and 3</font></blockquote><br>
&gt;&gt;&gt;Changed. the Introduction now focuses on current limitations
and the second section focuses on the overview.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; Optical networks are
being developed to include optical<br>
&nbsp;&nbsp; cross-connects, routers and DWDMs that are configured<br>
&nbsp;&nbsp; with control channels and data links.&nbsp; LMP was created
to<br>
&nbsp;&nbsp; provide, among other features, link discovery
between</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; and link
verification</font></blockquote><br>
&gt;&gt;&gt;changed.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; these devices.&nbsp;
Currently, LMP requires the ability to<br>
&nbsp;&nbsp; terminate data in these links in order to perform this<br>
&nbsp;&nbsp; link discovery. Many of these devices, such as DWDMs,
do<br>
&nbsp;&nbsp; not currently have these capabilities and the addition
of<br>
&nbsp;&nbsp; these capabilities could be expensive or even
technically<br>
&nbsp;&nbsp; unfeasible.&nbsp; This memo defines extensions to the LMP
Link<br>
&nbsp;&nbsp; Verification Procedure to allow neighbors to determine<br>
&nbsp;&nbsp; their interface mappings using the presence and 
absence<br>
&nbsp;&nbsp; (a.k.a loss of light or LoL)loss of light on
those</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; /re-write<br>
&nbsp;&nbsp; Verification Procedure to allow neighbors to determine<br>
&nbsp;&nbsp; their interface mappings using the presence or absence<br>
&nbsp;&nbsp; of received light on those<br>
&gt;&gt; /re-write off</font></blockquote><br>
&gt;&gt;&gt;changed.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; interfaces, a capability
that is simpler, does not<br>
&nbsp;&nbsp; require optical/electrical conversion cheaper, and
is</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; add &quot;,
is&quot;</font></blockquote><br>
&gt;&gt;&gt;removed cheaper<br>
<br>
<blockquote type=cite cite><font face="courier" size=2>&nbsp;&nbsp;
require optical/electrical conversion, is cheaper, and
is</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; within the existing
functional requirements of many of<br>
&nbsp;&nbsp; these devices.&nbsp; A common name for the signal
indicating<br>
&nbsp;&nbsp; presence and absence of light is Loss-of-Light, (LOL),
so<br>
&nbsp;&nbsp; that name is used throughout this document.&nbsp; The
proposed<br>
&nbsp;&nbsp; mechanism provides a more scalable solution than the<br>
&nbsp;&nbsp; existing link verification
mechanisms.</font><font size=3><br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>1.1.&nbsp; Current
Limitations</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; [LMP] Link Verification
requires optical devices to<br>
&nbsp;&nbsp; provide link termination of each port and provides a
wide<br>
&nbsp;&nbsp; variety of transport mechanisms for possible
termination.<br>
&nbsp;&nbsp; This requirement leads to several challengeshe LMP
link</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; 
typo</font></blockquote><br>
&gt;&gt;&gt;changed<br>
<br>
<blockquote type=cite cite><font face="courier" size=2>&nbsp;&nbsp; This
requirement leads to several challenges. The LMP
link</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; termination requirement
prevents adoption on devices<br>
&nbsp;&nbsp; which do not already electrically terminate links and<br>
&nbsp;&nbsp; presents difficult engineering challenges for<br>
&nbsp;&nbsp; incorporation in many other devices. Another 
limitation<br>
&nbsp;&nbsp; is the scalability of the current link verification<br>
&nbsp;&nbsp; procedure. These are discussed in detail
below.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>1.1.1 Link Termination.&nbsp;
Issues<br>
&nbsp;&nbsp; This section raises issues of possible additional<br>
&nbsp;&nbsp; complexity, performance impacts, reliability impacts<br>
&nbsp;&nbsp; and potentially prohibitive cost issues which could<br>
&nbsp;&nbsp; limit the applicability of LMP for certain devices.
Many<br>
&nbsp;&nbsp; of the issues are implementation specific and not all<br>
&nbsp;&nbsp; issues affect all types of optical
devices.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; 1)&nbsp; First,
X-transparent devices have no reason, other 
than</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; do you need to explain
x-transparent and X-aspect?</font></blockquote>&gt;&gt;&gt;I think the
altered DWDM example at the end of the paragraph should make it clear
enough. I'll pass it by a few more eyes.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp; supporting
LMP link verification, to terminate the X-aspect<br>
&nbsp;&nbsp;&nbsp;&nbsp; of the data link. Support for such termination
can greatly<br>
&nbsp;&nbsp;&nbsp;&nbsp; increase the complexity, and cost, and power
consumption of<br>
&nbsp;&nbsp;&nbsp;&nbsp; some devices and the additional components could
affect such<br>
&nbsp;&nbsp;&nbsp;&nbsp; important aspects of a device as MTBF. A DWDM
that is</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>Bradford et
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 2]<br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September 2002<br>
&nbsp;&nbsp;&nbsp;&nbsp; electrically transparent, for example, would
need to add the</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; do you mean
&quot;optically&quot; transparent?</font></blockquote><br>
&gt;&gt;&gt;Yes. I've reworded the entire paragraph. Let me know if this
seems clearer.<br>
<br>
<font face="Times New Roman, Times" size=3>&gt;&gt;&gt;First,
X-transparent devices have no reason, other than supporting LMP link
verification, to terminate the X-aspect of the data link. Support for
such termination can greatly increase the complexity, and cost, and power
consumption of some devices and the additional components could affect
such important aspects of a device as MTBF.. For example, an optically
transparent DWDM does not need the ability to decode the light signal,
except to support LMP Link Verification.<br>
<br>
</font><blockquote type=cite cite>&nbsp;<br>
<font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp; ability to switch
every port between its operational pass-<br>
&nbsp;&nbsp;&nbsp;&nbsp; through mode and its termination
mode.</font><font size=3><br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>&nbsp;&nbsp; 2)&nbsp; Second, the
addition of link termination can increase<br>
&nbsp;&nbsp;&nbsp;&nbsp; the signal loss through certain devices even
when the link<br>
&nbsp;&nbsp;&nbsp;&nbsp; is not terminated, due to the additional
switching<br>
&nbsp;&nbsp;&nbsp;&nbsp; requirement. An example of this is a DWDM, which
normally<br>
&nbsp;&nbsp;&nbsp;&nbsp; does not need to switch the incoming light to an
internal<br>
&nbsp;&nbsp;&nbsp;&nbsp; termination module. While this is very
implementation<br>
&nbsp;&nbsp;&nbsp;&nbsp; dependent, the ability to losslessly add this
cabability</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; 
typo</font><font size=3><br>
</font><font face="courier" size=2>&nbsp;&nbsp;
&quot;capability&quot;</font></blockquote>&gt;&gt;&gt;changed.<br>
<br>
<br>
<blockquote type=cite cite><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp;
could present a roadblock to support for link verification.<br>
&nbsp;&nbsp; 3) Third, an electrically transparent OXC would need to
add<br>
&nbsp;&nbsp;&nbsp;&nbsp; one or more termination modules and could and
would lose the<br>
&nbsp;&nbsp;&nbsp;&nbsp; switching capacity required for those
termination modules<br>
&nbsp;&nbsp;&nbsp;&nbsp; (e.g. a 16x16 port fabric mightwould need to
have at least</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; &quot;mightwould&quot;
:-)</font></blockquote>&gt;&gt;&gt;changed<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp; one of those
ports connected to the link termination module,<br>
&nbsp;&nbsp;&nbsp;&nbsp; preventing its connection to an external
interface).<br>
&nbsp;&nbsp; 4) Fourth, is the problem of supporting the
&quot;right&quot; set of<br>
&nbsp;&nbsp;&nbsp;&nbsp; termination capabilities. For example, a
electrically</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; &quot;an&quot;
electrically</font></blockquote><br>
&gt;&gt;&gt;changed<br>
<br>
<blockquote type=cite cite><font face="courier" size=2>&nbsp;&nbsp; but,
again, do you mean optically transparent?</font><font size=3><br>
</font><font face="courier" size=2>&nbsp;&nbsp; Actually, I think you
mean that the data plane is transparent</font><font size=3><br>
</font><font face="courier" size=2>&nbsp;&nbsp; to the control plane.
That is, the control plane cannot </font><font size=3><br>
</font><font face="courier" size=2>&nbsp;&nbsp; extract packets or
overhead information from the data plane.</font><font size=3><br>
</font><font face="courier" size=2>&nbsp;&nbsp; This is a superset of
optically transparent.&nbsp;&nbsp; </font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp; transparent
switch may be able to support connections<br>
&nbsp;&nbsp;&nbsp;&nbsp; carrying SONET or Gigabit Ethernet. In addition,
that switch<br>
&nbsp;&nbsp;&nbsp;&nbsp; may be able to switch wavelengths, which are
carrying<br>
&nbsp;&nbsp;&nbsp;&nbsp; anything from OC483 through OC768 and beyond. It
would be<br>
&nbsp;&nbsp;&nbsp;&nbsp; costly and difficult to provide termination
capabilities for<br>
&nbsp;&nbsp;&nbsp;&nbsp; even a small subset of these transport
mechanisms.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>1.1.2 Link Verification
Scalability</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; 1)&nbsp; In addition to
the above, the many of theexisting</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; typo &quot;the
existing&quot;</font></blockquote>changed.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp; mechanisms
for LMP LV calls for the link verification<br>
&nbsp;&nbsp;&nbsp;&nbsp; initiator to send in-band messages from each
port. If the<br>
&nbsp;&nbsp;&nbsp;&nbsp; link-verification target switch is incapable
of<br>
&nbsp;&nbsp;&nbsp;&nbsp; simultaneously terminating all its ports, it
must then cycle<br>
&nbsp;&nbsp;&nbsp;&nbsp; through termination of its ports to find the
interface<br>
&nbsp;&nbsp;&nbsp;&nbsp; connected to each source. This does not scale
well for large<br>
&nbsp;&nbsp;&nbsp;&nbsp; switches. If a group of 512 port OXCs is
connected together,<br>
&nbsp;&nbsp;&nbsp;&nbsp; then each target switch will need to cycle
through an<br>
&nbsp;&nbsp;&nbsp;&nbsp; average of 256 ports before finding its mate.
This requires<br>
&nbsp;&nbsp;&nbsp;&nbsp; an average of 131,072 (256x512) combinations to
try, a large<br>
&nbsp;&nbsp;&nbsp;&nbsp; number, especially if the combinations must be
tested<br>
&nbsp;&nbsp;&nbsp;&nbsp; serially(i.e. one termination at a
time).</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; FWIW the average is less than
this for point-to-point connectivity<br>
&nbsp;&nbsp; in stable systems because you don't need to scan ports that
are<br>
&nbsp;&nbsp; already known to be
connected</font></blockquote>&gt;&gt;&gt;Yes, adding a single port is
simpler. the worst case is the startup with a lot of ports, which should
only happen once, (unless the node and its neighbors get hit by the same
event, like a power hit).<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; The solution proposed in
this document limits the<br>
&nbsp;&nbsp; excessive link termination costs, both in terms of
added<br>
&nbsp;&nbsp; hardware and the potentially increased reduce optical<br>
&nbsp;&nbsp; lossbudgets to support that hardware. It also provides
a<br>
&nbsp;&nbsp; mechanism that scales much better for large numbers of<br>
&nbsp;&nbsp; interconnects.</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>Bradford et
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 3]<br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September 2002<br>
1.2.&nbsp; Proposed Solution Overview and
Benefits.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; The solution must address
the issue of link termination<br>
&nbsp;&nbsp; compatibility as well as the scalability limitation of<br>
&nbsp;&nbsp; the existing LMP link verification
procedure.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; The ability to switch
light on for the transmit side of<br>
&nbsp;&nbsp; an interface and the ability to detect the presence of<br>
&nbsp;&nbsp; light on the receive side of an interface is already<br>
&nbsp;&nbsp; present in many optical devices, regardless of the<br>
&nbsp;&nbsp; optical encoding mechanisms used. A link verification<br>
&nbsp;&nbsp; mechanism based on LOL puts a minimal requirement on 
an<br>
&nbsp;&nbsp; interface and provides universal
compatibility.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; For scalability, the
enhanced procedure allows testing of<br>
&nbsp;&nbsp; all ports in parallel and without terminating the 
line.<br>
&nbsp;&nbsp; This avoids the limitation of testing ports serially,<br>
&nbsp;&nbsp; which requires terminating one source port at a time,<br>
&nbsp;&nbsp; then the destination will need to terminate a line,
wait<br>
&nbsp;&nbsp; some interval which is greater than the inter-message<br>
&nbsp;&nbsp; arrival time, and move to the next. This requires the<br>
&nbsp;&nbsp; source to send on the order of n-squared messages. The<br>
&nbsp;&nbsp; method described in this document reduces this to a<br>
&nbsp;&nbsp; number on the order of ln(n) for large numbers of<br>
&nbsp;&nbsp; interconnects. Note that the scalability problem is
only<br>
&nbsp;&nbsp; an issue for devices which cannot terminate multiple<br>
&nbsp;&nbsp; ports simultaneously.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; Here is an overview of
the procedure. For brevity, the<br>
&nbsp;&nbsp; initiator of link verification will be referred to as
LV-<br>
&nbsp;&nbsp; src and the destination node accepting the link<br>
&nbsp;&nbsp; verification request will be referred to as
LV-dst.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; You need to clarify
&quot;pattern&quot;. I think you should say<br>
&nbsp;&nbsp; something like...<br>
&nbsp;&nbsp; The LV-Src may set some of its ports to transmit light<br>
&nbsp;&nbsp; and others to not transmit light. Given a well-known<br>
&nbsp;&nbsp; ordering of ports, the ports may be represented as a<br>
&nbsp;&nbsp; bit sequence with a zero bit representing no light and<br>
&nbsp;&nbsp; a one representing a port transmitting light. The<br>
&nbsp;&nbsp; resultant bit sequence represents the 'pattern' of<br>
&nbsp;&nbsp; enabled interfaces.<br>
&gt;&gt; /end suggested text</font></blockquote><br>
&gt;&gt;Added suggested text.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; LV-Src sets the
interfaces it is verifying to emit light<br>
&nbsp;&nbsp; in a particular pattern and then sends that pattern to
LV-<br>
&nbsp;&nbsp; Dst over the control channel. LV-Dst looks for light 
on<br>
&nbsp;&nbsp; all its available interfaces and reports back over the<br>
&nbsp;&nbsp; control channel. Initially every one of LV-dst's<br>
&nbsp;&nbsp; interfaces can be &quot;possibly-connected&quot; to all of
LV-src's<br>
&nbsp;&nbsp; interfaces, since no possibilities have yet been<br>
&nbsp;&nbsp; eliminated. However, each time LV-Src changes the<br>
&nbsp;&nbsp; combination light on its interfaces, some of LV-dst's<br>
&nbsp;&nbsp; interfaces will not see the corresponding change, and<br>
&nbsp;&nbsp; connectivity between those two ports will be 
eliminated<br>
&nbsp;&nbsp; as a possibility.</font><font size=3><br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>&gt;&gt; I would suggest moving all
example material out to a new section<br>
&nbsp;&nbsp; at the end of the draft. I don't think that you need to give
the<br>
&nbsp;&nbsp; comparison with port-by-port scalability again - you have
already<br>
&nbsp;&nbsp; covered this.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; Using this mechanism, the
port connectivity can be<br>
&nbsp;&nbsp; established through a series of
interface/light-emission<br>
&nbsp;&nbsp; patterns. For an eight port example, the pattern 0xF0,<br>
&nbsp;&nbsp; 0x0F, 0xCC, and 0xAA, would be more than sufficient to<br>
&nbsp;&nbsp; provide the mapping of eight ports to eight ports.
These<br>
&nbsp;&nbsp; 4 messages will actually each require an
acknowledgement,<br>
&nbsp;&nbsp; totaling 8 messages. To verify eight-port
connectivity</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>Bradford et
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 4]<br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September
2002</font><font size=3><br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>&nbsp;&nbsp; using the existing LMP
Link verification procedure<br>
&nbsp;&nbsp; requires the source to terminate each source port in<br>
&nbsp;&nbsp; turn. For each source port, the destination must<br>
&nbsp;&nbsp; terminate each potential destination until a test
message<br>
&nbsp;&nbsp; is received. On average, half the ports will need to 
be<br>
&nbsp;&nbsp; tested before discovering the right one. This requires
a<br>
&nbsp;&nbsp; minimum of 8*4= 32 test messages, on average, and<br>
&nbsp;&nbsp; probably many more, perhaps 64, since port termination<br>
&nbsp;&nbsp; and waiting for a packet will typically require 
waiting<br>
&nbsp;&nbsp; for more than a single packet transmission interval.
For<br>
&nbsp;&nbsp; eight ports, the number of test messages is reduced
from<br>
&nbsp;&nbsp; between 32 and 63 messages, to just 8. For 64 ports,
this<br>
&nbsp;&nbsp; method reduces the number of test messages from<br>
&nbsp;&nbsp; (64*63)/2=2016 (or twice that), to 6+2=8 (or 16
including<br>
&nbsp;&nbsp; acknowledgments..</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; Once LV-Src has completed
its entire pattern, LV-Dst will<br>
&nbsp;&nbsp; report which interfaces, if any, map to its local<br>
&nbsp;&nbsp; interfaces.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; The pattern of lights
emissions must cause each interface<br>
&nbsp;&nbsp; to change and must uniquely differentiate between all
the<br>
&nbsp;&nbsp; ports. The algorithm used in the above sequences is as<br>
&nbsp;&nbsp; follows. For N ports. Pattern 1 = first N/2 ports on,<br>
&nbsp;&nbsp; second N/2 ports off. Pattern 2 = First N/2 ports off<br>
&nbsp;&nbsp; second N/2 on. Patterns 3-maximium, (where M= pattern
#)<br>
&nbsp;&nbsp; = Alternate on and off in groups of
N/(2**(M-1)).</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; You should stress that this
is an example, but that the<br>
&nbsp;&nbsp; behavior is entirely an implementation matter for the<br>
&nbsp;&nbsp; LV-Src.</font></blockquote><br>
&gt;&gt;Added <br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
<br>
</font><font face="courier" size=2>2.
Terminology</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; This document uses
terminology from the MPLS architecture<br>
&nbsp;&nbsp; document [MPLSArch] and the LMP Draft
[LMP].</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; if you move the bulk of the
text in section 1 downwards, you </font><font size=3><br>
</font><font face="courier" size=2>&nbsp;&nbsp; can add terminology for
'pattern' and for 'transparent'.</font></blockquote><br>
&gt;&gt;&gt; Moved Terminology section up.<br>
<br>
<br>
<blockquote type=cite cite><font face="courier" size=2>3. Link
Verification Extensions.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; The following extensions
are needed to support this<br>
&nbsp;&nbsp; method of Link Verification:</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp; .&nbsp; A new
flag is defined to identify LOL in the Verify<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Transport Mechanism field of
the BEGIN_VERIFY object and the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Verify Transport Response
field of the BEGIN_VERIFY_ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; object. This field is defined
across all LSP encoding types<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and does not interfere with
specification of the existing<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transport mechanisms.<br>
&nbsp;&nbsp;&nbsp;&nbsp; .&nbsp; Extension of the Test Message to include
the LOL Status.<br>
&nbsp;&nbsp;&nbsp;&nbsp; .&nbsp; Extension of the TestStatusSuccess
message, which is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; similar to the modified Test
Message.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; &quot;similar&quot;?
:-)</font></blockquote>&gt;&gt;&gt;fixed<br>
<br>
<blockquote type=cite cite><font face="courier" size=2>&nbsp;&nbsp; see
my note in message format below</font><font size=3><br>
</font><font face="courier" size=2>&nbsp;&nbsp; there is an asymmetry
between the messages</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp; .&nbsp;
Addition of a LOL_TEST_STATUS Object.<br>
&gt;&gt; Assume this is the object included in the previous two
bullets?</font></blockquote><br>
&gt;&gt;&gt;move it before the reference.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
<br>
</font><font face="courier" size=2>Bradford et
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 5]<br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September
2002</font><font size=3><br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>3.1.&nbsp; LOL Link Verification
Walkthrough</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; Here is a walkthrough of
the procedure.&nbsp; LV-src sends a<br>
&nbsp;&nbsp; BeginVerify message indicating LOL as the transport<br>
&nbsp;&nbsp; mechanism.&nbsp; LV-dst responds with a BeginVerifyAck<br>
&nbsp;&nbsp; message, selecting LOL as the transport
mechanism.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; LV-src sets its
interfaces to emit light in pattern 1.<br>
&nbsp;&nbsp; For example, where 8 ports are being verified, and
where<br>
&nbsp;&nbsp; a one represents &quot;transmit light&quot;, the pattern of
light<br>
&nbsp;&nbsp; emissions could be represented by the eight bit number<br>
&nbsp;&nbsp; 0xF0.&nbsp; LV-src then creates a test message, which
includes<br>
&nbsp;&nbsp; the light emission status and local-interface-id for<br>
&nbsp;&nbsp; every interface being tested.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; So I have a question...<br>
&nbsp;&nbsp; Can I do link verification without impacting existing
traffic?</font></blockquote><br>
&gt;&gt;&gt;No the link must be idle. turning off the light source will
disrupt traffic.<br>
<br>
<blockquote type=cite cite><font face="courier" size=2>&nbsp;&nbsp; I
don't suppose I can verify in-use links in this way, but what<br>
&nbsp;&nbsp; if I want to do verification on those links that are
not<br>
&nbsp;&nbsp; currently active? Can I do this?<br>
&nbsp;&nbsp; I think the text below for &quot;stuck&quot; ports handles
this but we<br>
&nbsp;&nbsp; should expose it explicitly.<br>
&nbsp;&nbsp; Note discovery and verification are different in this
question.</font><font size=3><br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>&nbsp;&nbsp; LV-dst, on receipt of a
test message, records the status<br>
&nbsp;&nbsp; of light for every port and if at least one port has<br>
&nbsp;&nbsp; light it replies with a TestStatusSuccess message,<br>
&nbsp;&nbsp; containing the the local Interface_ID for each port
that</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; typo &quot;the
the&quot;</font></blockquote><br>
&gt;&gt;&gt;Fixed.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; has light. Otherwise, it
sends a TestStatusFailure<br>
&nbsp;&nbsp; message indicating that no light was seen on any
ports.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; On receipt of a
TestStatusSuccess message, the LV-src<br>
&nbsp;&nbsp; sends a TestStatusAck message and changes the light<br>
&nbsp;&nbsp; emission to the next pattern and continues the
process.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; When the LV-src has
completed its test patterns and<br>
&nbsp;&nbsp; received the TestStatusSucccess messages for those 
Test<br>
&nbsp;&nbsp; Messages, it will send an EndVerify message to end the<br>
&nbsp;&nbsp; process.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; Using this mechanism, the
port connectivity can be<br>
&nbsp;&nbsp; established through a series of interface
light-emission<br>
&nbsp;&nbsp; patterns.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; Should we handle the case
where the LV-Src believes it has collected<br>
&nbsp;&nbsp; sufficient information to resolve the links but the LV-Dst
believes<br>
&nbsp;&nbsp; it needs more information?<br>
&nbsp;&nbsp; This would probably reflect an implementation issue at Src
or Dst,<br>
&nbsp;&nbsp; but could be addressed in the EndVerify response allowing
the Dst<br>
&nbsp;&nbsp; to refuse EndVerify and to request a specific
pattern.</font></blockquote><br>
&gt;&gt;&gt;Interesting. If we added a feature like that I think we'd
have to add another mechanism, since an EndVerify is the LV-src has to
end the process. It might want to use that under several circumstances.
for example, if it was in the periodic re-verification of an idle port
and a request to set up an LSP came in.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
<br>
</font><font face="courier" size=2>&gt;&gt; Move example
out?</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; For an eight port
example, the pattern 0xF0,<br>
&nbsp;&nbsp; 0x0F, 0xCC, and 0xAA, would be sufficient to provide
the<br>
&nbsp;&nbsp; mapping of eight ports to eight ports using only four<br>
&nbsp;&nbsp; patterns. For a switch with 64 ports the bitmap would<br>
&nbsp;&nbsp; have to be enlarged to eight bytes, and could use the<br>
&nbsp;&nbsp; patterns 0xFFFFFFFF00000000, 0x00000000FFFFFFFF,<br>
&nbsp;&nbsp; 0xFFFF0000FFFF0000, 0xFF00FF00FF00FF00,<br>
&nbsp;&nbsp; 0xF0F0F0F0F0F0F0F0, 0xCCCCCCCCCCCCCCCC,<br>
&nbsp;&nbsp; 0xAAAAAAAAAAAAAAAA - performing the mapping using only<br>
&nbsp;&nbsp; seven patterns.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>[BIG SNIP]</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>3.2 LOL support for multiple
neighbors<br>
&nbsp;&nbsp; A weakness in the LOL mechanism occurs when (a)
multiple<br>
neighbors simultaneously use the mechanism to verify their<br>
ports and (b) multiple links between a pair of nodes are<br>
verified simultaneously.&nbsp; This section describes the first<br>
weakness and an enhanced algorithm that can overcome
this</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; and the second weakness is
described where?</font></blockquote><br>
&gt;&gt;&gt;Actually, both weaknesses are actually variations of the same
problem. I'll fix the text.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>weakness.&nbsp; Note that any given
node may only be performing<br>
LOL link verification with one neighbor at a time.&nbsp;
The</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>[SNIP]</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>4. LMP LOL Message
Definitions</font><font size=3><br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>4.1.&nbsp; Test Message (Msg Type =
10)</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; The LOL Test message is
transmitted over the control<br>
channel and not the data link and is used to verify its<br>
physical connectivity. This is transmitted in the standard<br>
LMP UDP/IP packet with payload format as
follows:</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp; &lt;Test
Message&gt; ::= &lt;Common Header&gt; &lt;VERIFY_ID&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;MESSAGE_ID&gt;
&lt;LOL_TEST_STATUS&gt;</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>4.2.&nbsp; TestStatusSuccess Message
(Msg Type = 11)</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
The TestStatusSuccess message is transmitted over the<br>
&nbsp;&nbsp; control channel and is used to transmit the mapping<br>
&nbsp;&nbsp; between the local Interface Id and the Interface Id
that<br>
&nbsp;&nbsp; was received in the Test messageTest Message once the<br>
&nbsp;&nbsp; exchange of Test and TestStatusSuccess messages is<br>
&nbsp;&nbsp; complete.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; &lt;TestStatusSuccess
Message&gt; ::= &lt;Common Header&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;LOCAL_LINK_ID&gt; &lt;MESSAGE_ID&gt; &lt;VERIFY_ID&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;LOCAL_INTERFACE_ID1&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;LOCAL_INTERFACE_ID2&gt;. . .<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;LOCAL_INTERFACE_IDn&gt;</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; Why two different
mechanisms?<br>
&nbsp;&nbsp; If you put LOL_TEST_STATUS in this message you have
symmetry<br>
&nbsp;&nbsp; and don't have to worry about ordering of the
LOCAL_INTERFACE_ID<br>
&nbsp;&nbsp; objects.</font></blockquote>&gt;&gt;&gt;Actually, that would
be simpler. I don't recall exactly why they were different, perhaps to
make the message shorter. Simplicity seems a better choice.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; The above transmission
order SHOULD be followed, but the<br>
&nbsp;&nbsp; location of the VERIFY_ID in the message is
unimportant.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; Surely the order of
LOCAL_INTERFACE_IDs is very important</font></blockquote><br>
&gt;&gt;&gt;Yes, but I like the idea of using LO_TEST_STATUS.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</font><font face="courier" size=2>Bradford et
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 10]<br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September
2002</font><font size=3><br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>5. LMP Object
Definitions</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</font><font face="courier" size=2>5.1.&nbsp; BEGIN_VERIFY Class
modifications.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; Verify Transport
Mechanism:&nbsp; 16 bits</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This
defines the transport mechanism for the Test<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Messages. The scope of this bit mask is
restricted to<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; each link encoding type. The local node
will set the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bits corresponding to the various
mechanisms it can<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support for transmitting LMP
test</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x100
LOL: Loss Of Light and out-of-band Test<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; messages</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; Why this choice of value?
LMP-07 only defines 0x8000</font></blockquote>&gt;&gt;&gt;It was based on
an earlier draft. 0x4000?<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Capable of supporting link verification<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
through the Presence and Loss of Light. In<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
this case, the Test messageTest Messages are<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
exchanged over the same IP control channel as<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
standard LMP control messages. The Test<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
messageTest Messages identify the Data<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Link(s) where Light is being emitted.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TestStatusSuccess messages identify the Data<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Link(s) where Light has been detected.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; The following paragraph is
duplicate information.<br>
&nbsp;&nbsp; Just refer to section 4.1</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>The format of the Test message is as
follows:</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;Test Message&gt; ::= &lt;Common Header&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;MESSAGE_ID&gt; &lt;VERIFY_ID&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;LOL_TEST_STATUS&gt;</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
</font><font face="courier" size=2>5.2.&nbsp; LOL_TEST_STATUS
Class</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;&nbsp; Class =
21</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
</font><font face="courier" size=2>Bradford et
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 11]<br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September
2002</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;o&nbsp;&nbsp;&nbsp; IPv4, C-Type
= 1</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1<br>
&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Interface Id (4
bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
LOL
Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
//<br>
&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Interface Id (4
bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
LOL
Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
</font><font face="courier" size=2>[SNIP]</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp;LOL_Status: 32
bits</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp; This indicates the status
condition of a data channel.&nbsp; The<br>
&nbsp; following values are defined.&nbsp; All other values are
reserved.</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&nbsp; 1&nbsp;&nbsp; Signal Okay (OK):
Interface Sent or Detected Light<br>
&nbsp; 2&nbsp;&nbsp; Signal Inconsistent: The Interface did
sometimes<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; detected light, sometimes did
not<br>
This Object contains one or more Interface Ids followed by an<br>
&nbsp;&nbsp; LOL_Status field.</font><font size=3><br>
&nbsp;<br>
<br>
</font><font face="courier" size=2>&gt;&gt; Given that so few values are
defined and that they are used as<br>
&nbsp;&nbsp; counting integers not flags can we reduce the size of the
field<br>
&nbsp;&nbsp; and have some reserved bits?<br>
&nbsp;&nbsp; I suggest that we don't need more than one byte for
LOL_status.<br>
&nbsp;&nbsp; Two if you are *really*
pessimistic.</font></blockquote><br>
&gt;&gt;&gt;Good Idea.8 bits is plenty.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>Bradford et
al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[Page 13]<br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;
draft-rbradfor-ccamp-lmp-lol-00.txt&nbsp; September
2002</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</font><font face="courier" size=2>6.
Acknowledgments</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</font><font face="courier" size=2>7. 
References</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>&gt;&gt; Need to split into Normative
and Informational references</font></blockquote><br>
&gt;&gt;&gt;done<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;<br>
</font><font face="courier" size=2>[SNIP]</font><font size=3></font></blockquote><br>

<font face="Courier, Courier"></font></html>

--=====================_50206833==_.ALT--

Delivery-date: Mon, 02 Dec 2002 16:45:13 -0800
content-class: urn:content-classes:message
Subject: RE: J0/J1 encoding issues
Date: Mon, 2 Dec 2002 19:43:26 -0500
From: "Brungard, Deborah A, ALASO" <[email-masked]>
To: "Stephen Trowbridge" <[email-masked]>, "Jonathan Lang" <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>, "Peter Wery" <[email-masked]>
Cc: "Razdan, Rajender" <[email-masked]>, "John Drake" <[email-masked]>, <[email-masked]>, <[email-masked]>

There are some of us who are members of OIF/ITU/T1X1/IETF, though the =
majority are not. For those of us attending multiple meetings, we do =
forget;-)

We had identified an open dir for IETF and ITU-T to share work of common =
interest? Considering discovery and routing are our (ITU) current work =
items, I recommend we make available these drafts in the public =
directory. The earlier we can share work between IETF and ITU, we will =
all benefit.

And T1X1.5 welcomes participation and contributions, both USA and =
international. Our exploder is open and our contribution dir is open.

Deborah

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Tuesday, November 26, 2002 1:21 PM
To: Jonathan Lang; Lam, Hing-Kam (Kam); Peter Wery
Cc: Razdan, Rajender; John Drake; [email-masked]; Brungard,
Deborah A, ALASO; [email-masked]
Subject: Re: J0/J1 encoding issues

Jonathan,
I do not write these communication statements: they come from the
individual Rapporteur groups doing the work (in this case, Q.14/15).
These are usually generated at meetings (in the case of this one,
and the one to IETF ccamp regarding G.7713.2 and G.7713.3, these
were generated at the meeting of Q.14/15 in Ottawa in October).

I did think it more expeditious to refer people to the OIF
communication which already contained the desired document rather
than going through the mechanics of generating a new one. After
all, I think the majority of key participants are OIF memebers
as well.

I will copy Kam Lam, the Rapporteur of Q.14/15 on this email so
that he is aware of your interest. The next meeting of Q.14/15 is
not until our full Study Group 15 meeting from 20-31 January in
Geneva, but it is also possible for communication statements to
be formulated and approved via email correspondence when necessary
between meetings.
Regards,
Steve

Jonathan Lang wrote:
>=20
> Stephen,
>   May I suggest that you add routing & discovery to the
> communication/liaison statement to the IETF. Since most of the OIF =
work is
> based on protocols developed in the IETF, it seems odd that IETF
> participants need to go through the OIF to see these documents.
>=20
> Thanks,
> Jonathan
>=20
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Tuesday, November 26, 2002 9:30 AM
> > To: Razdan, Rajender
> > Cc: Jonathan Lang; John Drake; [email-masked]; =
'Brungard,
> > Deborah A, ALASO '; [email-masked]
> > Subject: Re: J0/J1 encoding issues
> >
> >
> > All,
> > There are some rules about distributing ITU-T documents
> > outside of ITU-T.
> > Generally, the only way to distribute draft text to non-ITU-T
> > members is by
> > sending them via communication/liaison statements to
> > organizations outside
> > of ITU-T.
> >
> > G.7714.1 has not been officially communicated to IETF ccamp,
> > but it has
> > been communicated to OIF in which many of you participate. To obtain =
a
> > copy of the document from the communication statement to OIF, start =
by
> > pointing your browser to:
> > ftp://sg15opticalt:[email-masked]/tsg15opticaltransport
> > /COMMUNICATIONS/index.html
> >
> > From there, choose the link for Optical Internetworking Forum (OIF).
> > Acknowledge the ITU-T copyright.
> > Choose the communication statement dated 11 October 2002 entitled:
> > "Signaling, Routing, and Discovery work in Q.14/15".
> >
> > There are links in this communication for the download of
> > several documents,
> > the last of which is the latest draft of G.7714.1.
> > Regards,
> > Steve Trowbridge
> > Vice-Chairman, ITU-T Study Group 15
> >
> > "Razdan, Rajender" wrote:
> > >
> > > [ post by non-subscriber.  with the massive amount of spam,
> > it is easy to
> > >   miss and therefore delete mis-posts.  so fix subscription
> > addresses! ]
> > >
> > > Jonathan,
> > >
> > >     I welcome the idea of making the draft of G.7714.1 more freely
> > > available. I don't know, however, if there are any ITU rules about
> > > distributing draft documents. One possibility, which I have often
> > > seen used in the past, is to send the latest version as a
> > contribution
> > > to a T1X1.5 meeting. These contributions are freely available to =
the
> > > public. Noting that we do have an upcoming T1X1.5 meeting, I'll go
> > > ahead and do that.
> > >
> > > Cheers,
> > > Rajender Razdan
> > >
> > > -----Original Message-----
> > > From: Jonathan Lang [mailto:[email-masked]]
> > > Sent: Monday, November 25, 2002 10:28 PM
> > > To: Razdan, Rajender; John Drake; [email-masked]
> > > Cc: 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: RE: J0/J1 encoding issues
> > >
> > > Rajender,
> > >   May I suggest that the authors of the G.7714.1 draft make
> > it available to
> > > the wider community. As it is still a draft with most of
> > the discussion
> > > amongst authors and not on a public mailing list, most
> > people have not had a
> > > chance to look at the latest version which is significantly
> > different from
> > > the one discussed at the Experts meeting in Ottawa.
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > > -----Original Message-----
> > > > From: Razdan, Rajender [mailto:[email-masked]]
> > > > Sent: Monday, November 25, 2002 8:55 AM
> > > > To: John Drake; [email-masked]
> > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > Subject: RE: J0/J1 encoding issues
> > > >
> > > >
> > > > John,
> > > >
> > > >     I don't subscribe to the ccamp mailing list, and so
> > > > haven't had a chance
> > > > to comment on the LMP drafts till now. The discussion on
> > > > J0/J1 issues was
> > > > forwarded to me by Jonathan Sadler. As the editor of Draft
> > > > G.7714.1, I was
> > > > quite distressed to read about your understanding that none
> > > > of the work aimed
> > > > at G.7714.1 is compatible with the T.50 requirement. I don't
> > > > know how you got
> > > > that absolutely wrong impression. In fact, compatibility with
> > > > the T.50
> > > > requirement, as dictated by ITU Rec. G.707, has been the most
> > > > important
> > > > consideration for us in our defining J0/J1/J2 discovery
> > > > mechanisms. The current
> > > > draft of G.7714.1 clearly states this. I FULLY agree with
> > > > Jonathan Sadler that
> > > > the LMP work should also be consistent with this requirement.
> > > >
> > > > Regards,
> > > > Rajender Razdan
> > > >
> > > > -----Original Message-----
> > > > From: John Drake [mailto:[email-masked]]
> > > > Sent: Monday, November 25, 2002 11:24 AM
> > > > To: [email-masked]
> > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > Subject: RE: J0/J1 encoding issues
> > > >
> > > >
> > > > Jonathan,
> > > >
> > > > The various Test transport mechanisms that are currently
> > defined in
> > > > draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to
> > > > input from
> > > > various carriers and organizations such as the OIF.  The
> > fact that the
> > > > individual carriers have different requirements for the
> > > > contents of the
> > > > various SDH/SONET overheads is also consistent with my
> > > > reading of Deborah's
> > > > recent e-mail on this topic.
> > > >
> > > > Since one of the transport mechanisms, the J0/J1/J2 trace
> > correlation,
> > > > allows the transport of T.50 characters, I think we're done wrt
> > > > draft-ietf-ccamp-lmp-test-sonet-sdh.
> > > >
> > > > Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding
> > > > that none of the
> > > > work aimed at G.7714.1 is compatible with the T.50 requirement.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > Sent: Thursday, November 21, 2002 8:23 PM
> > > > To: John Drake
> > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > Subject: Re: J0/J1 encoding issues
> > > >
> > > >
> > > > John -
> > > >
> > > > I think you forgot what my original message said.  It stated:
> > > >
> > > > > > As mentioned at the CCAMP meeting, the SDH trace
> > bytes (J0/J1/J2)
> > > > > > have restrictions not only on the length of a trace
> > message and on
> > > > > > the bits usable in a octet, but also on whether the
> > payload in the
> > > > > > message uses printable ASCII characters.
> > > > > >
> > > > > > The requirements for J0/J1/J2 (found in G.707) state the =
trace
> > > > > > message payload must utilize the printable characters
> > defined in
> > > > > > T.50.  Two current LMP drafts
> > > > (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are =
not
> > > > > > consistant with this requirement.
> > > >
> > > > I fail to see what is incorrect with the above.
> > > >
> > > > While draft-ietf-ccamp-lmp-test-sonet-sdh does describe
> > methods for
> > > > J0/J1/J2 that fall within the requirements of G.707, it
> > also includes
> > > > methods that don't.  This situation SHOULD be resolved to
> > provide the
> > > > greatest amount of interoperability while reducing the
> > number of trace
> > > > methods that need to be implemented.
> > > >
> > > > I'm glad to see we agree on the fact that
> > > > draft-lang-ccamp-lmp-bootstrap
> > > > only provides methods that fall outside the requirements of
> > > > G.707.  This
> > > > situation MUST be resolved.
> > > >
> > > > Jonathan Sadler
> > > >
> > > > John Drake wrote:
> > > > >
> > > > > Wouldn't it be more precise to say that it is an issue with
> > > > > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue =
with
> > > > > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > > Sent: Thursday, November 21, 2002 12:49 PM
> > > > > To: John Drake
> > > > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > > > Subject: Re: J0/J1 encoding issues
> > > > >
> > > > > John -
> > > > >
> > > > > draft-lang-ccamp-lmp-bootstrap does not support Trace
> > Correlation.
> > > > > Therefore, it is an issue.
> > > > >
> > > > > Jonathan Sadler
> > > > >
> > > > > John Drake wrote:
> > > > > >
> > > > > > Is it the case that if one chooses to use J0/J1/J2 Trace
> > > > Correlation,
> > > > then
> > > > > > Jonathan Sadler's issue is a non-issue?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > John
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jonathan Lang
> > > > > > Sent: Thursday, November 21, 2002 8:56 AM
> > > > > > To: 'Brungard, Deborah A, ALASO ';
> > [email-masked] ';
> > > > > > 'ccamp '
> > > > > > Subject: FW: J0/J1 encoding issues
> > > > > >
> > > > > > Deborah,
> > > > > >   Thanks for the note. The option that Jonathan mentioned
> > > > is one of a
> > > > > couple
> > > > > > options we define for Jx. We defined other options to
> > > > > > interwork with existing equipment without requiring
> > any changes to
> > > > > > existing encodings (this would support both C1 and T.50
> > > > requirements).
> > > > > > These mechanisms are defined in Section 3.1 as J0/J1/J2 =
Trace
> > > > > > Correlation. We welcome additional comments from you
> > and others at
> > > > > > T1X1.5/ITU.
> > > > > >
> > > > > > Thanks,
> > > > > > Jonathan
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brungard, Deborah A, ALASO
> > > > > > To: [email-masked]; ccamp
> > > > > > Sent: 11/21/2002 5:22 AM
> > > > > > Subject: RE: J0/J1 encoding issues
> > > > > >
> > > > > > As Jonathan says, the current G.707 is using T.50. And
> > > > there's more.
> > > > > > Example, for J0, one currently needs to support:
> > > > > > - previously defined C1 (repeating one-byte)
> > > > > > - T.50 (with format of G.707)
> > > > > > - no J0 (for equipment not supporting).
> > > > > >
> > > > > > So already we have defined multiple applications for this
> > > > byte. Not to
> > > > > > say, there will be not any new ones. Even ITU knows,
> > it never is
> > > > > > final;-)
> > > > > >
> > > > > > For supporting LMP's use, we need to understand the
> > > > scenarios of use
> > > > > > (sounds familiar to T1X1.5 participants?) e.g. =
intra-operator,
> > > > > > inter-operator, applied for equipment installation
> > verification or
> > > > > > service connection verification, etc. And hardware
> > implications.
> > > > > >
> > > > > > Actually, G.831 defines multiple uses depending if inter
> > > > or intra -
> > > > > > including for intra-operator, support of routing/path
> > > > set-up (and G.831
> > > > > > was done years ago).
> > > > > >
> > > > > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5,
> > > > contribute the
> > > > > > proposal for the meeting and we can start the discussion.
> > > > The next ITU-T
> > > > > > meeting is in January. If the LMP editors need help
> > on our T1X1.5
> > > > > > process, just ask.
> > > > > >
> > > > > > Deborah
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jonathan Sadler [mailto:[email-masked]]
> > > > > > Sent: Monday, November 18, 2002 7:59 PM
> > > > > > To: ccamp
> > > > > > Subject: J0/J1 encoding issues
> > > > > >
> > > > > > All -
> > > > > >
> > > > > > As mentioned at the CCAMP meeting, the SDH trace
> > bytes (J0/J1/J2)
> > > > > > have restrictions not only on the length of a trace
> > message and on
> > > > > > the bits usable in a octet, but also on whether the
> > payload in the
> > > > > > message uses printable ASCII characters.
> > > > > >
> > > > > > The requirements for J0/J1/J2 (found in G.707) state the =
trace
> > > > > > message payload must utilize the printable characters
> > defined in
> > > > > > T.50.  Two current LMP drafts
> > > > (draft-ietf-ccamp-lmp-test-sonet-sdh &
> > > > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are =
not
> > > > > > consistant with this requirement.
> > > > > >
> > > > > > This message is being sent to document this issue.
> > It is not a
> > > > > > statement that no other issues exist -- I expect that the
> > > > appropriate
> > > > > > experts in the ITU will review the rest of these two
> > drafts and
> > > > > > provide appropriate comment.
> > > > > >
> > > > > > Jonathan Sadler
> > > >
> > > > (I disclaim the disclaimer that follows this message.)
> > > > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > The information contained in this message may be privileged
> > > > and confidential and protected from disclosure.  If the
> > > > reader of this message is not the intended recipient, or an
> > > > employee or agent responsible for delivering this message to
> > > > the intended recipient, you are hereby notified that any
> > > > reproduction, dissemination or distribution of this
> > > > communication is strictly prohibited. If you have received
> > > > this communication in error, please notify us immediately by
> > > > replying to the message and deleting it from your computer.
> > > >
> > > > Thank you.
> > > > Tellabs
> > > > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > >
> >

Delivery-date: Mon, 02 Dec 2002 15:47:57 -0800
From: [email-masked]
Date: Mon, 2 Dec 2002 17:47:13 -0600
Subject: RE: IETF 55 - CCAMP Minutes
TO: [email-masked]
CC: [email-masked]

I normally just monitor the CCAMP list, but this line of discussion 
concerns me.  Perhaps it wasn't intended by Yangguang Xu, but these 
types of comments have come up several times recently.  They are not 
helping us reach a clear industry standard for the optical control 
plane.

I wanted to add two things to what Kireeti had to say on this topic.

1) The OIF discussion does not represent all those interested in the 
work.  Sprint is not currently an OIF member, but we are interested in 
the results.  An open standards body has a much better chance of 
representing a broader industry view.

2) One of the most critical factors in any standardization effort is 
consistency with existing standards where possible.  I hear that the OIF 
has improved with regards to understanding the related standards, but 
the best place to maintain consistency is where those standards are 
developed, be it the IETF or ITU-T.  We've all seen how terms get used 
differently in different bodies as a clear example.

Regardless of what people would like, every group has full right to 
discuss anything it wishes.  If the OIF wishes to develop stand-alone 
implementation agreements, fine.  But if the goal is an industry wide 
standard, then discussion at the OIF is not sufficient.  A full 
discussion is appropriate wherever the work is to be adopted.  The best 
we can hope for is that the things learned in one group will be clearly 
conveyed to help bring the other groups up to the same point without 
requiring a full discussion again.  We have a great opportunity to work 
together on these topics.  Let's do it.

Regards,

Mark Loyd Jones
Sprint
Technology Planning & Integration
913-794-2139

-----Original Message-----
From: kireeti [mailto:[email-masked]]
Sent: Monday, December 02, 2002 4:52 PM
To: xuyg
Cc: ccamp
Subject: Re: IETF 55 - CCAMP Minutes

Hi Yangguang,

On Mon, 2 Dec 2002, Yangguang Xu wrote:

> I wasn't at IETF.   From my reading of the draft and info from this
> thread, the overlay ID sounds like the P-UNI effort which has been
> discussed lengthily in OIF. Is my understanding correct? If so, can
> somebody clarify what happened to OIF about this effort and why it's
> being brought up in IETF now?

Your email suggests that a) if the OIF discussed this topic *lengthily*,
the IETF shouldn't; and b) if the OIF dropped the topic, the IETF
shouldn't bring it up.  What is the basis for these suggestions?

Note that:
a) the IETF is a standards body, whereas the OIF makes implementation
	agreements, and this is clearly an area that needs standards;
b) the IETF has every right to modify, extend and clarify the use of the
	protocols developed in the IETF (in this case, GMPLS RSVP-TE)
	(which is more than can be said of the OIF); and
c) the IETF has every right to "bring up" topics that other forums may
	or may not already have discussed, lengthily or otherwise,
	especially when it concerns protocols that the IETF developed.

Kireeti.

Delivery-date: Mon, 02 Dec 2002 15:24:34 -0800
Date: Mon, 02 Dec 2002 18:23:19 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: IETF 55 - CCAMP Minutes

Kireeti,

> 
> > I wasn't at IETF.   From my reading of the draft and info from this
> > thread, the overlay ID sounds like the P-UNI effort which has been
> > discussed lengthily in OIF. Is my understanding correct? If so, can
> > somebody clarify what happened to OIF about this effort and why it's
> > being brought up in IETF now?
> 
> Your email suggests that a) if the OIF discussed this topic *lengthily*,
> the IETF shouldn't; and b) if the OIF dropped the topic, the IETF
> shouldn't bring it up.  What is the basis for these suggestions?
> 

Wow! you do have some imagination. But I wasn't suggesting anything, rather, I
was stating a fact and ask for clarifications. I didn't know OIF totally dropped
the topic. You seem to know why OIF drop this topic, would you please share it
with us? The reason I am asking this clarification is because if OIF experts
dropped it after lengthily discussion, there must be some good reasons. (please
don't guess my intention again.)

> Note that:
> a) the IETF is a standards body, whereas the OIF makes implementation
>         agreements, and this is clearly an area that needs standards;

Sure. And I hope that for a type of application, standardization can help us
eliminate options rather than creating more. That's what standardization should
be, isn't it?

> b) the IETF has every right to modify, extend and clarify the use of the
>         protocols developed in the IETF (in this case, GMPLS RSVP-TE)
>         (which is more than can be said of the OIF); and

1200% support this. Indeed, did I ever argue (or hint) against this?

> c) the IETF has every right to "bring up" topics that other forums may
>         or may not already have discussed, lengthily or otherwise,
>         especially when it concerns protocols that the IETF developed.

We cool. It's fine with me. But I still hope you get my question answered.

Yangguang

Delivery-date: Mon, 02 Dec 2002 14:55:43 -0800
Date: Mon, 2 Dec 2002 14:52:06 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Yangguang Xu <[email-masked]>
cc: <[email-masked]>
Subject: Re: IETF 55 - CCAMP Minutes

Hi Yangguang,

On Mon, 2 Dec 2002, Yangguang Xu wrote:

> I wasn't at IETF.   From my reading of the draft and info from this
> thread, the overlay ID sounds like the P-UNI effort which has been
> discussed lengthily in OIF. Is my understanding correct? If so, can
> somebody clarify what happened to OIF about this effort and why it's
> being brought up in IETF now?

Your email suggests that a) if the OIF discussed this topic *lengthily*,
the IETF shouldn't; and b) if the OIF dropped the topic, the IETF
shouldn't bring it up.  What is the basis for these suggestions?

Note that:
a) the IETF is a standards body, whereas the OIF makes implementation
	agreements, and this is clearly an area that needs standards;
b) the IETF has every right to modify, extend and clarify the use of the
	protocols developed in the IETF (in this case, GMPLS RSVP-TE)
	(which is more than can be said of the OIF); and
c) the IETF has every right to "bring up" topics that other forums may
	or may not already have discussed, lengthily or otherwise,
	especially when it concerns protocols that the IETF developed.

Kireeti.

Delivery-date: Mon, 02 Dec 2002 11:28:30 -0800
Date: 2 Dec 2002 19:25:45 -0000
From: "venkat  d" <[email-masked]>
Reply-To: "venkat  d" <[email-masked]>
To: "Marcos Antonio De Almeida Cora" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Upstream Labels in GMPLS

Hai,=0A=0A     When a bi-directional request is sent for path establishment=
,any kind of failure irrespective of any error occurring for path towards d=
ownstream or path towards upstream will result in failure of the request as=
 a whole. So no path is established in either and the intiator has to try a=
gain with new set.=0A=0AThanks=0AVenkat=0A=0A=0A=0AOn Mon, 02 Dec 2002 Marc=
os Antonio De Almeida Cora wrote :=0A>[ post by non-subscriber.  with the m=
assive amount of spam, it is easy to miss=0A>   and therefore delete posts =
by non-subscribers.  if you wish to regularly=0A>   post from an address th=
at is not subscribed to this mailing list, send a=0A>   message to <listnam=
e>[email-masked] and ask to have the alternate=0A>   address added to =
the list of addresses from which submissions are=0A>   automatically accept=
ed. ]=0A>=0A>Hi,=0A>=0A>I have some doubts on Upstream Labels in GMPLS.=0A>=
First, GMPLS supports both "unidirectional LSPs" and "bidirectional LSPs" ?=
??=0A>I would like to know if when a initiator node send a request message=
=0A>(Path/RSVP or Label Request/CR-LDP) with a Upstream Label, and this lab=
el is=0A>not suitable for use at the next LSR, it must reject the request m=
essage=0A>and send a "Error message" to the initiator node. In this case, t=
he Error=0A>message may include an acceptable Label Set to tell the Upstrea=
m LSR wich=0A>labels would have been succeful.=0A>But if Upstream LSR decid=
e to fail the LSP set up, my doubt is: The=0A>unidirectional LSP will set u=
p and just the bidirectional LSP not is set=0A>up ?? or both uniderectional=
 and bidirectional will fail, and LSR=0A>initiator will try again ??=0A>=0A=
>Thanks,=0A>=0A>        Marcos=0A>=0A>_____________________________________=
____________________________=0A>=0A>   Marcos Ant=81=F4nio de Almeida Cor=
=81=E1=0A>   School of Electrical and Computer Engineering=0A>   Departamen=
t of Telematics=0A>   State University of Campinas/Brazil - UNICAMP=0A>   P=
hone: +55 (19) 3788.3711 - Branch: 73723=0A>   Home Page: www.dt.fee.unicam=
p.br/~cora=0A>_____________________________________________________________=
____=0A>=0A>=0A>=0A>=0A>=0A>=0A=0A=0A______________________________________=
__________________________=0A NIIT supports World Computer Literacy Day on =
2nd December. =0A Enroll for NIIT SWIFT Jyoti till 2nd December for only Rs=
. 749=0A and get free Indian Languages Office software worth Rs. 2500.=0A F=
or details contact your nearest NIIT centre, SWIFT Point=0A or click here h=
ttp://swift.rediff.com/=0A

Delivery-date: Mon, 02 Dec 2002 10:02:37 -0800
Date: Mon, 2 Dec 2002 15:00:34 -0200 (EDT)
From: Marcos Antonio De Almeida Cora <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Upstream Labels in GMPLS

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi, 

I have some doubts on Upstream Labels in GMPLS.
First, GMPLS supports both "unidirectional LSPs" and "bidirectional LSPs" ???
I would like to know if when a initiator node send a request message
(Path/RSVP or Label Request/CR-LDP) with a Upstream Label, and this label is 
not suitable for use at the next LSR, it must reject the request message 
and send a "Error message" to the initiator node. In this case, the Error
message may include an acceptable Label Set to tell the Upstream LSR wich
labels would have been succeful.
But if Upstream LSR decide to fail the LSP set up, my doubt is: The
unidirectional LSP will set up and just the bidirectional LSP not is set
up ?? or both uniderectional and bidirectional will fail, and LSR
initiator will try again ??

Thanks, 

       Marcos

_________________________________________________________________

  Marcos Ant�ônio de Almeida Cor�á    
  School of Electrical and Computer Engineering
  Departament of Telematics
  State University of Campinas/Brazil - UNICAMP
  Phone: +55 (19) 3788.3711 - Branch: 73723   
  Home Page: www.dt.fee.unicamp.br/~cora
_________________________________________________________________

Delivery-date: Mon, 02 Dec 2002 06:33:45 -0800
Date: Mon, 02 Dec 2002 09:13:04 -0500
From: Ron Bonica <[email-masked]>
Subject: FW: IETF 55 - CCAMP Minutes
To: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_tCbkSyhawQ8nnjVkCsrfUw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

 Folks,

Please comment on these minutes of the CCAMP WG meeting. If there are no
comments by Friday, I will archive them.

                                                                    Ron

 ===============================

 IETF 54 CCAMP Meeting Minutes
 ==============================

 Schedule rearranged due to technical difficulties.....

0930-0935
http://www.ietf.org/internet-drafts/draft-swallow-gmpls-overlay-00.txt

 G.Swallow: discussed the application of gmpls for overlay
 networks, ending with a proposal for making this a
 wg i-d (proposed standard)

 K.Kompella: asked for people in favor/opposed: Fewer than
 thirty people resonded, with a slight majority of those responding
 in favor.

 S.Throwbridge: asked whether the proposal was aligned with
 the carrier requirements (without more details)

 K.Kompella: let's bring it to the mailing list.

 also some comments:

 " Dmitri: Could you comment on applicability of incompatibility with
 other documents."

 "Can you comment on backward compatibility with the other lmp
 documents ?"

 Kireeti:  Can someone come up here and sing during the break? *)

 0935 - 0950
 http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt
                 Lang

 Provided summary of updates to LMP draft.  See his slides for details.
 Thinks we are ready for IESG last call. Summary of updates to LMP
 WDM draft.
 See slides for details. Ready for WG last call.

 Bonica: initiate last call on list after meeting.

 LMP Test Sonet SDH draft. See slides for details. After changes,
 we should solicit
 comments from list. We would like a WG last call thereafter. Get
 a feel from the room?

 Kireeti:  Assuming that J0-64 format is removed, are there any comments?

 Bert: The base LMP document was intended for proposed standard.
 We got pushback
 from ITU people stating that we should not be working on some of
 this stuff, so we
 split it out to a separate document. Are we intending on prop
 standard for this stuff?

 Kireeti: Yes, prop. Standards stuff.

 Bert: Are we on our proper turf? I would like ITU people to speak
 up on this as well
 as review it. I don't want discussion during last call, want
 resolution now.

 Kim: Question RE: LMP. I checked minor editing errors in LMP Ver 7.
 After this meeting I'll tell Mr. Lang them. After reading LMP
specification,
 I believe the security consideration has mandatory configuration. Is my
understanding right?

 Lang: Yes, security considerations are mandatory.

 Kim: I would like security to be optional.

 Bert: Security considerations may not be optional.  We can have
 some as optional,
 but some mandatory security options are required.

 Kireeti: It is mandatory to define security - how to run LMP in a
 secure mode.
 It is not mandatory to run LMP in a secure mode. Can you?

 Lang: That is correct, it can be run un-secure.  Ipsec is defined
 for LMP.
 If you do not want to run IPSec, you can run it without.

 Speaker 2: I am concerned about J0 encoding. It doesn't seem to
 be consistent with ITU
 T.50 requirement. Printable ASCII characters in particular might
 be an issue.

 Bert: Please pose question to mailing list.

 Ron: That way we will have record of conversation.

 Lyndon Ong(Cienna): My company is editing 7714.1 ITU document.
 Will there be any
 additional alignment with this?

 Lang: I think the 7714.1 document is more closely related to
 bootstrap document, and
 I would lke to discuss this in next part of presentation.

 Lyndon: This is now taking LMP and LMP-WDM that are tech
 specific. Are there any non-tech
 specific things that cannot be applied to both.

 Lang: The whole document can be applied to both.

 Kireeti: Is there any objection in ITU from letting IETF have
 this document or will
 we dribble out requirements one by one?

 ITU leason: I cannot speak for all ITUT, but we need to socialize
 this within the ITU.
 There is work going on with regard to discovery in ITU 7714 that
 might need to be aligned.
 However, I will try to get discussion going on rapidly.

 Dmitry P:  There may be issues with the way the messages are encoded.

 Kireeti:  We are not talking about discovery; test messages.
 Documents were separated
 so that we can work issues doc-by-doc.  Good to get ruling for
 each document. The
 typical issues with using J0 etc... has rules for how to use
 this.  Make clear that
 that some issues are about before service starts.

 Speaker 5: 7714 issue: if they do the same thing, then why define
 two documents for this?

 Lang: There may be overlap between next document, but not here.

 Speaker 5: Need to be clear about what the overlaps are.

 Lang: Bootstrap document (next doc), the intro describes why the
 doc exists.
 Prev. document is defined in LMP base document. If you disagree,
 let me know.

 LMP Bootstrap document. See slides for details. This is not WG
 document. Would like
 technical comments on list.

 Dmitri: Could you comment on applicability of incompatibility
 with other documents.

 Lang: The point to make is the information exchanged is the same
 as that for the LMP
 protocol. There is no new information exchanged.

 Kireeti: We need to continue this on the list (ITU input) on how
 we move these documents
 forward.

 Kireeti - CCAMP 55 WG status.

 Kireeti: Is there any problem with sending GMPLS framework to
 IESG as informational.

 Bert: I reviewed this doc a while back, and question is that
 non-standard extensions are
 detailed here. This seems strange to publish a document that
 suggests a way of signaling
 things without a document being somewhere that details the
 specifics somewhere.

 Dmitri: We have been looking for comments RE: pointers/document
 to fulfill your query. I
 think it is unfair to continue without filling these
 requirements. When I sent comments
 on the list, I asked people to provide pointers. If people would
 like to continue, please
 send pointers ASAP.

 Kireeti: As a fallback, what are we going to do if no docs are received.

 Bert: Throw it into the garbage.

 Kireeti: Unless we get pointers, this goes in the can.

 Kireeti: One thing has been asked about is changes to the
 charter. We want to make
 changes to the charter. Please send us suggestions. Few
 additions: inter-area (within AS
 domain),  Protection/restoration, optical VPN.  This will be
 discussed partially during
 SUB-IP meeting, but approval of charter changes come from IESG.

 JPV: Question about the charter. Will signaling between
 computation server and client are
 part of the charter, or do we need to add?

 Kireeti: The current charter does not explicitly have this. This
 is part of the charter
 extensions we are asking for.

 JPV: This can be used in other areas.

 Kireeti: Don't go there. If it is in the charter it is, if not
 then no. Need to make sure
 this is in the charter.

 Ron: I will send out an update on the charter additions
 (proposed) to the mailing list.

 Ashok - Interoperability draft.

 Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS.
 These are issues for RSVP.

 Bert: These are separate documents. Do this in RSVP.

 Lou:  Spec. requires TSPEC. Lets talk about this offline.

 Kireeti: Okay. I want to talk about some implementation
 recommendations. How are these
 published?

 Bert: Implementation recommendations are fine to either publish
 as BCP or Informational.
 I am worried about the limited set of specifications/issues and
 that they are captured.

 Kireeti: Generic RSVP things are already specified (according to
 Lou). Lets talk about
 this offline to see where changes are required. Define what
 issues are, how are they
 specified. Do this offline.  Should we add recommendations to
 implementation survey as an
 appendix?

 Bert: Whichever.

 Lou: These look like guidelines to implementations. This is
 usually done outside of spec.
 done as BCP/Info.

 Kireeti: Question is where to put it.

 Lou: Seems like this is not a BCP.

 Kireeti: Too early to say that these include "best" practices.
 Looks informational.
 Need to talk with Lou about remaining issues.

 Tom Nadeau did a presentation on the discussions
 regarding the GMPLS MIBs at the Sat MIB Meeting.

 * how Saturday meeting affects the GMPLS MIBs?

 * issues for CCAMP: how to represent SONET (i.e.
 longer) labels

 * proposed solution on label/index given
   Tom asked for feedback from the working group
    on this proposed solution

    type field + octet string

    goal is to support longer labels

 * Comment by Kireeti to rename
   Link Bundling MIB to TE-LINK-MIB.

 (No questions on presentation).

 Nadeau: MIB overview presentation

 Dora: MIB discussion. 2 issues.

 Tom: SNMP is just another management interface, and like any
 other tool, it needs to be
 used appropriately. Otherwise, you will have scalability and
 provisioning issues.

 Kireeti: Lets have a discussion on the list for all of these things.

 Bert: Discussion going on in IESG/SNMP community. Been hearing
 that people do not want to
 use SNMP for configuration.   However, I will defer to the WG for
 guidance on this. We
 need discussion on this issue, in particular from operators.
 Kireeti: We should take this to the mailing list.

 Protection/Restoration Team:

 Kireeti: I suggest that you kick off a discussion so that people
 can pick on points that
 might be controversial. We need to do this before we make this a
 WG document.  We need to
 take this into account.

 Dmitri:  We took existing protocols and analysed them.   What I
 have said is a
 consolidation. I think we are fine with the scope. We need to
 focus on the validation.

 Kireeti: We need to make sure there is a consensus on your cut
 off that it was reasonable.

 Bonica: Tunnel trace draft. See slides.  Is the requirements
 draft ready for WG last call.

 Monique:  How is this going to relate to LSP Ping?

 Ron: When you discover a tunnel, GTTP invokes LSP ping.  There is
 one open item: if the
 LSP is supported by an IP/IP tunnel. LSP Ping will not tell you this.

 Kireeti: Are there any comments from anyone else?  The
 requirements document is a WG
 document. Can we have a show of hands for support of GTTP
 proposed solution as WG
 document?  We have a small consensus in favor of this. Go back to
 mailing list to confirm.

 Dmitri: Draft.

 Dmitri: When you increase the scope of what GMPLS may cover. We
 need to handle the
 limited complexity here. This is what we have worked on.   We
 need to handle optical/PSTN.

 Kireeti: Lets not make this a WG document until discussion on the list.

--Boundary_(ID_tCbkSyhawQ8nnjVkCsrfUw)
Content-type: application/x-zip-compressed; name=IETF55.zip
Content-transfer-encoding: base64
Content-disposition: attachment; filename=IETF55.zip

--Boundary_(ID_tCbkSyhawQ8nnjVkCsrfUw)--

Delivery-date: Mon, 02 Dec 2002 06:11:15 -0800
Date: Mon, 02 Dec 2002 09:02:51 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: [email-masked]
CC: John Drake <[email-masked]>, "Ong, Lyndon" <[email-masked]>, "'Ron Bonica'" <[email-masked]>, [email-masked]
Subject: Re: IETF 55 - CCAMP Minutes

I wasn't at IETF. From my reading of the draft and info from this thread, the
overlay ID sounds like the P-UNI effort which has been discussed lengthily in
OIF. Is my understanding correct? If so, can somebody clarify what happened to
OIF about this effort and why it's being brought up in IETF now?

Thanks,

Yangguang

[email-masked] wrote:
> 
> john, the point is probably that from a * protocol *
> viewpoint i didn't hear any compelling argument during
> the meeting (or on the mailing list), so if there are
> any gmpls signalling or other protocol issues that seems
> unclear for the ccamp community it would be very good
> to settle them asap in order to move forward with this
> i-d
> 
> imho, this is the only reason why kireeti asked to move
> the discussion to the list
> 
> thanks,
> - dimitri.
> 
> John Drake wrote:
> >
> > My count was 27 yes, 3 no to the question of whether the overlay I-D should
> > become a working group draft
> >
> > -----Original Message-----
> > From: Ong, Lyndon [mailto:[email-masked]]
> > Sent: Monday, November 25, 2002 4:25 PM
> > To: 'Ron Bonica'; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: IETF 55 - CCAMP Minutes
> >
> > Hi Ron,
> >
> > Just adding some more notes on George's overlay presentation -
> >
> > The question was raised on the difference between this
> > and the OIF UNI work, George responded that the OIF UNI
> > is aimed at public service providers with a separate
> > address space, while this is not.  George also noted
> > that the current addressing in Session and Sender_Template
> > objects may be overly constrained for overlay.
> >
> > IMHO, I'm not sure I would say a vast majority supported
> > it, the vast majority was generally pretty quiet at the meeting.
> >
> > Cheers,
> >
> > Lyndon Ong
> >
> > -----Original Message-----
> > From: Ron Bonica [mailto:[email-masked]]
> > Sent: Sunday, November 24, 2002 7:10 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: IETF 55 - CCAMP Minutes
> >
> > Thanks!
> >
> > I will add this to the minutes.
> >
> >                   Ron
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > Sent: Sunday, November 24, 2002 10:12 PM
> > > To: Ron Bonica
> > > Cc: [email-masked]
> > > Subject: Re: IETF 55 - CCAMP Minutes
> > >
> > >
> > > hi ron, all
> > >
> > > i do not see the report on the gmpls for overlay networks
> > > what i have is as follows (may be others can correct me
> > > or complete this):
> > >
> > > G.Swallow: discussed the application of gmpls for overlay
> > > networks, ending with a proposal for making this a
> > > wg i-d (proposed standard) see for more details:
> > > http://www.ietf.org/internet-drafts/draft-swallow-gmpls-overlay-00.txt
> > >
> > > K.Kompella: asked for people in favor/opposed: the result
> > > was that only a few people (2 or 3) were opposed whilst
> > > the vast majority were in favor
> > >
> > > S.Throwbridge: asked whether the proposal was aligned with
> > > the carrier requirements (without more details)
> > >
> > > K.Kompella: let's bring it to the mailing list.
> > >
> > > also some comments:
> > >
> > > "> Dmitri: Could you comment on applicability of incompatibility with
> > > other
> > > > documents."
> > >
> > > "Can you comment on backward compatibility with the other lmp
> > > documents ?"
> > >
> > > thanks,
> > > - dimitri.
> > >
> > > Ron Bonica wrote:
> > > >
> > > > Folks,
> > > >
> > > > CCAMP WG minutes follow. Slides are attached. Please comment on
> > > the minutes
> > > > within two weeks so that we can make any required corrections
> > > and enter them
> > > > into the record.
> > > >
> > > >                                            Ron
> > > >
> > > > P.S. Kireeti's presentation provides a snapshot of WG status. I
> > > will make
> > > > sure that the ID tracker stays up to date so we will always
> > > have a current
> > > > picture of WG status.
> > > >
> > > > ===============================
> > > >
> > > > IETF 54 CCAMP Meeting Minutes
> > > > ==============================
> > > >
> > > > Schedule rearranged due to technical difficulties.....
> > > >
> > > > Kireeti:  Can someone come up here and sing during the break? *)
> > > >
> > > > 0935 - 0950
> > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-06.txt
> > > >                 Lang
> > > >
> > > > Provided summary of updates to LMP draft.  See his slides for details.
> > > > Thinks we are ready for IESG last call. Summary of updates to
> > > LMP WDM draft.
> > > > See slides for details. Ready for WG last call.
> > > >
> > > > Bonica: initiate last call on list after meeting.
> > > >
> > > > LMP Test Sonet SDH draft. See slides for details. After
> > > changes, we should
> > > > solicit
> > > > comments from list. We would like a WG last call thereafter.
> > > Get a feel from
> > > > the room?
> > > >
> > > > Kireeti:  Assuming that J0-64 format is removed, are there any comments?
> > > >
> > > > Bert: The base LMP document was intended for proposed standard. We got
> > > > pushback
> > > > from ITU people stating that we should not be working on some
> > > of this stuff,
> > > > so we
> > > > split it out to a separate document. Are we intending on prop
> > > standard for
> > > > this stuff?
> > > >
> > > > Kireeti: Yes, prop. Standards stuff.
> > > >
> > > > Bert: Are we on our proper turf? I would like ITU people to
> > > speak up on this
> > > > as well
> > > > as review it. I don't want discussion during last call, want
> > > resolution now.
> > > >
> > > > Speaker 1: Question RE: LMP. After this meeting I intend to
> > > start a draft.
> > > > After reading LMP specification, I believe it has mandatory
> > > configuration.
> > > > Are there security considerations.
> > > >
> > > > Lang: Yes, security considerations are mandatory.
> > > >
> > > > Speaker 1: I would like security to be optional.
> > > >
> > > > Bert: Security considerations may not be optional.  We can have some as
> > > > optional,
> > > > but some mandatory security options are required.
> > > >
> > > > Kireeti: It is mandatory to define security - how to run LMP in a secure
> > > > mode.
> > > > It is not mandatory to run LMP in a secure mode. Can you?
> > > >
> > > > Lang: That is correct, it can be run un-secure.  Ipsec is
> > > defined for LMP.
> > > > If you do not want to run IPSec, you can run it without.
> > > >
> > > > Speaker 2: I am concerned about J0 encoding. It doesn't seem to be
> > > > consistent with ITU
> > > > T.50 requirement. Printable ASCII characters in particular might be an
> > > > issue.
> > > >
> > > > Bert: Please pose question to mailing list.
> > > >
> > > > Ron: That way we will have record of conversation.
> > > >
> > > > Lyndon Ong(Cienna): My company is editing 7714.1 ITU document.
> > > Will there
> > > > be any
> > > > additional alignment with this?
> > > >
> > > > Lang: I think the 7714.1 document is more closely related to bootstrap
> > > > document, and
> > > > I would lke to discuss this in next part of presentation.
> > > >
> > > > Lyndon: This is now taking LMP and LMP-WDM that are tech
> > > specific. Are there
> > > > any non-tech
> > > > specific things that cannot be applied to both.
> > > >
> > > > Lang: The whole document can be applied to both.
> > > >
> > > > Kireeti: Is there any objection in ITU from letting IETF have
> > > this document
> > > > or will
> > > > we dribble out requirements one by one?
> > > >
> > > > ITU leason: I cannot speak for all ITUT, but we need to socialize this
> > > > within the ITU.
> > > > There is work going on with regard to discovery in ITU 7714
> > > that might need
> > > > to be aligned.
> > > > However, I will try to get discussion going on rapidly.
> > > >
> > > > Dmitry P:  There may be issues with the way the messages are encoded.
> > > >
> > > > Kireeti:  We are not talking about discovery; test messages.
> > > Documents were
> > > > separated
> > > > so that we can work issues doc-by-doc.  Good to get ruling for each
> > > > document. The
> > > > typical issues with using J0 etc... has rules for how to use this.  Make
> > > > clear that
> > > > that some issues are about before service starts.
> > > >
> > > > Speaker 5: 7714 issue: if they do the same thing, then why define two
> > > > documents for this?
> > > >
> > > > Lang: There may be overlap between next document, but not here.
> > > >
> > > > Speaker 5: Need to be clear about what the overlaps are.
> > > >
> > > > Lang: Bootstrap document (next doc), the intro describes why
> > > the doc exists.
> > > > Prev. document is defined in LMP base document. If you disagree, let me
> > > > know.
> > > >
> > > > LMP Bootstrap document. See slides for details. This is not WG document.
> > > > Would like
> > > > technical comments on list.
> > > >
> > > > Dmitri: Could you comment on applicability of incompatibility with other
> > > > documents.
> > > >
> > > > Lang: The point to make is the information exchanged is the
> > > same as that for
> > > > the LMP
> > > > protocol. There is no new information exchanged.
> > > >
> > > > Kireeti: We need to continue this on the list (ITU input) on how we move
> > > > these documents
> > > > forward.
> > > >
> > > > Kireeti - CCAMP 55 WG status.
> > > >
> > > > Kireeti: Is there any problem with sending GMPLS framework to IESG as
> > > > informational.
> > > >
> > > > Bert: I reviewed this doc a while back, and question is that
> > > non-standard
> > > > extensions are
> > > > detailed here. This seems strange to publish a document that
> > > suggests a way
> > > > of signaling
> > > > things without a document being somewhere that details the specifics
> > > > somewhere.
> > > >
> > > > Dmitri: We have been looking for comments RE: pointers/document
> > > to fulfill
> > > > your query. I
> > > > think it is unfair to continue without filling these
> > > requirements. When I
> > > > sent comments
> > > > on the list, I asked people to provide pointers. If people would like to
> > > > continue, please
> > > > send pointers ASAP.
> > > >
> > > > Kireeti: As a fallback, what are we going to do if no docs are received.
> > > >
> > > > Bert: Throw it into the garbage.
> > > >
> > > > Kireeti: Unless we get pointers, this goes in the can.
> > > >
> > > > Kireeti: One thing has been asked about is changes to the
> > > charter. We want
> > > > to make
> > > > changes to the charter. Please send us suggestions. Few additions:
> > > > inter-area (within AS
> > > > domain),  Protection/restoration, optical VPN.  This will be discussed
> > > > partially during
> > > > SUB-IP meeting, but approval of charter changes come from IESG.
> > > >
> > > > JPV: Question about the charter. Will signaling between
> > > computation server
> > > > and client are
> > > > part of the charter, or do we need to add?
> > > >
> > > > Kireeti: The current charter does not explicitly have this.
> > > This is part of
> > > > the charter
> > > > extensions we are asking for.
> > > >
> > > > JPV: This can be used in other areas.
> > > >
> > > > Kireeti: Don't go there. If it is in the charter it is, if not
> > > then no. Need
> > > > to make sure
> > > > this is in the charter.
> > > >
> > > > Ron: I will send out an update on the charter additions
> > > (proposed) to the
> > > > mailing list.
> > > >
> > > > Ashok - Interoperability draft.
> > > >
> > > > Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS. These are
> > > > issues for RSVP.
> > > >
> > > > Bert: These are separate documents. Do this in RSVP.
> > > >
> > > > Lou:  Spec. requires TSPEC. Lets talk about this offline.
> > > >
> > > > Kireeti: Okay. I want to talk about some implementation
> > > recommendations. How
> > > > are these
> > > > published?
> > > >
> > > > Bert: Implementation recommendations are fine to either publish
> > > as BCP or
> > > > Informational.
> > > > I am worried about the limited set of specifications/issues and
> > > that they
> > > > are captured.
> > > >
> > > > Kireeti: Generic RSVP things are already specified (according
> > > to Lou). Lets
> > > > talk about
> > > > this offline to see where changes are required. Define what
> > > issues are, how
> > > > are they
> > > > specified. Do this offline.  Should we add recommendations to
> > > implementation
> > > > survey as an
> > > > appendix?
> > > >
> > > > Bert: Whichever.
> > > >
> > > > Lou: These look like guidelines to implementations. This is usually done
> > > > outside of spec.
> > > > done as BCP/Info.
> > > >
> > > > Kireeti: Question is where to put it.
> > > >
> > > > Lou: Seems like this is not a BCP.
> > > >
> > > > Kireeti: Too early to say that these include "best" practices. Looks
> > > > informational.
> > > > Need to talk with Lou about remaining issues.
> > > >
> > > > Tom Nadeau did a presentation on the discussions
> > > > regarding the GMPLS MIBs at the Sat MIB Meeting.
> > > >
> > > > * how Saturday meeting affects the GMPLS MIBs?
> > > >
> > > > * issues for CCAMP: how to represent SONET (i.e.
> > > > longer) labels
> > > >
> > > > * proposed solution on label/index given
> > > >   Tom asked for feedback from the working group
> > > >    on this proposed solution
> > > >
> > > >    type field + octet string
> > > >
> > > >    goal is to support longer labels
> > > >
> > > > * Comment by Kireeti to rename
> > > >   Link Bundling MIB to TE-LINK-MIB.
> > > >
> > > > (No questions on presentation).
> > > >
> > > > Nadeau: MIB overview presentation
> > > >
> > > > Dora: MIB discussion. 2 issues.
> > > >
> > > > Tom: SNMP is just another management interface, and like any
> > > other tool, it
> > > > needs to be
> > > > used appropriately. Otherwise, you will have scalability and
> > > provisioning
> > > > issues.
> > > >
> > > > Kireeti: Lets have a discussion on the list for all of these things.
> > > >
> > > > Bert: Discussion going on in IESG/SNMP community. Been hearing
> > > that people
> > > > do not want to
> > > > use SNMP for configuration.   However, I will defer to the WG
> > > for guidance
> > > > on this. We
> > > > need discussion on this issue, in particular from operators.
> > > > Kireeti: We should take this to the mailing list.
> > > >
> > > > Protection/Restoration Team:
> > > >
> > > > Kireeti: I suggest that you kick off a discussion so that
> > > people can pick on
> > > > points that
> > > > might be controversial. We need to do this before we make this a WG
> > > > document.  We need to
> > > > take this into account.
> > > >
> > > > Dmitri:  We took existing protocols and analysed them.   What I
> > > have said is
> > > > a
> > > > consolidation. I think we are fine with the scope. We need to
> > > focus on the
> > > > validation.
> > > >
> > > > Kireeti: We need to make sure there is a consensus on your cut
> > > off that it
> > > > was reasonable.
> > > >
> > > > Bonica: Tunnel trace draft. See slides.  Is the requirements
> > > draft ready for
> > > > WG last call.
> > > >
> > > > Monique:  How is this going to relate to LSP Ping?
> > > >
> > > > Ron: When you discover a tunnel, GTTP invokes LSP ping.  There
> > > is one open
> > > > item: if the
> > > > LSP is supported by an IP/IP tunnel. LSP Ping will not tell you this.
> > > >
> > > > Kireeti: Are there any comments from anyone else?  The
> > > requirements document
> > > > is a WG
> > > > document. Can we have a show of hands for support of GTTP
> > > proposed solution
> > > > as WG
> > > > document?  We have a small consensus in favor of this. Go back
> > > to mailing
> > > > list to confirm.
> > > >
> > > > Dmitri: Draft.
> > > >
> > > > Dmitri: When you increase the scope of what GMPLS may cover. We need to
> > > > handle the
> > > > limited complexity here. This is what we have worked on.   We
> > > need to handle
> > > > optical/PSTN.
> > > >
> > > > Kireeti: Lets not make this a WG document until discussion on the list.
> > > >
> > > > ===========================================
> > > > Ronald P. Bonica       Ph: 703 886 1681
> > > > vBNS Engineering       page: 1 888 268 8021
> > > > Ashburn, Va.
> > > > ===========================================
> > > > "We are not on Earth to guard a museum, but
> > > > to cultivate a flourishing garden of life."
> > > >                 -- Angelo Giuseppe Roncalli
> > > >
> > > >
> > > ------------------------------------------------------------------------
> > > >                  Name: IETF55.zip
> > > >    IETF55.zip    Type: Zip Compressed Data
> > > (application/x-zip-compressed)
> > > >              Encoding: base64
> > >
> > > --
> > > Papadimitriou Dimitri
> > > E-mail : [email-masked]
> > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > E-mail : [email-masked]
> > > Public : http://psg.com/~dpapadimitriou/
> > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
> 
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361