Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF
From: Charles Kalmanek <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Date: Thu, 28 Feb 2002 22:16:18 -0500

My vote is for 1).

"Wijnen, Bert (Bert)" wrote:
> 
> CCAMP WG members,
> 
> before we start down another many 100s of emails re-discussing
> the same topic....
> 
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
> 
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Thanks
> Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Thu, 28 Feb 2002 18:05:38 -0800
Date: Fri, 01 Mar 2002 11:01:06 +0900
From: Yoshihiko SUEMURA <[email-masked]>
To: [email-masked]
Subject: Re: CCAMP Protection/Restoration Design Team

Hi all,

I wish my new draft
http://www.ietf.org/internet-drafts/draft-suemura-gmpls-restoration-signaling-00.txt
will also be considered.

Thank you,

Yoshihiko Suemura

On Sun, 24 Feb 2002 18:25:17 -0800 (PST),
Kireeti Kompella <[email-masked]> wrote:

> Hi Folks,
> 
> I'd like to thank all of you who volunteered for this work.  To keep
> the team small and effective, not everyone who volunteered could
> participate directly.  Note that you can (and should) participate
> through the CCAMP WG, by giving suggestions/feedback to the DT, and,
> if deemed necessary, by proposing alternate documents.
> 
> Finally, note that the design team is _just another set of authors_.
> The document(s) they produce are subject to WG consensus to progress
> to WG documents and beyond.
> 
> Here's the Protection/Restoration Design Team.  They have been on
> the job for a little over a month now.
> 
> Deborah Brungard
> Sudheer Dharanikota
> Jonathan Lang
> Guangzhi Li
> Eric Mannie
> Dimitri Papadimitriou
> Bala Rajagopalan
> Yakov Rekhter
> 
> Sudheer is the team lead.
> 
> Their charter ("you" in what follows refers to the DT):
> 
> a) read drafts re protection/restoration in CCAMP, IPO and MPLS.
>    These include (but are not limited to :-)):
> 
> *******	draft-ietf-tewg-restore-hierarchy-00.txt *******
> 
> 	draft-bala-protection-restoration-signaling-00.txt
> 	draft-bala-restoration-signaling-01.txt
> 	draft-ietf-ipo-carrier-requirements-00.txt (Section 10)
> 	draft-kini-restoration-shared-backup-01.txt
> 	draft-li-shared-mesh-restoration-01.txt
> 	draft-many-optical-restoration-01.txt
> 	draft-suemura-protection-hierarchy-00.txt
> 	draft-ylee-protection-occ-00.txt
> 	-----------------------------------------------------
> 	draft-atlas-rsvp-local-protect-interop-02.txt
> 	draft-chang-mpls-path-protection-03.txt
> 	draft-chang-mpls-rsvpte-path-protection-ext-02.txt
> 	draft-owens-crldp-path-protection-ext-01.txt
> 
>    The first draft is the requirements for Protection & Restoration
>    produced by the TEWG Design Team.  Functionality that you come up
>    with should satisfy these requirements; stuff that you come up
>    with that either goes beyond these requirements or doesn't meet
>    some of them should be called out so that we can re-evaluate.
> 
>    The drafts below the line may be MPLS-specific, so they may or may
>    not apply.
> 
> | AD's comment: For the first round... please refrain as much as possible
> | from going beyond the requirements specified in the first draft.  That
> | document restricted itself (on purpose) to requirements that are felt
> | to be realistic for real operators and in the reasonably short term.
> | So that is the scope you should be working in.
> 
> b) produce a terminology document, preferably using ITU-T terminology,
>    but having a decoder ring to translate to terminology in current
>    drafts as well as the TE WG document
> c) produce an interim analysis document, comparing and contrasting
>    approaches (i.e., the above drafts, published and ongoing work
>    at the ITU/T1-X1/...)
> 
> | AD's comment: And be careful. Leave the ITU and T1X1-... etc work in
> | those organisations if that is where it belongs (and often it does)!
> 
> d) produce a more complete version of (c)
> e) produce a functional spec delineating
>    o 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.
>    o Overall approach
>    o Objects/procedures/... needed in a protocol-independent fashion
> f) produce a document detailing the changes for RSVP-TE and CR-LDP
> g) produce a document detailing the changes for OSFP-TE and IS-IS-TE
> 
> The timeline for (a-c) is before the next IETF (March 1, 2002).
> 
> A first cut of (d) and (e) should be available by end of April, 2002.
> If there is rough consensus in the CCAMP WG for the approach in (e),
> work should then start on (f) and (g).
> 
> Kireeti.
> 
> 

-----------------------------------------------------------------
Yoshihiko SUEMURA 

Networking Research Laboratories, 
NEC Corporation
E-mail: [email-masked]
Phone: +81 44 856 8109, FAX: +81 44 856 8071

Envelope-to: [email-masked]
Delivery-date: Thu, 28 Feb 2002 17:01:27 -0800
Date: Thu, 28 Feb 2002 19:59:06 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: IETF & ITU-T
Cc: [email-masked]

> Can anyone point me to the IETF ITU-T formal agreement document referred to
> in an earlier post.

existing version - RFC 2436

update - draft-fishman-2436bis-01.txt

Scott

Delivery-date: Thu, 28 Feb 2002 14:50:32 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Morgan, Peter (Engineering)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: IETF & ITU-T	
Date: Thu, 28 Feb 2002 23:50:04 +0100

You probably are looking for RFC2436.
Also not that a new rev is in the works:
   draft-fishman-2436bis-01.txt

Bert 

> -----Original Message-----
> From: Morgan, Peter (Engineering) [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 11:16 PM
> To: [email-masked]'
> Cc: [email-masked]'
> Subject: IETF & ITU-T 
> 
> 
> Can anyone point me to the IETF ITU-T formal agreement 
> document referred to
> in an earlier post.
> 
> Thank You,
> Peter.
> 
> "If you know what you're doing, it's engineering - if you don't, it's
> research."
> 
> 

Delivery-date: Thu, 28 Feb 2002 14:45:10 -0800
Date: Thu, 28 Feb 2002 15:44:16 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Morgan, Peter (Engineering)" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: IETF & ITU-T

Peter,
I think the latest revision can be found in:
http://www.ietf.org/internet-drafts/draft-fishman-2436bis-01.txt
Regards,
Steve Trowbridge

"Morgan, Peter (Engineering)" wrote:
> 
> Can anyone point me to the IETF ITU-T formal agreement document referred to
> in an earlier post.
> 
> Thank You,
> Peter.
> 
> "If you know what you're doing, it's engineering - if you don't, it's
> research."

Delivery-date: Thu, 28 Feb 2002 14:22:18 -0800
From: "Morgan, Peter (Engineering)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: IETF & ITU-T	
Date: Thu, 28 Feb 2002 22:16:17 -0000

Can anyone point me to the IETF ITU-T formal agreement document referred to
in an earlier post.

Thank You,
Peter.

"If you know what you're doing, it's engineering - if you don't, it's
research."

Delivery-date: Thu, 28 Feb 2002 14:16:12 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: new WG co-chair
Date: Thu, 28 Feb 2002 23:13:47 +0100

Dear CCAMPers,

You may all have noticed that Vijay Gill did not have the time
lately to act as WG co-chair. We all know that he did a great job
when he did have more time in the past. Vijay, THANK you for that
good work.

We have found Ron Bonica to be prepared to take over from Vijay.
Ron, thanks for stepping up to the task at hand. I trust that you
and Kireeti will re-energize the WG to move ahead to try and achieve
the intended results as specified in the WG charter.

Bert 

Delivery-date: Thu, 28 Feb 2002 14:08:40 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 22:08:05 -0000

Eric/Shahram,  see addtional remarks below.  regards Neil

> Shahram> 1) If a router  is not GTTP upgraded, it will  drop 
> the TTL expired
> Shahram>    GTTP messages.  Consequently the host will not 
> receive any reply
> Shahram>    from that router,  which translates to a break  
> in the tunnel at
> Shahram>    that point.
> 
> For GTTP to be useful at all, the tunnel head ends must support it. 
> 
> If a particular  node within a tunnel does not support  GTTP, 
> but some nodes
> beyond  it do,  we won't  get complete  trace info,  but 
> should  be  able to
> continue tracing beyond the non-supporting node.
> 
> But the  basic point is valid,  that in order  to use GTTP to 
>  trace through
> your network,  your routers must  support it.  I  guess I 
> don't see  this as
> much of a problem.  I  wouldn't call it an interoperability 
> problem, because
> no existing mechanisms are broken by the use of GTTP. 
NH=> If you noted in some of my earlier mails I was very careful to refer to
'simple breaks' when using trail-trace type of mechanisms for defect
diagnosis.  If you ever get a misbranching/mismerging defect then:
-	you need to know it exists in the 1st place (not obvious how this
can be done....with CV it's trivial, as you see the source ID of any
offending LSP at the sink of the offended LSP, so you both detect/diagnose
immediately)....I'll ignore the fact that a whole raft of consequent actions
are also missing;
-	since the location of such defects cannot be known a priori, then if
you want the 'misbranched' GTTP messages to elicit a response then the
arbitrary nodes where they end up must be able to respond......and in
general this means the whole network/nodes need to be 'GTTP aware' and they
need a return channel to the source.
IMO any trail-trace functions are best used under the assumption that the
network is actually defect-free.....we need other tools to detect/handle the
defects (for the many reasons I tried to point out in earlier mails).
> 
> Shahram> 2) TTL expired user packets will now be forwarded to 
> UDP module
> Shahram>    instead of being dropped. Which could overload 
> the UDP module in
> Shahram>    certain situations.  
> 
> TTL-expired user packets are not simply dropped today; they 
> are forwarded to
> the ICMP module  to cause the generation of an  ICMP message. 
>  Usually there
> is some sort of limit placed on the number of packets that 
> can be queued for
> ICMP processing, or the  number of such packets that can be  
> seen in a given
> amount of  time, etc.  The  marginal overhead to  see whether 
> a  packet that
> makes it through to ICMP processing  is a GTTP packet doesn't 
> seem like that
> big a deal.
NH=> Asking ICMP to proxy for missing defect handling in MPLS is a
possibility....and as Geroge hints in an earlier mail is actually an example
of a layer violation, but so be it.  However, this should not be used in
XoverMPLS....you need a solution here that is self-contained within the MPLS
network.

Delivery-date: Thu, 28 Feb 2002 14:08:36 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 22:08:03 -0000

Thanks Steve....nice to hear a voice of sanity.

Just FYI.....many people from various IETF lists have privately asked me for
copies of Y.1711 (and/or Y.1710 - requirements/principles) and I have have
passed them on.  Also SG13 have sent formal liaisons to IETF/ATMF/MPLSF on
these already.  If anyone else wants a copy until such time they become
publically available please ask me and I'll do my best to post on.....but be
prepared for a little delay as I'll be travelling from tomorrow for a week
or so.

As an aside.....this ITU/IETF bickering is really helping nobody here.  Each
side can learn from the other.  I get really sad when I see destructive
comments about the G.805 layering/partitioning arch
stuff......why?....because its how we all actually work even if some of us
don't actually consciously recognise it.  G.805 just gives it a formal
base....and its a damn sight more useful than the almost useless L1/2/3
classifications (which mean nothing) and the OSI model which gives the
illusion there is only *one* layer network (at L3, OSI sense)....absolute
bunkum.  G.805 matches reality.  Give it a shot.

regards, Neil

> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: 28 February 2002 17:28
> To: Shahram Davari
> Cc: [email-masked]'; 'Randy Bush'; Cuevas, Enrique G, ALASO;
> [email-masked]; Brian Moore
> Subject: Re: draft-bonica-tunneltrace-02
> 
> 
> (snip)
> > Why? Simply because it is produced by ITU is not a logical 
> way to dismiss it. 
> > Do you think the ITU architecture is wrong and if so why? 
> and what architecture
> > (if any!) do you suggest that the requirements and 
> solutions should fit in to?
> ITU and IETF do have a formal cooperation agreement. This 
> does not mean that
> either organization needs to do what the other says, but in 
> the event IETF were
> to choose to diverge, it would at least be polite to send a 
> communication to
> the relevante ITU-T study group (in this case, SG13) to 
> indicate why. ITU-T
> input should at least be given serious consideration.
> 
> > As has been stated these are to a
> > large extent documented in the (sadly too new to get at for 
> free) documents
> > Y.1711/Y.1710 but were in the now expired though surely google-able
> > draft-harrison... 
> My understanding is that these should be made available to 
> IETF through a
> public ftp site in the next few days. Material from Study 
> Group 15 has been
> shared in this way in the past. A similar mechanism is now 
> being set up for
> Study Group 13.
> 
> Regards,
> Steve Trowbridge
> 

Delivery-date: Thu, 28 Feb 2002 14:08:33 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 22:08:04 -0000

George....you are simply wrong here *if* applied architecturally correctly.
But please explain/list examples of layer violations you are aware of.
BTW - If anyone takes what you have written at face value then all tunnels
should be banned, ie they are *all* layer violations (I see Shahram also
noted exactly similar).  Sadly, from what I see you may be actually correct
in many cases (ie relying on fault management of one layer to proxy for
inadequacies in another layer)....but you'd need to think the consequences
of that out very carefully and the potential implications before you take it
further.

In the meantime.....

Think of a leased line (as a server...any technology) that you do not
own.....or even a duct network (yes its a real network, bottom layer in
fact....and sets the inherited disjoint connectiveity graph for *all* layers
above it) that you do not own, and I am aware of Andy Reid of BT here
telling me you lost a bet with him over virtualisation here.  A 'Tunnel' is
a colloquialism for a (more formally defined) server layer trail (which can
be a link connection between client layer nodes).  If you don't/can't grok
this yet please read the text book by Reid/Sexton on Broadband Networking or
G.805.....and tell us what is factually wrong with what is in there.  I am
finding these terse 'I know better than you' assertions not all
constructive....esp when they are plainly wrong, like this one (*if* done
arch correctly of course).

Neil

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: 28 February 2002 17:12
> To: Shahram Davari
> Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked];
> [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02 
> 
> 
> Shahram -
> 
> > and layer violation issues.
> 
> Any sort of a tunnel is a layer violation in and of itself.  So if you
> have to violate those same layers to trace them so be it.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 

Delivery-date: Thu, 28 Feb 2002 14:05:38 -0800
Date: Thu, 28 Feb 2002 16:29:29 -0500
From: Luis Aguirre-Torres <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

--------------0D5CD2AFDCD9D8EAE4318B87
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[ post by non-subscriber ]

1)

Luis

-----Original Message-----

> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Sunday, February 24, 2002 7:11 PM
> To: Wijnen, Bert (Bert)
> Cc: Mannie, Eric; [email-masked]'; [email-masked]'; ccamp-wg;
> [email-masked]'
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
>
>
>
>
> On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:
>
> > Guys... I have seen to much of this. I have asked Kireeti
> > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> > WG mailing list. I do NOT want another 500 emails going back
> > and forth on this issue. We need to approach this pragmatically.
> >
> > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the
> >   WG mailing list on what exactly we agreed in SLC. That will
> >   help to prepare a response to ITU-T as well
>
> First off, I should apologize for letting this go on unchecked.
>
> Second, I should make it known to the WG as a whole that there was
> a discussion of this issue at SLC among several folks directly
> involved, the ADs and the chairs.  I thought we had achieved
> consensus, but now it seems not.
>
> Here's what I thought we had agreed:
>
> 1) There is a document in the ITU that defines a *single* standard
> that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the only
> such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET
>
>    that do not match the ITU document.
>
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
>
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
>
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
>
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
>
> 1) Do you think we should have just a single set of traffic parameters
>
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
>
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
>
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
>
> Thanks,
> Kireeti.
>

--
Luis Aguirre-Torres

AT&T Labs
Room A5 1E04
200 S. Laurel Avenue,
Middletown, NJ 07748
USA

Tel: +1 732 420 9046
Fax: +1 732 368 9433

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<font size=-1>1)</font><font size=-1></font>
<p><font size=-1>Luis</font><font size=-1></font>
<p><font size=-1>-----Original Message-----</font>
<blockquote TYPE=CITE><font size=-1>From: Kireeti Kompella [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]</font>
<br><font size=-1>Sent: Sunday, February 24, 2002 7:11 PM</font>
<br><font size=-1>To: Wijnen, Bert (Bert)</font>
<br><font size=-1>Cc: Mannie, Eric; [email-masked]'; [email-masked]';
ccamp-wg;</font>
<br><font size=-1>[email-masked]'</font>
<br><font size=-1>Subject: RE: SONET/SDH label agreement for IETF, ITU-T
and OIF</font>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p><font size=-1>On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:</font>
<p><font size=-1>> Guys... I have seen to much of this. I have asked Kireeti</font>
<br><font size=-1>> EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS
on the</font>
<br><font size=-1>> WG mailing list. I do NOT want another 500 emails going
back</font>
<br><font size=-1>> and forth on this issue. We need to approach this pragmatically.</font>
<br><font size=-1>></font>
<br><font size=-1>> - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT
on the</font>
<br><font size=-1>>&nbsp;&nbsp; WG mailing list on what exactly we agreed
in SLC. That will</font>
<br><font size=-1>>&nbsp;&nbsp; help to prepare a response to ITU-T as
well</font>
<p><font size=-1>First off, I should apologize for letting this go on unchecked.</font>
<p><font size=-1>Second, I should make it known to the WG as a whole that
there was</font>
<br><font size=-1>a discussion of this issue at SLC among several folks
directly</font>
<br><font size=-1>involved, the ADs and the chairs.&nbsp; I thought we
had achieved</font>
<br><font size=-1>consensus, but now it seems not.</font>
<p><font size=-1>Here's what I thought we had agreed:</font>
<p><font size=-1>1) There is a document in the ITU that defines a *single*
standard that</font>
<br><font size=-1>&nbsp;&nbsp; encompasses both SONET and SDH -- almost.&nbsp;
There are a few signals</font>
<br><font size=-1>&nbsp;&nbsp; that are in SONET but not in SDH; it was
believed that the only such</font>
<br><font size=-1>&nbsp;&nbsp; signal was VC-3.&nbsp; Also, there are "legacy"
implementations of SONET</font>
<br><font size=-1>&nbsp;&nbsp; that do not match the ITU document.</font>
<p><font size=-1>2) Thus, it was agreed (to my recollection) that both
the SONET and</font>
<br><font size=-1>&nbsp;&nbsp; SDH label formats will be retained, with
wording that says that</font>
<br><font size=-1>&nbsp;&nbsp; whenever possible, the SDH equivalent should
be used.&nbsp; This covers</font>
<br><font size=-1>&nbsp;&nbsp; both the cases of SONET signals that don't
have SDH equivalents,</font>
<br><font size=-1>&nbsp;&nbsp; and legacy equipment.</font>
<p><font size=-1>It is *not* the IETF's intention to promote an artificial
separation</font>
<br><font size=-1>between SONET and SDH.&nbsp; Nor is it the intent to
promote as standard</font>
<br><font size=-1>work that is now "pre-standard".</font>
<p><font size=-1>However, it *is* the IETF's goal to be able to set up
paths across</font>
<br><font size=-1>SONET and SDH networks, and to be pragmatic about this.&nbsp;
This was</font>
<br><font size=-1>the spirit in which an agreement was forged -- or so
I thought.&nbsp; In</font>
<br><font size=-1>retrospect, it would have been wise to go one step further
and</font>
<br><font size=-1>decide the actual words.</font>
<p><font size=-1>So, here we are again, arguing over this.&nbsp; Let's
follow the AD's</font>
<br><font size=-1>suggestion and look for consensus in the WG.</font>
<p><font size=-1>1) Do you think we should have just a single set of traffic
parameters</font>
<br><font size=-1>&nbsp;&nbsp; and label values for SDH, and none for SONET?</font>
<br><font size=-1>or</font>
<br><font size=-1>2) Do you think we should have one for SONET and one
for SDH, with</font>
<br><font size=-1>&nbsp;&nbsp; the proviso that, if an SDH equivalent is
available, one SHOULD</font>
<br><font size=-1>&nbsp;&nbsp; use the SDH equivalent?</font>
<br><font size=-1>or</font>
<br><font size=-1>3) Do you think we should have one for SONET and one
for SDH, with</font>
<br><font size=-1>&nbsp;&nbsp; the proviso that, if an SDH equivalent is
available, one MUST</font>
<br><font size=-1>&nbsp;&nbsp; use the SDH equivalent?</font>
<p><font size=-1>(in the above, SHOULD and MUST are to be interpreted as
in RFC 2119.)</font>
<p><font size=-1>PLEASE respond with just (1), (2) or (3), and avoid long
diatribes!</font>
<p><font size=-1>Feedback is welcome from *all* those interested in the
CCAMP WG.</font>
<br><font size=-1>Also, what we are looking for is rough consensus, not
votes.</font>
<p><font size=-1>Thanks,</font>
<br><font size=-1>Kireeti.</font>
<br>&nbsp;</blockquote>

<p>--
<br>Luis Aguirre-Torres
<p>AT&amp;T Labs
<br>Room A5 1E04
<br>200 S. Laurel Avenue,
<br>Middletown, NJ 07748
<br>USA
<p>Tel: +1 732 420 9046
<br>Fax: +1 732 368 9433
<br>&nbsp;</html>

--------------0D5CD2AFDCD9D8EAE4318B87--

Delivery-date: Thu, 28 Feb 2002 12:50:19 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 20:49:28 -0000

Eric....can I please ask that you separate slagging-off of the ITU from the
issues.....you do eventually get back to reason I note.  If you want to air
your own prejudices, lack of understanding of the issues being discussed and
have a rant about the ITU then that's OK, but it does not really help
anyone.  Many of your company's customers actually have great respect for
ITU transport Recs, and your own company's success is largely predicated on
the fact that operators have built massive transport networks which are used
to interconnect your company's boxes and create a network....IP on it's own
can't get between boxes, it does need something underneath it.

BTW - The 'arcane' layered network ITU Rec I assume you are alluding to (and
Shahram actually did not) is G.805.....this Rec just states fact (but does
so in a common/rigorous language that many operators/vendors found necessary
to formulate), and there are many manufacturers/operators out there who (i)
helped develop this Rec and (ii) use it to ensure functional architecture
implementations (inter)work/make-sense.  I personally know many of the
engineers who did this work, and let me assure these people are not
stupid...OK?  If you have a problem with this fact that is *your* problem
not the ITU's, not the IETF's and certainly not Shahram's.  So please
exercise some restraint on this ITU bashing as it does you no credit at all.

regards, Neil

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: 28 February 2002 14:59
> To: Shahram Davari
> Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02 
> 
> 
> 
> Shahram> It  has serious  security, complexity,  backward  
> compatibility and
> Shahram> layer violation issues.
> 
> Tom> Can you elaborate on what you think these are? 
> 
> Shahram> Please refer to previous emails by me and David 
> Allan. Most of them
> Shahram> are listed there.  
> 
> I'm sorry, but  as far as I  can tell, those previous mails  
> simply say that
> (a)  the  proposed  solution doesn't  do  some  things  that 
> you  think  are
> valuable,  and (b)  the proposed  solution doesn't  fit well  
> into  some ITU
> architecture.
> 
> The  second  of  these  points  is  completely  irrelevant.   
> The  first  is
> irrelevant too, unless there is a reasonable alternative 
> proposed which does
> more,  or if the  current proposal  doe so  little that  SPs 
> don't  think it
> worthwhile.   The MPLS OAM  stuff you've  been pushing  is 
> not  a reasonable
> alternative of  this sort  because (a)  it is MPLS-specific,  
> and (b)  it is
> already crystal  clear that it will not  be accepted in the  
> IETF.  And it's
> pretty clear  that a number of SPs  do think that what  the 
> current proposal
> does is worthwhile.
> 
> If  you can actually  cite specific  security issues  with 
> the  proposal, it
> would be valuable to know about them. 
> 
> Suggestions for reducing complexity would  also be valuable, 
> if you have any
> specific suggestions in that area. 
> 
> I don't understand what the backwards compatibility issue is, 
> as there is no
> previous version to be compatible with.
> 
> If you think there  are layer violation issues, then what you 
>  need to do is
> exhibit the particular set of  specific problems that will 
> arise in practice
> as a result of those violations.   If you cannot do this 
> without referencing
> some arcane ITU  architecture document, then the natural  
> conclusion is that
> the  problem  is with  that  architecture's  layering  model, 
> not  with  the
> proposal.
> 
> 
> 
> 
> 

Delivery-date: Thu, 28 Feb 2002 12:50:17 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 20:49:27 -0000

Yes Tom...you are correct.  The draft Mina is referring to only covers fault
management aspects.  I'd like to understand how element registers are done
wrt metrics collected/thresholding/exception(normal)_reporting/etc......I
have told our Ops guys to get on to this as I am not a MIB expert myself and
I don't know how good the stuff you/others have been doing is.  However, a
further aspect of 'management' is billing and usually doing this against
delivering some SLA......so if you can't measure availability (ergo QoS)
then there are some strongly related issues here.  I recall asking you about
this some time ago (ie how can you measure availability when defects are not
even defined?) and got a less than satisfactory answer...I let it pass at
the time, but at some stage I'll want to get to the bottom of this.

regards, Neil

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: 28 February 2002 16:53
> To: Mina Azad
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> 
> >I just want to clarify that "Requirements for OAM in MPLS Networks"
> >draft-harrison-mpls-oam-req-01.txt is live and kicking (exp. 
> May 2002).
> >
> >Draft-bonica focuses on tunnel tracing only, i.e. only one 
> aspect of MPLS 
> >management.
> 
> >Draft-harrison-mpls-oam-req-01.txt covers all aspects of 
> MPLS management.
> 
>          I would be careful with statements like that. I 
> personally think 
> that statement is
> inaccurate. I would characterize it as one characterization of for 
> management of
> MPLS, but certainly not _the_ specification for how management should
> be done by any means.
> 
>          --Tom
> 
> 
> 
> >Therefore with regards to MPLS, 
> draft-harrison-mpls-oam-req-01 is more 
> >"generic" than draft-bonica.
> >
> >Regards,
> >
> >Mina Azad
> >
> > > -----Original Message-----
> > > From: Gibson, Mark 
> > [<mailto:[email-masked]>mailto:[email-masked]]
> > > Sent: Thursday, February 28, 2002 10:32 AM
> > > To: [email-masked]
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > > As an impartial observer, there seems to be an obvious way
> > > forward for this
> > > discussion.
> > >
> > > In the first instance, draft-bonica-tunneltrace-02 can go
> > > through the usual
> > > process in the wg meeting in Minneapolis and, subject to
> > > rough consensus,
> > > become adopted as a solution for the cases that it solves.  I
> > > believe even
> > > the proponents of the mplsoam scheme concede that the tunnel
> > > trace solution
> > > has merit in certain circumstances.  [a point made by Dave
> > > Allan as I type]
> > > Lets document that solution space and, if technically
> > > sufficient, advance
> > > this draft such that tunnel trace can meet all the points in
> > > that space it
> > > can.
> > >
> > > In the second instance, lets define the specifics of the
> > > remainder of the
> > > OAM problem space and work on some solutions that solve these
> > > problems.
> > > From memory, there were a number of individuals in the OAM
> > > BoF who, though a
> > > minority were a large minority who believed something more
> > > substantive than
> > > tunnel trace was needed, including a number of operators.
> > > Presumably these
> > > guys know what their requirements are.  As has been stated
> > > these are to a
> > > large extent documented in the (sadly too new to get at for
> > > free) documents
> > > Y.1711/Y.1710 but were in the now expired though surely 
> google-able
> > > draft-harrison...
> > >
> > > And finally, lets stop this "not invented here" mentality.
> > > I'm not sure
> > > that dismissing ITU documents because that's what they are
> > > does the IETF any
> > > favours at all.  (c.f. the diatribe against the WAP
> > > representative at the
> > > Adelaide open plenary).
> > >
> > > Mark
> > >
> > >  -----Original Message-----
> > > From:         Eric Rosen 
> > [<mailto:[email-masked]>mailto:[email-masked]]
> > > Sent: 28 February 2002 14:59
> > > To:   Shahram Davari
> > > Cc:   'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
> > > Subject:      Re: draft-bonica-tunneltrace-02
> > >
> > >
> > > Shahram> It  has serious  security, complexity,  backward
> > > compatibility and
> > > Shahram> layer violation issues.
> > >
> > > Tom> Can you elaborate on what you think these are?
> > >
> > > Shahram> Please refer to previous emails by me and David
> > > Allan. Most of them
> > > Shahram> are listed there.
> > >
> > > I'm sorry, but  as far as I  can tell, those previous mails
> > > simply say that
> > > (a)  the  proposed  solution doesn't  do  some  things  that
> > > you  think  are
> > > valuable,  and (b)  the proposed  solution doesn't  fit well
> > > into  some ITU
> > > architecture.
> > >
> > > The  second  of  these  points  is  completely  irrelevant.
> > > The  first  is
> > > irrelevant too, unless there is a reasonable alternative
> > > proposed which does
> > > more,  or if the  current proposal  doe so  little that  SPs
> > > don't  think it
> > > worthwhile.   The MPLS OAM  stuff you've  been pushing  is
> > > not  a reasonable
> > > alternative of  this sort  because (a)  it is MPLS-specific,
> > > and (b)  it is
> > > already crystal  clear that it will not  be accepted in the
> > > IETF.  And it's
> > > pretty clear  that a number of SPs  do think that what  the
> > > current proposal
> > > does is worthwhile.
> > >
> > > If  you can actually  cite specific  security issues  with
> > > the  proposal, it
> > > would be valuable to know about them.
> > >
> > > Suggestions for reducing complexity would  also be valuable,
> > > if you have any
> > > specific suggestions in that area.
> > >
> > > I don't understand what the backwards compatibility issue is,
> > > as there is no
> > > previous version to be compatible with.
> > >
> > > If you think there  are layer violation issues, then what you
> > >  need to do is
> > > exhibit the particular set of  specific problems that will
> > > arise in practice
> > > as a result of those violations.   If you cannot do this
> > > without referencing
> > > some arcane ITU  architecture document, then the natural
> > > conclusion is that
> > > the  problem  is with  that  architecture's  layering  model,
> > > not  with  the
> > > proposal.
> > >
> > >
> > >
> > >
> > >
> > >
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 
> 

Delivery-date: Thu, 28 Feb 2002 12:34:39 -0800
To: Shahram Davari <[email-masked]>
cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02 
Reply-To: [email-masked]
Date: Thu, 28 Feb 2002 15:33:58 -0500
From: Eric Rosen <[email-masked]>

Shahram> 1) If a router  is not GTTP upgraded, it will  drop the TTL expired
Shahram>    GTTP messages.  Consequently the host will not receive any reply
Shahram>    from that router,  which translates to a break  in the tunnel at
Shahram>    that point.

For GTTP to be useful at all, the tunnel head ends must support it. 

If a particular  node within a tunnel does not support  GTTP, but some nodes
beyond  it do,  we won't  get complete  trace info,  but should  be  able to
continue tracing beyond the non-supporting node.

But the  basic point is valid,  that in order  to use GTTP to  trace through
your network,  your routers must  support it.  I  guess I don't see  this as
much of a problem.  I  wouldn't call it an interoperability problem, because
no existing mechanisms are broken by the use of GTTP. 

Shahram> 2) TTL expired user packets will now be forwarded to UDP module
Shahram>    instead of being dropped. Which could overload the UDP module in
Shahram>    certain situations.  

TTL-expired user packets are not simply dropped today; they are forwarded to
the ICMP module  to cause the generation of an  ICMP message.  Usually there
is some sort of limit placed on the number of packets that can be queued for
ICMP processing, or the  number of such packets that can be  seen in a given
amount of  time, etc.  The  marginal overhead to  see whether a  packet that
makes it through to ICMP processing  is a GTTP packet doesn't seem like that
big a deal.

Delivery-date: Thu, 28 Feb 2002 12:34:36 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Richard Rabbat' <[email-masked]>,  "'Michael I Mandelberg(Isaac)'" <[email-masked]>,  [email-masked]
Subject: RE: Question re: reference in GMPLS-ARCH
Date: Thu, 28 Feb 2002 21:32:25 +0100

Thanks, noted.

Eric

-----Original Message-----
From: Richard Rabbat [mailto:[email-masked]]
Sent: Thursday, February 28, 2002 8:52 PM
To: 'Michael I Mandelberg(Isaac)'; [email-masked]
Subject: RE: Question re: reference in GMPLS-ARCH

Hi Michael,

Refer to RFC 3031 at http://www.ietf.org/rfc/rfc3031.txt
I believe the authors of draft-ietf-ccamp-gmpls-architecture-01.txt
probably missed the reference.

Richard.

--
Richard Rabbat, Ph.D.
Fujitsu Laboratories of America, Inc.
595 Lawrence Expressway, Sunnyvale, CA 94040
Phone: 1-408-530-4537. Fax: 1-408-530-4515

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael I Mandelberg(Isaac)
Sent: Thursday, February 28, 2002 11:15 AM
To: [email-masked]
Subject: Question re: reference in GMPLS-ARCH

Simple question. The current GMPLS Architecture doc references
[MPLS-ARCH],
but this is not found in the references section at the end. Could
someone
point me to the reference?

Thanks

Michael Mandelberg

Delivery-date: Thu, 28 Feb 2002 12:08:05 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 12:07:16 -0800

Eric,
> 
> Thanks for extracting Dave's note on security issues; I 
> apologize for having
> missed that in  the noise.  That is certainly a reasonable  
> set of issues to
> discuss before turning the GTTP document into a Proposed Standard. 

Good.

> 
> I don't think your compatibility issues are valid.
> 
> > It is not compatible with RFC792 and RFC1122. 
> 
> > 1) RFC792 says: 
> 
> > "If the gateway processing a datagram finds the time to 
> live field is zero
> > it must discard the datagram" 
> 
> > GTTP draft says: 
> 
> > On TTL expiration forward the GTTP messages to a local GTTP module. 
> 
> I'm not sure  that I see what the incompatibility is;  
> "discard a packet" is
> generally interpreted as  meaning "do not continue to  
> forward the packet to
> its destination address". 
> 
> If you  can show  an interoperability  problem of some  sort, 
> that  would be
> interesting.

Here they are:

1)If a router is not GTTP upgraded, it will drop the TTL expired GTTP messages. 
Consequently the host will not receive any reply from that router, which 
translates to a break in the tunnel at that point.

2)TTL expired user packets will now be forwarded to UDP module instead of being
dropped. Which could overload the UDP module in certain situations.

> 
> > 2) RFC1122 says: 
> 
> > "An incoming Time Exceeded message MUST be passed to the 
> transport layer." 
> 
> > GTTP draft says: 
> 
> > "The error-processing module sends an  ICMP Time Expired 
> Message to D1. D1
> > discards this ICMP message."
> 
> RFC1122  is  not   meant  to  apply  to  routers. 
 
Yes it does. Actually RFC 1812 (router requirements) references 1122.

> Even   so, 
>  there  is  no
> incompatibility, because it is not the IP layer at D1 that is 
> discarding the
> message, but  the higher layer.  Perhaps  what the doc should 
>  really say is
> that GTTP should discard the ICMP Time Expired Messages.

OK. 

> 
> On  the issue of  layer violations,  I think  that if  you 
> cannot  state the
> problem   in  practical   terms,  without   using  the   
> words   "layer"  or
> "architecture", then there is no problem.
> 

I am working on examples. I will send it to you later.

-Shahram 

Delivery-date: Thu, 28 Feb 2002 11:53:06 -0800
From: "Richard Rabbat" <[email-masked]>
To: "'Michael I Mandelberg\(Isaac\)'" <[email-masked]>, <[email-masked]>
Subject: RE: Question re: reference in GMPLS-ARCH
Date: Thu, 28 Feb 2002 11:52:29 -0800

Hi Michael,

Refer to RFC 3031 at http://www.ietf.org/rfc/rfc3031.txt
I believe the authors of draft-ietf-ccamp-gmpls-architecture-01.txt
probably missed the reference.

Richard.

--
Richard Rabbat, Ph.D.
Fujitsu Laboratories of America, Inc.
595 Lawrence Expressway, Sunnyvale, CA 94040
Phone: 1-408-530-4537. Fax: 1-408-530-4515

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael I Mandelberg(Isaac)
Sent: Thursday, February 28, 2002 11:15 AM
To: [email-masked]
Subject: Question re: reference in GMPLS-ARCH

Simple question. The current GMPLS Architecture doc references
[MPLS-ARCH],
but this is not found in the references section at the end. Could
someone
point me to the reference?

Thanks

Michael Mandelberg

Delivery-date: Thu, 28 Feb 2002 11:31:49 -0800
content-class: urn:content-classes:message
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Thu, 28 Feb 2002 14:30:34 -0500
From: "Lazer, Monica A, ALCNS" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, <[email-masked]>, <[email-masked]>, "ccamp-wg" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C1C08E.6414756A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Definitely 1.

-----Original Message-----
From: Kireeti Kompella [ mailto:[email-masked]]
Sent: Sunday, February 24, 2002 7:11 PM
To: Wijnen, Bert (Bert)
Cc: Mannie, Eric; [email-masked]'; [email-masked]'; ccamp-wg;
[email-masked]'
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:

> Guys... I have seen to much of this. I have asked Kireeti
> EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> WG mailing list. I do NOT want another 500 emails going back
> and forth on this issue. We need to approach this pragmatically.
>
> - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the
>   WG mailing list on what exactly we agreed in SLC. That will
>   help to prepare a response to ITU-T as well

First off, I should apologize for letting this go on unchecked.

Second, I should make it known to the WG as a whole that there was
a discussion of this issue at SLC among several folks directly
involved, the ADs and the chairs.  I thought we had achieved
consensus, but now it seems not.

Here's what I thought we had agreed:

1) There is a document in the ITU that defines a *single* standard that
   encompasses both SONET and SDH -- almost.  There are a few signals
   that are in SONET but not in SDH; it was believed that the only such
   signal was VC-3.  Also, there are "legacy" implementations of SONET
   that do not match the ITU document.

2) Thus, it was agreed (to my recollection) that both the SONET and
   SDH label formats will be retained, with wording that says that
   whenever possible, the SDH equivalent should be used.  This covers
   both the cases of SONET signals that don't have SDH equivalents,
   and legacy equipment.

It is *not* the IETF's intention to promote an artificial separation
between SONET and SDH.  Nor is it the intent to promote as standard
work that is now "pre-standard".

However, it *is* the IETF's goal to be able to set up paths across
SONET and SDH networks, and to be pragmatic about this.  This was
the spirit in which an agreement was forged -- or so I thought.  In
retrospect, it would have been wise to go one step further and
decide the actual words.

So, here we are again, arguing over this.  Let's follow the AD's
suggestion and look for consensus in the WG.

1) Do you think we should have just a single set of traffic parameters
   and label values for SDH, and none for SONET?
or
2) Do you think we should have one for SONET and one for SDH, with
   the proviso that, if an SDH equivalent is available, one SHOULD
   use the SDH equivalent?
or
3) Do you think we should have one for SONET and one for SDH, with
   the proviso that, if an SDH equivalent is available, one MUST
   use the SDH equivalent?

(in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)

PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Feedback is welcome from *all* those interested in the CCAMP WG.
Also, what we are looking for is rough consensus, not votes.

Thanks,
Kireeti.

------_=_NextPart_001_01C1C08E.6414756A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE></TITLE>

<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><BR>
<P><FONT size=3D2><STRONG>Definitely =
1.</STRONG><BR><BR><BR>-----Original=20
Message-----<BR>From: Kireeti Kompella [<A=20
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>Se=
nt:=20
Sunday, February 24, 2002 7:11 PM<BR>To: Wijnen, Bert (Bert)<BR>Cc: =
Mannie,=20
Eric; [email-masked]'; [email-masked]';=20
ccamp-wg;<BR>[email-masked]'<BR>Subject: RE: SONET/SDH label agreement =
for=20
IETF, ITU-T and OIF<BR><BR><BR><BR><BR>On Fri, 22 Feb 2002, Wijnen, Bert =
(Bert)=20
wrote:<BR><BR>&gt; Guys... I have seen to much of this. I have asked=20
Kireeti<BR>&gt; EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on=20
the<BR>&gt; WG mailing list. I do NOT want another 500 emails going =
back<BR>&gt;=20
and forth on this issue. We need to approach this =
pragmatically.<BR>&gt;<BR>&gt;=20
- WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on =
the<BR>&gt;&nbsp;&nbsp;=20
WG mailing list on what exactly we agreed in SLC. That =
will<BR>&gt;&nbsp;&nbsp;=20
help to prepare a response to ITU-T as well<BR><BR>First off, I should =
apologize=20
for letting this go on unchecked.<BR><BR>Second, I should make it known =
to the=20
WG as a whole that there was<BR>a discussion of this issue at SLC among =
several=20
folks directly<BR>involved, the ADs and the chairs.&nbsp; I thought we =
had=20
achieved<BR>consensus, but now it seems not.<BR><BR>Here's what I =
thought we had=20
agreed:<BR><BR>1) There is a document in the ITU that defines a *single* =

standard that<BR>&nbsp;&nbsp; encompasses both SONET and SDH -- =
almost.&nbsp;=20
There are a few signals<BR>&nbsp;&nbsp; that are in SONET but not in =
SDH; it was=20
believed that the only such<BR>&nbsp;&nbsp; signal was VC-3.&nbsp; Also, =
there=20
are "legacy" implementations of SONET<BR>&nbsp;&nbsp; that do not match =
the ITU=20
document.<BR><BR>2) Thus, it was agreed (to my recollection) that both =
the SONET=20
and<BR>&nbsp;&nbsp; SDH label formats will be retained, with wording =
that says=20
that<BR>&nbsp;&nbsp; whenever possible, the SDH equivalent should be =
used.&nbsp;=20
This covers<BR>&nbsp;&nbsp; both the cases of SONET signals that don't =
have SDH=20
equivalents,<BR>&nbsp;&nbsp; and legacy equipment.<BR><BR>It is *not* =
the IETF's=20
intention to promote an artificial separation<BR>between SONET and =
SDH.&nbsp;=20
Nor is it the intent to promote as standard<BR>work that is now=20
"pre-standard".<BR><BR>However, it *is* the IETF's goal to be able to =
set up=20
paths across<BR>SONET and SDH networks, and to be pragmatic about =
this.&nbsp;=20
This was<BR>the spirit in which an agreement was forged -- or so I=20
thought.&nbsp; In<BR>retrospect, it would have been wise to go one step =
further=20
and<BR>decide the actual words.<BR><BR>So, here we are again, arguing =
over=20
this.&nbsp; Let's follow the AD's<BR>suggestion and look for consensus =
in the=20
WG.<BR><BR>1) Do you think we should have just a single set of traffic=20
parameters<BR>&nbsp;&nbsp; and label values for SDH, and none for=20
SONET?<BR>or<BR>2) Do you think we should have one for SONET and one for =
SDH,=20
with<BR>&nbsp;&nbsp; the proviso that, if an SDH equivalent is =
available, one=20
SHOULD<BR>&nbsp;&nbsp; use the SDH equivalent?<BR>or<BR>3) Do you think =
we=20
should have one for SONET and one for SDH, with<BR>&nbsp;&nbsp; the =
proviso=20
that, if an SDH equivalent is available, one MUST<BR>&nbsp;&nbsp; use =
the SDH=20
equivalent?<BR><BR>(in the above, SHOULD and MUST are to be interpreted =
as in=20
RFC 2119.)<BR><BR>PLEASE respond with just (1), (2) or (3), and avoid =
long=20
diatribes!<BR><BR>Feedback is welcome from *all* those interested in the =
CCAMP=20
WG.<BR>Also, what we are looking for is rough consensus, not=20
votes.<BR><BR>Thanks,<BR>Kireeti.<BR><BR></FONT></P></BODY></HTML>

------_=_NextPart_001_01C1C08E.6414756A--

Delivery-date: Thu, 28 Feb 2002 11:18:01 -0800
From: "Michael I Mandelberg(Isaac)" <[email-masked]>
To: [email-masked]
Subject: Question re: reference in GMPLS-ARCH
Date: Thu, 28 Feb 2002 14:15:27 -0500

Simple question. The current GMPLS Architecture doc references [MPLS-ARCH],
but this is not found in the references section at the end. Could someone
point me to the reference?

Thanks

Michael Mandelberg

Delivery-date: Thu, 28 Feb 2002 10:03:49 -0800
From: Shahram Davari <[email-masked]>
To: "'Randy Bush'" <[email-masked]>, Mina Azad <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 10:03:22 -0800

Randy,

I think you have missed the point (which has been raised many times):

The harrison-req draft easily applies to any layered network not just MPLS.

-Shahram

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 12:11 PM
> To: Mina Azad
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> > I just want to clarify that "Requirements for OAM in MPLS Networks" 
> > draft-harrison-mpls-oam-req-01.txt is live and kicking 
> (exp. May 2002). 
> > 
> > Draft-bonica focuses on tunnel tracing only, i.e. only one 
> aspect of MPLS
> > management.
> > Draft-harrison-mpls-oam-req-01.txt covers all aspects of 
> MPLS management. 
> > Therefore with regards to MPLS, 
> draft-harrison-mpls-oam-req-01 is more
> > "generic" than draft-bonica.
> 
> no argument there.  but remember, this wg is for COMMON 
> (across lower layer
> technologies) measurement.  so the fact that bonica's covers 
> more than mpls
> tunnels speaks well for it.
> 
> randy
> 

Delivery-date: Thu, 28 Feb 2002 10:00:37 -0800
From: Shahram Davari <[email-masked]>
To: "'George Swallow'" <[email-masked]>
Cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 09:59:44 -0800

George,
 
> Shahram -
> 
> > and layer violation issues.
> 
> Any sort of a tunnel is a layer violation in and of itself.  

Very interesting point of view. This is the first time I have heard this.

-Shahram

Delivery-date: Thu, 28 Feb 2002 09:44:02 -0800
To: Shahram Davari <[email-masked]>
cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02 
Reply-To: [email-masked]
Date: Thu, 28 Feb 2002 12:42:56 -0500
From: Eric Rosen <[email-masked]>

Thanks for extracting Dave's note on security issues; I apologize for having
missed that in  the noise.  That is certainly a reasonable  set of issues to
discuss before turning the GTTP document into a Proposed Standard. 

I don't think your compatibility issues are valid.

> It is not compatible with RFC792 and RFC1122. 

> 1) RFC792 says: 

> "If the gateway processing a datagram finds the time to live field is zero
> it must discard the datagram" 

> GTTP draft says: 

> On TTL expiration forward the GTTP messages to a local GTTP module. 

I'm not sure  that I see what the incompatibility is;  "discard a packet" is
generally interpreted as  meaning "do not continue to  forward the packet to
its destination address". 

If you  can show  an interoperability  problem of some  sort, that  would be
interesting. 

> 2) RFC1122 says: 

> "An incoming Time Exceeded message MUST be passed to the transport layer." 

> GTTP draft says: 

> "The error-processing module sends an  ICMP Time Expired Message to D1. D1
> discards this ICMP message."

RFC1122  is  not   meant  to  apply  to  routers.  Even   so,  there  is  no
incompatibility, because it is not the IP layer at D1 that is discarding the
message, but  the higher layer.  Perhaps  what the doc should  really say is
that GTTP should discard the ICMP Time Expired Messages.

On  the issue of  layer violations,  I think  that if  you cannot  state the
problem   in  practical   terms,  without   using  the   words   "layer"  or
"architecture", then there is no problem.

On  the issue  of  ITU architectures,  as I  said,  the fact  that some  ITU
architecture says this or that is irrelevant.  (It does not follow from this
that everything the ITU does is wrong.) 

Now, if you think that the MPLS OAM proposal is alive and kicking, I suggest
you try to set up a BoF to discuss it ... 

Delivery-date: Thu, 28 Feb 2002 09:28:44 -0800
Date: Thu, 28 Feb 2002 10:28:10 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Shahram Davari <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked], Brian Moore <[email-masked]>
Subject: Re: draft-bonica-tunneltrace-02

(snip)
> Why? Simply because it is produced by ITU is not a logical way to dismiss it. 
> Do you think the ITU architecture is wrong and if so why? and what architecture
> (if any!) do you suggest that the requirements and solutions should fit in to?
ITU and IETF do have a formal cooperation agreement. This does not mean that
either organization needs to do what the other says, but in the event IETF were
to choose to diverge, it would at least be polite to send a communication to
the relevante ITU-T study group (in this case, SG13) to indicate why. ITU-T
input should at least be given serious consideration.

> As has been stated these are to a
> large extent documented in the (sadly too new to get at for free) documents
> Y.1711/Y.1710 but were in the now expired though surely google-able
> draft-harrison... 
My understanding is that these should be made available to IETF through a
public ftp site in the next few days. Material from Study Group 15 has been
shared in this way in the past. A similar mechanism is now being set up for
Study Group 13.

Regards,
Steve Trowbridge

Delivery-date: Thu, 28 Feb 2002 09:12:50 -0800
From: Randy Bush <[email-masked]>
To: Mina Azad <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 09:11:21 -0800

> I just want to clarify that "Requirements for OAM in MPLS Networks" 
> draft-harrison-mpls-oam-req-01.txt is live and kicking (exp. May 2002). 
> 
> Draft-bonica focuses on tunnel tracing only, i.e. only one aspect of MPLS
> management.
> Draft-harrison-mpls-oam-req-01.txt covers all aspects of MPLS management. 
> Therefore with regards to MPLS, draft-harrison-mpls-oam-req-01 is more
> "generic" than draft-bonica.

no argument there.  but remember, this wg is for COMMON (across lower layer
technologies) measurement.  so the fact that bonica's covers more than mpls
tunnels speaks well for it.

randy

Envelope-to: [email-masked]
Delivery-date: Thu, 28 Feb 2002 09:12:48 -0800
Message-Id: <[email-masked]>
To: Shahram Davari <[email-masked]>
cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 12:12:27 -0500
From: George Swallow <[email-masked]>

Shahram -

> and layer violation issues.

Any sort of a tunnel is a layer violation in and of itself.  So if you
have to violate those same layers to trace them so be it.

...George

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

Delivery-date: Thu, 28 Feb 2002 09:06:24 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 09:01:50 -0800

Eric,

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 9:59 AM
> To: Shahram Davari
> Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02 
> 
> 
> 
> Shahram> It  has serious  security, complexity,  backward  
> compatibility and
> Shahram> layer violation issues.
> 
> Tom> Can you elaborate on what you think these are? 
> 
> Shahram> Please refer to previous emails by me and David 
> Allan. Most of them
> Shahram> are listed there.  
> 
> I'm sorry, but  as far as I  can tell, those previous mails  
> simply say that
> (a)  the  proposed  solution doesn't  do  some  things  that 
> you  think  are
> valuable,  and (b)  the proposed  solution doesn't  fit well  
> into  some ITU
> architecture.

These issues were raised by Neil, not me and Dave. And they mostly apply to
the GTTP not the requirement draft under discussion. 

> 
> The  second  of  these  points  is  completely  irrelevant.

Why? Simply because it is produced by ITU is not a logical way to dismiss it. Do you think the ITU architecture is wrong and if so why? and what architecture (if any!) do you suggest that the requirements and solutions should fit in to?
   
> The  first  is
> irrelevant too, unless there is a reasonable alternative 
> proposed which does
> more,  or if the  current proposal  doe so  little that  SPs 
> don't  think it
> worthwhile.

Many SPs have this view.

> The MPLS OAM  stuff you've  been pushing  is 
> not  a reasonable
> alternative of  this sort  because (a)  it is MPLS-specific,

This shows that you haven't read the MPLS OAM documents. It has been written with generality in mind and could be applied to any network such as ATM, FR, Ethernet, etc. The reason that it is initially focused on MPLS, is due to immediate need for an OAM tool for MPLS networks. 

> and (b)  it is
> already crystal  clear that it will not  be accepted in the  
> IETF.

Thanks to excellent technical justification and no politics!

> And it's
> pretty clear  that a number of SPs  do think that what  the 
> current proposal
> does is worthwhile.

It was also pretty clear that a number of SPs (much larger than the number you are referring to) did think that MPLS OAM proposal is worthwhile. Was it enough to accept it in IETF?

> 
> If  you can actually  cite specific  security issues  with 
> the  proposal, it
> would be valuable to know about them.

Extracted from Dave's emails:

"1) I think a broader discussion of some of the security issues needs to be raised. First by whatever means a trace request needs to be able to be instantiated at a tunnel end 
point. Second, as a result of initiating a trace, any node in the network may be required to generate a response to the tracing application. Therefore the tracing application is required to promiscuously accept responses. A mechanism is required to authoritatively associate responses with requests and discard spurious messages. Further such a mechanism should not be able to be leveraged for denial of service attacks (e.g. spurious trace responses forcing lots of cryptography, defense against replay attacks etc.)."

"Actually the problem breaks down into about 4 things: 

- any host can inject trace requests into the network. 
- if you do not want to share trace information on your network, the only mechanism is to block replies. 
- if you are able to block replies, you are screening initiators (who can be anyone). This implies authentication and replay protection.

- any host can send malicious replies to a tracing agent. 
- you don't want unauthorized folks instructing other network elements to do things, but that is more an requirement of the system design, and not necessarily that of the protocol. "

> 
> Suggestions for reducing complexity would  also be valuable, 
> if you have any
> specific suggestions in that area.
> 
> I don't understand what the backwards compatibility issue is, 
> as there is no
> previous version to be compatible with.

It is not compatible with RFC792 and RFC1122. 

1) RFC792 says: 

"If the gateway processing a datagram finds the time to live field is zero it must discard the datagram"

GTTP draft says:

On TTL expiration forward the GTTP messages to a local GTTP module.

2) RFC1122 says:

"An incoming Time Exceeded message MUST be passed to the transport layer."

GTTP draft says:

"The error-processing module sends an ICMP Time Expired Message to D1. D1 discards this ICMP message."

> 
> If you think there  are layer violation issues, then what you 
>  need to do is
> exhibit the particular set of  specific problems that will 
> arise in practice
> as a result of those violations.

One of the main reasons for avoiding layer violations is to make a protocol future proof. Satisfying or not satisfying current practices is irrelevant.

>If you cannot do this 
> without referencing
> some arcane ITU  architecture document, then the natural  
> conclusion is that
> the  problem  is with  that  architecture's  layering  model, 
> not  with  the
> proposal.

If it is arcane for you, then I guess I can't discuss it with you.

-Shahram

> 
> 
> 
> 

Delivery-date: Thu, 28 Feb 2002 08:56:08 -0800
Date: Thu, 28 Feb 2002 11:53:20 -0500
To: "Mina Azad"<[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02 
Cc: [email-masked]

>I just want to clarify that "Requirements for OAM in MPLS Networks"
>draft-harrison-mpls-oam-req-01.txt is live and kicking (exp. May 2002).
>
>Draft-bonica focuses on tunnel tracing only, i.e. only one aspect of MPLS 
>management.

>Draft-harrison-mpls-oam-req-01.txt covers all aspects of MPLS management.

         I would be careful with statements like that. I personally think 
that statement is
inaccurate. I would characterize it as one characterization of for 
management of
MPLS, but certainly not _the_ specification for how management should
be done by any means.

         --Tom

>Therefore with regards to MPLS, draft-harrison-mpls-oam-req-01 is more 
>"generic" than draft-bonica.
>
>Regards,
>
>Mina Azad
>
> > -----Original Message-----
> > From: Gibson, Mark 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Thursday, February 28, 2002 10:32 AM
> > To: [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> > As an impartial observer, there seems to be an obvious way
> > forward for this
> > discussion.
> >
> > In the first instance, draft-bonica-tunneltrace-02 can go
> > through the usual
> > process in the wg meeting in Minneapolis and, subject to
> > rough consensus,
> > become adopted as a solution for the cases that it solves.  I
> > believe even
> > the proponents of the mplsoam scheme concede that the tunnel
> > trace solution
> > has merit in certain circumstances.  [a point made by Dave
> > Allan as I type]
> > Lets document that solution space and, if technically
> > sufficient, advance
> > this draft such that tunnel trace can meet all the points in
> > that space it
> > can.
> >
> > In the second instance, lets define the specifics of the
> > remainder of the
> > OAM problem space and work on some solutions that solve these
> > problems.
> > From memory, there were a number of individuals in the OAM
> > BoF who, though a
> > minority were a large minority who believed something more
> > substantive than
> > tunnel trace was needed, including a number of operators.
> > Presumably these
> > guys know what their requirements are.  As has been stated
> > these are to a
> > large extent documented in the (sadly too new to get at for
> > free) documents
> > Y.1711/Y.1710 but were in the now expired though surely google-able
> > draft-harrison...
> >
> > And finally, lets stop this "not invented here" mentality.
> > I'm not sure
> > that dismissing ITU documents because that's what they are
> > does the IETF any
> > favours at all.  (c.f. the diatribe against the WAP
> > representative at the
> > Adelaide open plenary).
> >
> > Mark
> >
> >  -----Original Message-----
> > From:         Eric Rosen 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: 28 February 2002 14:59
> > To:   Shahram Davari
> > Cc:   'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
> > Subject:      Re: draft-bonica-tunneltrace-02
> >
> >
> > Shahram> It  has serious  security, complexity,  backward
> > compatibility and
> > Shahram> layer violation issues.
> >
> > Tom> Can you elaborate on what you think these are?
> >
> > Shahram> Please refer to previous emails by me and David
> > Allan. Most of them
> > Shahram> are listed there.
> >
> > I'm sorry, but  as far as I  can tell, those previous mails
> > simply say that
> > (a)  the  proposed  solution doesn't  do  some  things  that
> > you  think  are
> > valuable,  and (b)  the proposed  solution doesn't  fit well
> > into  some ITU
> > architecture.
> >
> > The  second  of  these  points  is  completely  irrelevant.
> > The  first  is
> > irrelevant too, unless there is a reasonable alternative
> > proposed which does
> > more,  or if the  current proposal  doe so  little that  SPs
> > don't  think it
> > worthwhile.   The MPLS OAM  stuff you've  been pushing  is
> > not  a reasonable
> > alternative of  this sort  because (a)  it is MPLS-specific,
> > and (b)  it is
> > already crystal  clear that it will not  be accepted in the
> > IETF.  And it's
> > pretty clear  that a number of SPs  do think that what  the
> > current proposal
> > does is worthwhile.
> >
> > If  you can actually  cite specific  security issues  with
> > the  proposal, it
> > would be valuable to know about them.
> >
> > Suggestions for reducing complexity would  also be valuable,
> > if you have any
> > specific suggestions in that area.
> >
> > I don't understand what the backwards compatibility issue is,
> > as there is no
> > previous version to be compatible with.
> >
> > If you think there  are layer violation issues, then what you
> >  need to do is
> > exhibit the particular set of  specific problems that will
> > arise in practice
> > as a result of those violations.   If you cannot do this
> > without referencing
> > some arcane ITU  architecture document, then the natural
> > conclusion is that
> > the  problem  is with  that  architecture's  layering  model,
> > not  with  the
> > proposal.
> >
> >
> >
> >
> >
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Thu, 28 Feb 2002 08:40:44 -0800
From: "Mina Azad"<[email-masked]>
To: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 11:40:30 -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_01C1C076.A291C2A0
Content-Type: text/plain;
	charset="iso-8859-1"

I just want to clarify that "Requirements for OAM in MPLS Networks" 
draft-harrison-mpls-oam-req-01.txt is live and kicking (exp. May 2002). 

Draft-bonica focuses on tunnel tracing only, i.e. only one aspect of MPLS
management.
Draft-harrison-mpls-oam-req-01.txt covers all aspects of MPLS management. 
Therefore with regards to MPLS, draft-harrison-mpls-oam-req-01 is more
"generic" than draft-bonica.

Regards,

Mina Azad

> -----Original Message-----
> From: Gibson, Mark [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 10:32 AM
> To: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> As an impartial observer, there seems to be an obvious way 
> forward for this
> discussion.
> 
> In the first instance, draft-bonica-tunneltrace-02 can go 
> through the usual
> process in the wg meeting in Minneapolis and, subject to 
> rough consensus,
> become adopted as a solution for the cases that it solves.  I 
> believe even
> the proponents of the mplsoam scheme concede that the tunnel 
> trace solution
> has merit in certain circumstances.  [a point made by Dave 
> Allan as I type]
> Lets document that solution space and, if technically 
> sufficient, advance
> this draft such that tunnel trace can meet all the points in 
> that space it
> can.
> 
> In the second instance, lets define the specifics of the 
> remainder of the
> OAM problem space and work on some solutions that solve these 
> problems.
> From memory, there were a number of individuals in the OAM 
> BoF who, though a
> minority were a large minority who believed something more 
> substantive than
> tunnel trace was needed, including a number of operators.  
> Presumably these
> guys know what their requirements are.  As has been stated 
> these are to a
> large extent documented in the (sadly too new to get at for 
> free) documents
> Y.1711/Y.1710 but were in the now expired though surely google-able
> draft-harrison... 
> 
> And finally, lets stop this "not invented here" mentality.  
> I'm not sure
> that dismissing ITU documents because that's what they are 
> does the IETF any
> favours at all.  (c.f. the diatribe against the WAP 
> representative at the
> Adelaide open plenary).
> 
> Mark
> 
>  -----Original Message-----
> From: 	Eric Rosen [mailto:[email-masked]] 
> Sent:	28 February 2002 14:59
> To:	Shahram Davari
> Cc:	'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
> Subject:	Re: draft-bonica-tunneltrace-02 
> 
> 
> Shahram> It  has serious  security, complexity,  backward  
> compatibility and
> Shahram> layer violation issues.
> 
> Tom> Can you elaborate on what you think these are? 
> 
> Shahram> Please refer to previous emails by me and David 
> Allan. Most of them
> Shahram> are listed there.  
> 
> I'm sorry, but  as far as I  can tell, those previous mails  
> simply say that
> (a)  the  proposed  solution doesn't  do  some  things  that 
> you  think  are
> valuable,  and (b)  the proposed  solution doesn't  fit well  
> into  some ITU
> architecture.
> 
> The  second  of  these  points  is  completely  irrelevant.   
> The  first  is
> irrelevant too, unless there is a reasonable alternative 
> proposed which does
> more,  or if the  current proposal  doe so  little that  SPs 
> don't  think it
> worthwhile.   The MPLS OAM  stuff you've  been pushing  is 
> not  a reasonable
> alternative of  this sort  because (a)  it is MPLS-specific,  
> and (b)  it is
> already crystal  clear that it will not  be accepted in the  
> IETF.  And it's
> pretty clear  that a number of SPs  do think that what  the 
> current proposal
> does is worthwhile.
> 
> If  you can actually  cite specific  security issues  with 
> the  proposal, it
> would be valuable to know about them. 
> 
> Suggestions for reducing complexity would  also be valuable, 
> if you have any
> specific suggestions in that area. 
> 
> I don't understand what the backwards compatibility issue is, 
> as there is no
> previous version to be compatible with.
> 
> If you think there  are layer violation issues, then what you 
>  need to do is
> exhibit the particular set of  specific problems that will 
> arise in practice
> as a result of those violations.   If you cannot do this 
> without referencing
> some arcane ITU  architecture document, then the natural  
> conclusion is that
> the  problem  is with  that  architecture's  layering  model, 
> not  with  the
> proposal.
> 
> 
> 
> 
> 
> 

------_=_NextPart_001_01C1C076.A291C2A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02 </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I just want to clarify that &quot;Requirements for OAM in MPLS Networks&quot; </FONT>
<BR><FONT SIZE=2>draft-harrison-mpls-oam-req-01.txt is live and kicking (exp. May 2002). </FONT>
</P>

<P><FONT SIZE=2>Draft-bonica focuses on tunnel tracing only, i.e. only one aspect of MPLS management.</FONT>
<BR><FONT SIZE=2>Draft-harrison-mpls-oam-req-01.txt covers all aspects of MPLS management. </FONT>
<BR><FONT SIZE=2>Therefore with regards to MPLS, draft-harrison-mpls-oam-req-01 is more &quot;generic&quot; than draft-bonica.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Mina Azad</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Gibson, Mark [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, February 28, 2002 10:32 AM</FONT>
<BR><FONT SIZE=2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: draft-bonica-tunneltrace-02 </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; As an impartial observer, there seems to be an obvious way </FONT>
<BR><FONT SIZE=2>&gt; forward for this</FONT>
<BR><FONT SIZE=2>&gt; discussion.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In the first instance, draft-bonica-tunneltrace-02 can go </FONT>
<BR><FONT SIZE=2>&gt; through the usual</FONT>
<BR><FONT SIZE=2>&gt; process in the wg meeting in Minneapolis and, subject to </FONT>
<BR><FONT SIZE=2>&gt; rough consensus,</FONT>
<BR><FONT SIZE=2>&gt; become adopted as a solution for the cases that it solves.&nbsp; I </FONT>
<BR><FONT SIZE=2>&gt; believe even</FONT>
<BR><FONT SIZE=2>&gt; the proponents of the mplsoam scheme concede that the tunnel </FONT>
<BR><FONT SIZE=2>&gt; trace solution</FONT>
<BR><FONT SIZE=2>&gt; has merit in certain circumstances.&nbsp; [a point made by Dave </FONT>
<BR><FONT SIZE=2>&gt; Allan as I type]</FONT>
<BR><FONT SIZE=2>&gt; Lets document that solution space and, if technically </FONT>
<BR><FONT SIZE=2>&gt; sufficient, advance</FONT>
<BR><FONT SIZE=2>&gt; this draft such that tunnel trace can meet all the points in </FONT>
<BR><FONT SIZE=2>&gt; that space it</FONT>
<BR><FONT SIZE=2>&gt; can.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In the second instance, lets define the specifics of the </FONT>
<BR><FONT SIZE=2>&gt; remainder of the</FONT>
<BR><FONT SIZE=2>&gt; OAM problem space and work on some solutions that solve these </FONT>
<BR><FONT SIZE=2>&gt; problems.</FONT>
<BR><FONT SIZE=2>&gt; From memory, there were a number of individuals in the OAM </FONT>
<BR><FONT SIZE=2>&gt; BoF who, though a</FONT>
<BR><FONT SIZE=2>&gt; minority were a large minority who believed something more </FONT>
<BR><FONT SIZE=2>&gt; substantive than</FONT>
<BR><FONT SIZE=2>&gt; tunnel trace was needed, including a number of operators.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Presumably these</FONT>
<BR><FONT SIZE=2>&gt; guys know what their requirements are.&nbsp; As has been stated </FONT>
<BR><FONT SIZE=2>&gt; these are to a</FONT>
<BR><FONT SIZE=2>&gt; large extent documented in the (sadly too new to get at for </FONT>
<BR><FONT SIZE=2>&gt; free) documents</FONT>
<BR><FONT SIZE=2>&gt; Y.1711/Y.1710 but were in the now expired though surely google-able</FONT>
<BR><FONT SIZE=2>&gt; draft-harrison... </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; And finally, lets stop this &quot;not invented here&quot; mentality.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; I'm not sure</FONT>
<BR><FONT SIZE=2>&gt; that dismissing ITU documents because that's what they are </FONT>
<BR><FONT SIZE=2>&gt; does the IETF any</FONT>
<BR><FONT SIZE=2>&gt; favours at all.&nbsp; (c.f. the diatribe against the WAP </FONT>
<BR><FONT SIZE=2>&gt; representative at the</FONT>
<BR><FONT SIZE=2>&gt; Adelaide open plenary).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Mark</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Eric Rosen [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: 28 February 2002 14:59</FONT>
<BR><FONT SIZE=2>&gt; To:&nbsp;&nbsp; Shahram Davari</FONT>
<BR><FONT SIZE=2>&gt; Cc:&nbsp;&nbsp; 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: draft-bonica-tunneltrace-02 </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Shahram&gt; It&nbsp; has serious&nbsp; security, complexity,&nbsp; backward&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; compatibility and</FONT>
<BR><FONT SIZE=2>&gt; Shahram&gt; layer violation issues.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Tom&gt; Can you elaborate on what you think these are? </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Shahram&gt; Please refer to previous emails by me and David </FONT>
<BR><FONT SIZE=2>&gt; Allan. Most of them</FONT>
<BR><FONT SIZE=2>&gt; Shahram&gt; are listed there.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I'm sorry, but&nbsp; as far as I&nbsp; can tell, those previous mails&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; simply say that</FONT>
<BR><FONT SIZE=2>&gt; (a)&nbsp; the&nbsp; proposed&nbsp; solution doesn't&nbsp; do&nbsp; some&nbsp; things&nbsp; that </FONT>
<BR><FONT SIZE=2>&gt; you&nbsp; think&nbsp; are</FONT>
<BR><FONT SIZE=2>&gt; valuable,&nbsp; and (b)&nbsp; the proposed&nbsp; solution doesn't&nbsp; fit well&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; into&nbsp; some ITU</FONT>
<BR><FONT SIZE=2>&gt; architecture.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The&nbsp; second&nbsp; of&nbsp; these&nbsp; points&nbsp; is&nbsp; completely&nbsp; irrelevant.&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; The&nbsp; first&nbsp; is</FONT>
<BR><FONT SIZE=2>&gt; irrelevant too, unless there is a reasonable alternative </FONT>
<BR><FONT SIZE=2>&gt; proposed which does</FONT>
<BR><FONT SIZE=2>&gt; more,&nbsp; or if the&nbsp; current proposal&nbsp; doe so&nbsp; little that&nbsp; SPs </FONT>
<BR><FONT SIZE=2>&gt; don't&nbsp; think it</FONT>
<BR><FONT SIZE=2>&gt; worthwhile.&nbsp;&nbsp; The MPLS OAM&nbsp; stuff you've&nbsp; been pushing&nbsp; is </FONT>
<BR><FONT SIZE=2>&gt; not&nbsp; a reasonable</FONT>
<BR><FONT SIZE=2>&gt; alternative of&nbsp; this sort&nbsp; because (a)&nbsp; it is MPLS-specific,&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; and (b)&nbsp; it is</FONT>
<BR><FONT SIZE=2>&gt; already crystal&nbsp; clear that it will not&nbsp; be accepted in the&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; IETF.&nbsp; And it's</FONT>
<BR><FONT SIZE=2>&gt; pretty clear&nbsp; that a number of SPs&nbsp; do think that what&nbsp; the </FONT>
<BR><FONT SIZE=2>&gt; current proposal</FONT>
<BR><FONT SIZE=2>&gt; does is worthwhile.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If&nbsp; you can actually&nbsp; cite specific&nbsp; security issues&nbsp; with </FONT>
<BR><FONT SIZE=2>&gt; the&nbsp; proposal, it</FONT>
<BR><FONT SIZE=2>&gt; would be valuable to know about them. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Suggestions for reducing complexity would&nbsp; also be valuable, </FONT>
<BR><FONT SIZE=2>&gt; if you have any</FONT>
<BR><FONT SIZE=2>&gt; specific suggestions in that area. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I don't understand what the backwards compatibility issue is, </FONT>
<BR><FONT SIZE=2>&gt; as there is no</FONT>
<BR><FONT SIZE=2>&gt; previous version to be compatible with.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If you think there&nbsp; are layer violation issues, then what you </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; need to do is</FONT>
<BR><FONT SIZE=2>&gt; exhibit the particular set of&nbsp; specific problems that will </FONT>
<BR><FONT SIZE=2>&gt; arise in practice</FONT>
<BR><FONT SIZE=2>&gt; as a result of those violations.&nbsp;&nbsp; If you cannot do this </FONT>
<BR><FONT SIZE=2>&gt; without referencing</FONT>
<BR><FONT SIZE=2>&gt; some arcane ITU&nbsp; architecture document, then the natural&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; conclusion is that</FONT>
<BR><FONT SIZE=2>&gt; the&nbsp; problem&nbsp; is with&nbsp; that&nbsp; architecture's&nbsp; layering&nbsp; model, </FONT>
<BR><FONT SIZE=2>&gt; not&nbsp; with&nbsp; the</FONT>
<BR><FONT SIZE=2>&gt; proposal.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C076.A291C2A0--

Delivery-date: Thu, 28 Feb 2002 08:39:15 -0800
From: "David Allan"<[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 11:38:50 -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_01C1C076.667D5BD0
Content-Type: text/plain;
	charset="iso-8859-1"

Tom:

This was my original post.....(I think you commented on some of the
points)...

Dave

-----Original Message-----
From: Allan, David [CAR:NS00:EXCH] 
Sent: Wednesday, February 20, 2002 10:59 AM
To: Ron Bonica
Cc: [email-masked]
Subject: re: draft-bonica-tunneltrace-02

Ron: 
I have a number of comments on the draft. 
Clarifications: 

The discussion of traceroute in section 5, 2nd para. Are you really saying
that 
traceroute only reveals the current layer/level and reveals no knowledge of
nesting of 
lower layer/level tunnels or the relationship of the current level to higher
levels? 
It doesn't clearly come out. 

Comments on application requirements (numbers correspond to the
requirement): 

1) I think a broader discussion of some of the security issues needs to be
raised. First by 
whatever means a trace request needs to be able to be instantiated at a
tunnel end 
point. Second, as a result of initiating a trace, any node in the network
may be required to 
generate a response to the tracing application. Therefore the tracing
application is required 
to promiscuously accept responses. A mechanism is required to
authoritatively associate 
responses with requests and discard spurious messages. Further such a
mechanism should not be 
able to be leveraged for denial of service attacks (e.g. spurious trace
responses forcing lots 
of cryptography, defense against replay attacks etc.). 

2) Any interface? I think any routable interface (mind you this is where
separating out routing 
limitations into a separate section reduces the clarity). I think there is a
separate stipulation that 
there is no representation as to the number of protocol exchanges it takes
to perform a trace 
(other than permitting the trace originator to perform some measure of flow
control by the protocol 
being designed to bound the number of responses a transaction will elicit;
ideally 1 to 1, this also 
has DOS implications similar to ICMP smurf type attacks whereby the
responses to a single 
message can be unbounded). You actually bring this up obliquely in the
protocol requirements, but IMHO it 
should be expressed less prescriptively. 

3) Is third party really a special case? Can I not instantiate an in-line
trace using management 
protocols etc. and pull back the results. 

4) the application "displays" tunnels (editorial nit)? are we really
discussing how much information the 
application collects and reports on. The alternative interpretation is that
the same amount of 
information is always collected, and somehow filtered during presentation. 

4) When you say "single hop" or "in detail", are you really saying "this
layer" or "constituent 
lower layer components"? It could use clarification. 

5) Are you sure the collected information includes round trip delay? It's
not clear to me 
whether this is some pre-existing chunk of information just lying around, or
where the trace 
transaction is expected to measure RTT on the fly for every hop and provide
current view. 

6) I think are more accurate statement is support any tunneling technology
that is used between 
IP endpoints. Otherwise this is not a sustainable requirement. I am
concerned, for example, that 
any intervening L2 or layer 2 and a half skewers the model. (e.g..
IP/PPP/L2TP, you can only 
reveal the PPP end points, or if you look at L2TP tunnel switches, you
appear to be SOL) 

7) This is the "detail" referred to earlier? Seems this one is subject to
the routing 
requirements reported later. Might be easier simply to introduce that
limitation here. 

8) Is the expectation that the quality of information obtained from a
control plane trace and a 
forwarding plane be comparable? Can you clarify what you mean by a control
plane trace? I can see augmenting 
signalling protocols to faciliate this (e.g. LSP query I-D), but that does
not fit into this discussion. 

10) This seems to be overlapping with a solution framework. 

11) Any intention of aligning TTL models with the terminology emerging
elsewhere (pipe or uniform 
models?). 

13) Don't quite grok the motivation. I plead ignorance ;-) 

The protocol requirements section is actually rather prescriptive. There are
specific requirements 
in there that end up as either application limitations or part of an
applicability statement (e.g. routing 
requirements) or design guidelines. The rest shouldn't be in this document. 

IMHO at the present time the document is not quite ready for "prime time". 

my two cents 
Dave 

------_=_NextPart_001_01C1C076.667D5BD0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Tom:</FONT>
</P>

<P><FONT SIZE=2>This was my original post.....(I think you commented on some of the points)...</FONT>
</P>

<P><FONT SIZE=2>Dave</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Allan, David [CAR:NS00:EXCH] </FONT>
<BR><FONT SIZE=2>Sent: Wednesday, February 20, 2002 10:59 AM</FONT>
<BR><FONT SIZE=2>To: Ron Bonica</FONT>
<BR><FONT SIZE=2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=2>Subject: re: draft-bonica-tunneltrace-02</FONT>
</P>
<BR>

<P><FONT SIZE=2>Ron: </FONT>
<BR><FONT SIZE=2>I have a number of comments on the draft. </FONT>
<BR><FONT SIZE=2>Clarifications: </FONT>
</P>

<P><FONT SIZE=2>The discussion of traceroute in section 5, 2nd para. Are you really saying that </FONT>
<BR><FONT SIZE=2>traceroute only reveals the current layer/level and reveals no knowledge of nesting of </FONT>
<BR><FONT SIZE=2>lower layer/level tunnels or the relationship of the current level to higher levels? </FONT>
<BR><FONT SIZE=2>It doesn't clearly come out. </FONT>
</P>

<P><FONT SIZE=2>Comments on application requirements (numbers correspond to the requirement): </FONT>
</P>

<P><FONT SIZE=2>1) I think a broader discussion of some of the security issues needs to be raised. First by </FONT>
<BR><FONT SIZE=2>whatever means a trace request needs to be able to be instantiated at a tunnel end </FONT>
<BR><FONT SIZE=2>point. Second, as a result of initiating a trace, any node in the network may be required to </FONT>
<BR><FONT SIZE=2>generate a response to the tracing application. Therefore the tracing application is required </FONT>
<BR><FONT SIZE=2>to promiscuously accept responses. A mechanism is required to authoritatively associate </FONT>
<BR><FONT SIZE=2>responses with requests and discard spurious messages. Further such a mechanism should not be </FONT>
<BR><FONT SIZE=2>able to be leveraged for denial of service attacks (e.g. spurious trace responses forcing lots </FONT>
<BR><FONT SIZE=2>of cryptography, defense against replay attacks etc.). </FONT>
</P>

<P><FONT SIZE=2>2) Any interface? I think any routable interface (mind you this is where separating out routing </FONT>
<BR><FONT SIZE=2>limitations into a separate section reduces the clarity). I think there is a separate stipulation that </FONT>
<BR><FONT SIZE=2>there is no representation as to the number of protocol exchanges it takes to perform a trace </FONT>
<BR><FONT SIZE=2>(other than permitting the trace originator to perform some measure of flow control by the protocol </FONT>
<BR><FONT SIZE=2>being designed to bound the number of responses a transaction will elicit; ideally 1 to 1, this also </FONT>
<BR><FONT SIZE=2>has DOS implications similar to ICMP smurf type attacks whereby the responses to a single </FONT>
<BR><FONT SIZE=2>message can be unbounded). You actually bring this up obliquely in the protocol requirements, but IMHO it </FONT>
<BR><FONT SIZE=2>should be expressed less prescriptively. </FONT>
</P>

<P><FONT SIZE=2>3) Is third party really a special case? Can I not instantiate an in-line trace using management </FONT>
<BR><FONT SIZE=2>protocols etc. and pull back the results. </FONT>
</P>

<P><FONT SIZE=2>4) the application &quot;displays&quot; tunnels (editorial nit)? are we really discussing how much information the </FONT>
<BR><FONT SIZE=2>application collects and reports on. The alternative interpretation is that the same amount of </FONT>
<BR><FONT SIZE=2>information is always collected, and somehow filtered during presentation. </FONT>
</P>

<P><FONT SIZE=2>4) When you say &quot;single hop&quot; or &quot;in detail&quot;, are you really saying &quot;this layer&quot; or &quot;constituent </FONT>
<BR><FONT SIZE=2>lower layer components&quot;? It could use clarification. </FONT>
</P>

<P><FONT SIZE=2>5) Are you sure the collected information includes round trip delay? It's not clear to me </FONT>
<BR><FONT SIZE=2>whether this is some pre-existing chunk of information just lying around, or where the trace </FONT>
<BR><FONT SIZE=2>transaction is expected to measure RTT on the fly for every hop and provide current view. </FONT>
</P>

<P><FONT SIZE=2>6) I think are more accurate statement is support any tunneling technology that is used between </FONT>
<BR><FONT SIZE=2>IP endpoints. Otherwise this is not a sustainable requirement. I am concerned, for example, that </FONT>
<BR><FONT SIZE=2>any intervening L2 or layer 2 and a half skewers the model. (e.g.. IP/PPP/L2TP, you can only </FONT>
<BR><FONT SIZE=2>reveal the PPP end points, or if you look at L2TP tunnel switches, you appear to be SOL) </FONT>
</P>

<P><FONT SIZE=2>7) This is the &quot;detail&quot; referred to earlier? Seems this one is subject to the routing </FONT>
<BR><FONT SIZE=2>requirements reported later. Might be easier simply to introduce that limitation here. </FONT>
</P>

<P><FONT SIZE=2>8) Is the expectation that the quality of information obtained from a control plane trace and a </FONT>
<BR><FONT SIZE=2>forwarding plane be comparable? Can you clarify what you mean by a control plane trace? I can see augmenting </FONT>
<BR><FONT SIZE=2>signalling protocols to faciliate this (e.g. LSP query I-D), but that does not fit into this discussion. </FONT>
</P>

<P><FONT SIZE=2>10) This seems to be overlapping with a solution framework. </FONT>
</P>

<P><FONT SIZE=2>11) Any intention of aligning TTL models with the terminology emerging elsewhere (pipe or uniform </FONT>
<BR><FONT SIZE=2>models?). </FONT>
</P>

<P><FONT SIZE=2>13) Don't quite grok the motivation. I plead ignorance ;-) </FONT>
</P>

<P><FONT SIZE=2>The protocol requirements section is actually rather prescriptive. There are specific requirements </FONT>
<BR><FONT SIZE=2>in there that end up as either application limitations or part of an applicability statement (e.g. routing </FONT>
<BR><FONT SIZE=2>requirements) or design guidelines. The rest shouldn't be in this document. </FONT>
</P>

<P><FONT SIZE=2>IMHO at the present time the document is not quite ready for &quot;prime time&quot;. </FONT>
</P>

<P><FONT SIZE=2>my two cents </FONT>
<BR><FONT SIZE=2>Dave </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C076.667D5BD0--

Delivery-date: Thu, 28 Feb 2002 08:26:43 -0800
From: "David Allan"<[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: [email-masked], Shahram Davari <[email-masked]>, "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 11:25:33 -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_01C1C074.8B602D80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Loa:

First observation is that this has gone on way too long. T'would be =
nice to
see the chairs or ADs make a decision as to whether consensus exists in =
one
direction or another.

Second, I would assume that objecting to adopting a draft as a wg =
document
is in it's own way part of the wg process, and I suspect I have a =
higher
probability of having my concerns addressed at this point in the =
pipeline.
I'm not expecting the document to be perfect, I may have further =
comments
later as may others, I simply have a differnt hurdle for "good enough" =
as a
WG starting point.

If the WG wants to adopt a requirements document that is reverse =
engineered
from a specific solution, why not skip the requirements step entirely? =
Seems
redundant.=20

Dave

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 11:06 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]; Shahram Davari; 'Randy Bush'; Cuevas, Enrique =
G,
> ALASO; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02
>=20
>=20
> In line
>=20
> David Allan wrote:
>=20
> > Loa:
> >=20
> > I guess my concern is fairly simple. There is an element of reverse =

> > engineering of requirements from a specific solution (GTTP)=20
> embodied in=20
> > this document.=20
>=20
>=20
> given that that is the case why not simple weed it out as a part of
> the normal wg-process, that is what a wg do, take some less than good
> enough to go to a wg last call and improve it to be good enough for
> the wg to have rough consensus on. and then ship it to the iesg, if =
it
> were bug free to start with it could go to the iesg directly
>=20
> i would understand if you said, not the wg should not work in this
> area. but i can't understand this is something we should work with
> but we have to wait until the doc (by some magic) is good enough. =
that
> is wg job
>=20
> /loa
> --=20
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> R=E5sundav=E4gen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           [email-masked]
> WWW             www.utfors.se
>=20
>=20

------_=_NextPart_001_01C1C074.8B602D80
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Loa:</FONT>
</P>

<P><FONT SIZE=3D2>First observation is that this has gone on way too =
long. T'would be nice to see the chairs or ADs make a decision as to =
whether consensus exists in one direction or another.</FONT></P>

<P><FONT SIZE=3D2>Second, I would assume that objecting to adopting a =
draft as a wg document is in it's own way part of the wg process, and I =
suspect I have a higher probability of having my concerns addressed at =
this point in the pipeline. I'm not expecting the document to be =
perfect, I may have further comments later as may others, I simply have =
a differnt hurdle for &quot;good enough&quot; as a WG starting =
point.</FONT></P>

<P><FONT SIZE=3D2>If the WG wants to adopt a requirements document that =
is reverse engineered from a specific solution, why not skip the =
requirements step entirely? Seems redundant. </FONT></P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Loa Andersson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, February 28, 2002 11:06 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Allan, David [CAR:NS00:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]; Shahram Davari; 'Randy =
Bush'; Cuevas, Enrique G,</FONT>
<BR><FONT SIZE=3D2>&gt; ALASO; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In line</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David Allan wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Loa:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I guess my concern is fairly simple. There =
is an element of reverse </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; engineering of requirements from a =
specific solution (GTTP) </FONT>
<BR><FONT SIZE=3D2>&gt; embodied in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this document. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; given that that is the case why not simple weed =
it out as a part of</FONT>
<BR><FONT SIZE=3D2>&gt; the normal wg-process, that is what a wg do, =
take some less than good</FONT>
<BR><FONT SIZE=3D2>&gt; enough to go to a wg last call and improve it =
to be good enough for</FONT>
<BR><FONT SIZE=3D2>&gt; the wg to have rough consensus on. and then =
ship it to the iesg, if it</FONT>
<BR><FONT SIZE=3D2>&gt; were bug free to start with it could go to the =
iesg directly</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; i would understand if you said, not the wg =
should not work in this</FONT>
<BR><FONT SIZE=3D2>&gt; area. but i can't understand this is something =
we should work with</FONT>
<BR><FONT SIZE=3D2>&gt; but we have to wait until the doc (by some =
magic) is good enough. that</FONT>
<BR><FONT SIZE=3D2>&gt; is wg job</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; /loa</FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Loa Andersson</FONT>
<BR><FONT SIZE=3D2>&gt; Chief Architect,</FONT>
<BR><FONT SIZE=3D2>&gt; Utfors Research, Architecture and Future Lab =
(URAX)</FONT>
<BR><FONT SIZE=3D2>&gt; Utfors AB</FONT>
<BR><FONT SIZE=3D2>&gt; R=E5sundav=E4gen 12</FONT>
<BR><FONT SIZE=3D2>&gt; Box 525, 169 29 Solna</FONT>
<BR><FONT SIZE=3D2>&gt; =
Office&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +46 8 5270 =
2000</FONT>
<BR><FONT SIZE=3D2>&gt; Office direct&nbsp;&nbsp; +46 8 5270 =
5038</FONT>
<BR><FONT SIZE=3D2>&gt; Mobile&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; +46 70 848 5038</FONT>
<BR><FONT SIZE=3D2>&gt; =
Email&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; =
WWW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; www.utfors.se</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C074.8B602D80--

Delivery-date: Thu, 28 Feb 2002 08:11:44 -0800
Date: Thu, 28 Feb 2002 11:10:58 -0500
To: Shahram Davari <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
Cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]

         Shahram,

         I have referred to those previous emails, which is why I asked you
to elaborate. I don't think that there have been any good points for
discounting Ron's approach presented therein (one was an open-ended
  reference to not meeting requirements and the other about not fitting
into an ITU framework that is irrelevant here in the IETF). I am curious about
what specific details in Ron's approach you think don't work and why.

         --Tom

>Please refer to previous emails by me and David Allan. Most of them are 
>listed there.
>
>-Shahram
>
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:[email-masked]]
> > Sent: Thursday, February 28, 2002 9:24 AM
> > To: Shahram Davari
> > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> >
> > >It has serious security, complexity, backward compatibility
> > and layer
> > >violation issues.
> >
> >          Can you elaborate on what you think these are?
> >
> >          --Tom
> >
> >
> >
> > >-Shahram
> > >
> > > > -----Original Message-----
> > > > From: Randy Bush [mailto:[email-masked]]
> > > > Sent: Thursday, February 28, 2002 8:56 AM
> > > > To: Shahram Davari
> > > > Cc: Cuevas, Enrique G, ALASO; [email-masked]
> > > > Subject: RE: draft-bonica-tunneltrace-02
> > > >
> > > >
> > > > > Are you suggesting that any draft that falls in the
> > > > charter, no matter how
> > > > > good or bad it is, MUST become a WG document?
> > > >
> > > > one can imagine extreme cases of any principle.  one can also
> > > > just get to
> > > > work.
> > > >
> > > > randy
> > > >
> >
> >
> >
> > --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of our time.
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Thu, 28 Feb 2002 08:08:01 -0800
Date: Thu, 28 Feb 2002 17:06:23 +0100
From: Loa Andersson <[email-masked]>
To: David Allan <[email-masked]>
CC: [email-masked], Shahram Davari <[email-masked]>, 'Randy Bush' <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

In line

David Allan wrote:

> Loa:
> 
> I guess my concern is fairly simple. There is an element of reverse 
> engineering of requirements from a specific solution (GTTP) embodied in 
> this document. 

given that that is the case why not simple weed it out as a part of
the normal wg-process, that is what a wg do, take some less than good
enough to go to a wg last call and improve it to be good enough for
the wg to have rough consensus on. and then ship it to the iesg, if it
were bug free to start with it could go to the iesg directly

i would understand if you said, not the wg should not work in this
area. but i can't understand this is something we should work with
but we have to wait until the doc (by some magic) is good enough. that
is wg job

/loa
-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

Delivery-date: Thu, 28 Feb 2002 07:51:10 -0800
From: Randy Bush <[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 07:50:58 -0800

> why is it that "seeing the requirements, concise, sustainable
> and justifiable" is something you need to do before the doc
> becomes a wg doc, not as an outcome of a wg discussion. it seems
> like you are putting constraints on becoming a wg doc, almost
> as if it were a wg last call

i keep trying to understand this too.  i suspect it is one of
  o does not understand ietf/wg process
  o really hates the idea so wants to block

if the former, then we should just be patient, we were all new once.

if the latter, then the issue seems to divide

  o are there substantive issues with the problem(s) the draft is
    attempting to address such that they are outside of the problem
    set of the wg charter?  (i have seen no one make this case)

  o are the technical problems with the draft that need to be addressed?
    probably so, as with almost all drafts.  that's why we take them up
    as wg items, so the wg can discuss and fix them.

randy

Delivery-date: Thu, 28 Feb 2002 07:48:13 -0800
From: Shahram Davari <[email-masked]>
To: "'Randy Bush'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 07:47:58 -0800

> > What is missing here is that the discussions with the 
> AUTHOR on the list
> > indicate that many of the concerns are being addressed in the next
> > revision. Can we simply agree that Ron's next version be 
> the basis for
> > this discussion.
> 
> yup.  that's what we do with a wg document.
> 
> randy
> 

No. This is what we do with a draft that wants to become a WG document.

-Shahram 

Delivery-date: Thu, 28 Feb 2002 07:46:59 -0800
From: "David Allan"<[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: [email-masked], Shahram Davari <[email-masked]>, "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 10:46:32 -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_01C1C06F.181AFFD0
Content-Type: text/plain;
	charset="iso-8859-1"

Loa:

I guess my concern is fairly simple. There is an element of reverse
engineering of requirements from a specific solution (GTTP) embodied in this
document. That to me somewhat disqualifies it as a reasonable starting point
for a WG activity regardless of one's opinions of GTTP and the intent to fix
problems associated with traceroute.  

Some of my comments were in the spirit of removing self fulfilling prophecy
from the requirements as IMHO they were not sustainable except to justify a
specific solution. That's not necessarily a healthy approach.

cheers
Dave

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 10:32 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]; Shahram Davari; 'Randy Bush'; Cuevas, Enrique G,
> ALASO; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02
> 
> 
> Dave,
> 
> again and allowing for agreeing to dis-agree :)
> 
> why is it that "seeing the requirements, concise, sustainable
> and justifiable" is something you need to do before the doc
> becomes a wg doc, not as an outcome of a wg discussion. it seems
> like you are putting constraints on becoming a wg doc, almost
> as if it were a wg last call
> 
> /Loa
> 
> 
> 
> David Allan wrote:
> 
> > Eric:
> > 
> > I guess you didn't read all the emails. I raised a number 
> of concerns 
> > and somewhere in all this noise had a useful and productive 
> dialog going 
> > with Ron which suggested (to me at least) most were on their way to 
> > resolution in the next version of the draft. Which then 
> IMHO would be a 
> > reasonable starting point for a WG document.
> > 
> > As this is a requirements document, I'm a little confused 
> as to how it 
> > consistutes a proposal against which solutions that can do 
> more should 
> > be evaluated. There seems to be a blurring of requirements and the 
> > candidate solution set in this discussion which should be 
> irrelevant in 
> > discussing a requirements document.
> > 
> > I'm simply interested in seeing the requirements, concise, 
> sustainable 
> > and justifiable.
> > 
> > cheers
> > Dave
> > 
> > 
> > 
> >  > -----Original Message-----
> >  > From: Eric Rosen [mailto:[email-masked]]
> >  > Sent: Thursday, February 28, 2002 9:59 AM
> >  > To: Shahram Davari
> >  > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
> >  > Subject: Re: draft-bonica-tunneltrace-02
> >  >
> >  >
> >  >
> >  > Shahram> It  has serious  security, complexity,  backward 
> >  > compatibility and
> >  > Shahram> layer violation issues.
> >  >
> >  > Tom> Can you elaborate on what you think these are?
> >  >
> >  > Shahram> Please refer to previous emails by me and David
> >  > Allan. Most of them
> >  > Shahram> are listed there. 
> >  >
> >  > I'm sorry, but  as far as I  can tell, those previous mails 
> >  > simply say that
> >  > (a)  the  proposed  solution doesn't  do  some  things  that
> >  > you  think  are
> >  > valuable,  and (b)  the proposed  solution doesn't  fit well 
> >  > into  some ITU
> >  > architecture.
> >  >
> >  > The  second  of  these  points  is  completely  irrelevant.  
> >  > The  first  is
> >  > irrelevant too, unless there is a reasonable alternative
> >  > proposed which does
> >  > more,  or if the  current proposal  doe so  little that  SPs
> >  > don't  think it
> >  > worthwhile.   The MPLS OAM  stuff you've  been pushing  is
> >  > not  a reasonable
> >  > alternative of  this sort  because (a)  it is MPLS-specific, 
> >  > and (b)  it is
> >  > already crystal  clear that it will not  be accepted in the 
> >  > IETF.  And it's
> >  > pretty clear  that a number of SPs  do think that what  the
> >  > current proposal
> >  > does is worthwhile.
> >  >
> >  > If  you can actually  cite specific  security issues  with
> >  > the  proposal, it
> >  > would be valuable to know about them.
> >  >
> >  > Suggestions for reducing complexity would  also be valuable,
> >  > if you have any
> >  > specific suggestions in that area.
> >  >
> >  > I don't understand what the backwards compatibility issue is,
> >  > as there is no
> >  > previous version to be compatible with.
> >  >
> >  > If you think there  are layer violation issues, then what you
> >  >  need to do is
> >  > exhibit the particular set of  specific problems that will
> >  > arise in practice
> >  > as a result of those violations.   If you cannot do this
> >  > without referencing
> >  > some arcane ITU  architecture document, then the natural 
> >  > conclusion is that
> >  > the  problem  is with  that  architecture's  layering  model,
> >  > not  with  the
> >  > proposal.
> >  >
> >  >
> >  >
> >  >
> >  >
> >  >
> > 
> 
> 
> -- 
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> Råsundavägen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           [email-masked]
> WWW             www.utfors.se
> 
> 

------_=_NextPart_001_01C1C06F.181AFFD0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Loa:</FONT>
</P>

<P><FONT SIZE=3D2>I guess my concern is fairly simple. There is an =
element of reverse engineering of requirements from a specific solution =
(GTTP) embodied in this document. That to me somewhat disqualifies it =
as a reasonable starting point for a WG activity regardless of one's =
opinions of GTTP and the intent to fix problems associated with =
traceroute.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Some of my comments were in the spirit of removing =
self fulfilling prophecy from the requirements as IMHO they were not =
sustainable except to justify a specific solution. That's not =
necessarily a healthy approach.</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Loa Andersson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, February 28, 2002 10:32 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Allan, David [CAR:NS00:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]; Shahram Davari; 'Randy =
Bush'; Cuevas, Enrique G,</FONT>
<BR><FONT SIZE=3D2>&gt; ALASO; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; again and allowing for agreeing to dis-agree =
:)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; why is it that &quot;seeing the requirements, =
concise, sustainable</FONT>
<BR><FONT SIZE=3D2>&gt; and justifiable&quot; is something you need to =
do before the doc</FONT>
<BR><FONT SIZE=3D2>&gt; becomes a wg doc, not as an outcome of a wg =
discussion. it seems</FONT>
<BR><FONT SIZE=3D2>&gt; like you are putting constraints on becoming a =
wg doc, almost</FONT>
<BR><FONT SIZE=3D2>&gt; as if it were a wg last call</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; /Loa</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David Allan wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Eric:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I guess you didn't read all the emails. I =
raised a number </FONT>
<BR><FONT SIZE=3D2>&gt; of concerns </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and somewhere in all this noise had a =
useful and productive </FONT>
<BR><FONT SIZE=3D2>&gt; dialog going </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with Ron which suggested (to me at least) =
most were on their way to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; resolution in the next version of the =
draft. Which then </FONT>
<BR><FONT SIZE=3D2>&gt; IMHO would be a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; reasonable starting point for a WG =
document.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; As this is a requirements document, I'm a =
little confused </FONT>
<BR><FONT SIZE=3D2>&gt; as to how it </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; consistutes a proposal against which =
solutions that can do </FONT>
<BR><FONT SIZE=3D2>&gt; more should </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be evaluated. There seems to be a blurring =
of requirements and the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; candidate solution set in this discussion =
which should be </FONT>
<BR><FONT SIZE=3D2>&gt; irrelevant in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; discussing a requirements document.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I'm simply interested in seeing the =
requirements, concise, </FONT>
<BR><FONT SIZE=3D2>&gt; sustainable </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and justifiable.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; cheers</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; From: Eric Rosen [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Sent: Thursday, February 28, =
2002 9:59 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; To: Shahram Davari</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Cc: 'Randy Bush'; Cuevas, =
Enrique G, ALASO; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Subject: Re: =
draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Shahram&gt; It&nbsp; has =
serious&nbsp; security, complexity,&nbsp; backward </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; compatibility and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Shahram&gt; layer violation =
issues.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Tom&gt; Can you elaborate on =
what you think these are?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Shahram&gt; Please refer to =
previous emails by me and David</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Allan. Most of them</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Shahram&gt; are listed there. =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; I'm sorry, but&nbsp; as far as =
I&nbsp; can tell, those previous mails </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; simply say that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; (a)&nbsp; the&nbsp; =
proposed&nbsp; solution doesn't&nbsp; do&nbsp; some&nbsp; things&nbsp; =
that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; you&nbsp; think&nbsp; =
are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; valuable,&nbsp; and (b)&nbsp; =
the proposed&nbsp; solution doesn't&nbsp; fit well </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; into&nbsp; some ITU</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; architecture.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; The&nbsp; second&nbsp; of&nbsp; =
these&nbsp; points&nbsp; is&nbsp; completely&nbsp; irrelevant.&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; The&nbsp; first&nbsp; is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; irrelevant too, unless there is =
a reasonable alternative</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; proposed which does</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; more,&nbsp; or if the&nbsp; =
current proposal&nbsp; doe so&nbsp; little that&nbsp; SPs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; don't&nbsp; think it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; worthwhile.&nbsp;&nbsp; The =
MPLS OAM&nbsp; stuff you've&nbsp; been pushing&nbsp; is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; not&nbsp; a reasonable</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; alternative of&nbsp; this =
sort&nbsp; because (a)&nbsp; it is MPLS-specific, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; and (b)&nbsp; it is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; already crystal&nbsp; clear =
that it will not&nbsp; be accepted in the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; IETF.&nbsp; And it's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; pretty clear&nbsp; that a =
number of SPs&nbsp; do think that what&nbsp; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; current proposal</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; does is worthwhile.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; If&nbsp; you can actually&nbsp; =
cite specific&nbsp; security issues&nbsp; with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; the&nbsp; proposal, it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; would be valuable to know about =
them.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Suggestions for reducing =
complexity would&nbsp; also be valuable,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; if you have any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; specific suggestions in that =
area.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; I don't understand what the =
backwards compatibility issue is,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; as there is no</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; previous version to be =
compatible with.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; If you think there&nbsp; are =
layer violation issues, then what you</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;&nbsp; need to do is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; exhibit the particular set =
of&nbsp; specific problems that will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; arise in practice</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; as a result of those =
violations.&nbsp;&nbsp; If you cannot do this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; without referencing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; some arcane ITU&nbsp; =
architecture document, then the natural </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; conclusion is that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; the&nbsp; problem&nbsp; is =
with&nbsp; that&nbsp; architecture's&nbsp; layering&nbsp; model,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; not&nbsp; with&nbsp; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; proposal.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Loa Andersson</FONT>
<BR><FONT SIZE=3D2>&gt; Chief Architect,</FONT>
<BR><FONT SIZE=3D2>&gt; Utfors Research, Architecture and Future Lab =
(URAX)</FONT>
<BR><FONT SIZE=3D2>&gt; Utfors AB</FONT>
<BR><FONT SIZE=3D2>&gt; R=E5sundav=E4gen 12</FONT>
<BR><FONT SIZE=3D2>&gt; Box 525, 169 29 Solna</FONT>
<BR><FONT SIZE=3D2>&gt; =
Office&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +46 8 5270 =
2000</FONT>
<BR><FONT SIZE=3D2>&gt; Office direct&nbsp;&nbsp; +46 8 5270 =
5038</FONT>
<BR><FONT SIZE=3D2>&gt; =
Mobile&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +46 70 848 =
5038</FONT>
<BR><FONT SIZE=3D2>&gt; =
Email&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; =
WWW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; www.utfors.se</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C06F.181AFFD0--

Delivery-date: Thu, 28 Feb 2002 07:40:44 -0800
Date: Thu, 28 Feb 2002 10:47:43 -0500
From: Srinivasa Datari <[email-masked]>
To: ccamp mailing list <[email-masked]>, [email-masked]
CC: [email-masked], [email-masked]
Subject: Link Summary Nack issue

Hi,

The current LMP draft (draft-ietf-ccamp-lmp-02.txt) provides an error_code
object to indicate what type of error is being reported in a LinkSummaryNack
message. The error being reported is generic and does not provide a correlation
between the included data link objects and their corresponding errors
respectively.

Problem: 
The LinkSummaryNack message points to a generic error, but does not point to
what is incorrect in a particular data link. This forces a reexamination of the
received data link objects and trying to figure out what is mismatched in each
of them.

Proposal:
Extend the Data Link object to contain an error_code entry. This can be similar
to the "error codes" defined in the draft and can point to multiple
inconsistencies in a particular data link.

Example: (from the draft, modified with the proposed change) 

14.13.  DATA_LINK Class 
    
   Class = 17.  
    
   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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Flags     |                   (Reserved)                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                   Local_Interface_Id (4 bytes)                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                   Remote_Interface_Id (4 bytes)               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                   ERROR CODE (4 bytes)                        | This field
is added
  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              

The above ERROR CODE field is added to all C-Types for the DATA_LINK Class.

Advantages:
Efficiency. Eliminates unnecessary comparisons at the receiving end; Helps
isolate the incorrect parameter in the data link object.

Comments welcome.

Thanks in advance,
Srini Datari.

Delivery-date: Thu, 28 Feb 2002 07:38:25 -0800
From: "Gibson, Mark" <[email-masked]>
To: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 15:31:34 -0000

As an impartial observer, there seems to be an obvious way forward for this
discussion.

In the first instance, draft-bonica-tunneltrace-02 can go through the usual
process in the wg meeting in Minneapolis and, subject to rough consensus,
become adopted as a solution for the cases that it solves.  I believe even
the proponents of the mplsoam scheme concede that the tunnel trace solution
has merit in certain circumstances.  [a point made by Dave Allan as I type]
Lets document that solution space and, if technically sufficient, advance
this draft such that tunnel trace can meet all the points in that space it
can.

In the second instance, lets define the specifics of the remainder of the
OAM problem space and work on some solutions that solve these problems.
>From memory, there were a number of individuals in the OAM BoF who, though a
minority were a large minority who believed something more substantive than
tunnel trace was needed, including a number of operators.  Presumably these
guys know what their requirements are.  As has been stated these are to a
large extent documented in the (sadly too new to get at for free) documents
Y.1711/Y.1710 but were in the now expired though surely google-able
draft-harrison... 

And finally, lets stop this "not invented here" mentality.  I'm not sure
that dismissing ITU documents because that's what they are does the IETF any
favours at all.  (c.f. the diatribe against the WAP representative at the
Adelaide open plenary).

Mark

 -----Original Message-----
From: 	Eric Rosen [mailto:[email-masked]] 
Sent:	28 February 2002 14:59
To:	Shahram Davari
Cc:	'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
Subject:	Re: draft-bonica-tunneltrace-02 

Shahram> It  has serious  security, complexity,  backward  compatibility and
Shahram> layer violation issues.

Tom> Can you elaborate on what you think these are? 

Shahram> Please refer to previous emails by me and David Allan. Most of them
Shahram> are listed there.  

I'm sorry, but  as far as I  can tell, those previous mails  simply say that
(a)  the  proposed  solution doesn't  do  some  things  that you  think  are
valuable,  and (b)  the proposed  solution doesn't  fit well  into  some ITU
architecture.

The  second  of  these  points  is  completely  irrelevant.   The  first  is
irrelevant too, unless there is a reasonable alternative proposed which does
more,  or if the  current proposal  doe so  little that  SPs don't  think it
worthwhile.   The MPLS OAM  stuff you've  been pushing  is not  a reasonable
alternative of  this sort  because (a)  it is MPLS-specific,  and (b)  it is
already crystal  clear that it will not  be accepted in the  IETF.  And it's
pretty clear  that a number of SPs  do think that what  the current proposal
does is worthwhile.

If  you can actually  cite specific  security issues  with the  proposal, it
would be valuable to know about them. 

Suggestions for reducing complexity would  also be valuable, if you have any
specific suggestions in that area. 

I don't understand what the backwards compatibility issue is, as there is no
previous version to be compatible with.

If you think there  are layer violation issues, then what you  need to do is
exhibit the particular set of  specific problems that will arise in practice
as a result of those violations.   If you cannot do this without referencing
some arcane ITU  architecture document, then the natural  conclusion is that
the  problem  is with  that  architecture's  layering  model, not  with  the
proposal.

Delivery-date: Thu, 28 Feb 2002 07:32:11 -0800
Date: Thu, 28 Feb 2002 16:31:39 +0100
From: Loa Andersson <[email-masked]>
To: David Allan <[email-masked]>
CC: [email-masked], Shahram Davari <[email-masked]>, 'Randy Bush' <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

Dave,

again and allowing for agreeing to dis-agree :)

why is it that "seeing the requirements, concise, sustainable
and justifiable" is something you need to do before the doc
becomes a wg doc, not as an outcome of a wg discussion. it seems
like you are putting constraints on becoming a wg doc, almost
as if it were a wg last call

/Loa

David Allan wrote:

> Eric:
> 
> I guess you didn't read all the emails. I raised a number of concerns 
> and somewhere in all this noise had a useful and productive dialog going 
> with Ron which suggested (to me at least) most were on their way to 
> resolution in the next version of the draft. Which then IMHO would be a 
> reasonable starting point for a WG document.
> 
> As this is a requirements document, I'm a little confused as to how it 
> consistutes a proposal against which solutions that can do more should 
> be evaluated. There seems to be a blurring of requirements and the 
> candidate solution set in this discussion which should be irrelevant in 
> discussing a requirements document.
> 
> I'm simply interested in seeing the requirements, concise, sustainable 
> and justifiable.
> 
> cheers
> Dave
> 
> 
> 
>  > -----Original Message-----
>  > From: Eric Rosen [mailto:[email-masked]]
>  > Sent: Thursday, February 28, 2002 9:59 AM
>  > To: Shahram Davari
>  > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
>  > Subject: Re: draft-bonica-tunneltrace-02
>  >
>  >
>  >
>  > Shahram> It  has serious  security, complexity,  backward 
>  > compatibility and
>  > Shahram> layer violation issues.
>  >
>  > Tom> Can you elaborate on what you think these are?
>  >
>  > Shahram> Please refer to previous emails by me and David
>  > Allan. Most of them
>  > Shahram> are listed there. 
>  >
>  > I'm sorry, but  as far as I  can tell, those previous mails 
>  > simply say that
>  > (a)  the  proposed  solution doesn't  do  some  things  that
>  > you  think  are
>  > valuable,  and (b)  the proposed  solution doesn't  fit well 
>  > into  some ITU
>  > architecture.
>  >
>  > The  second  of  these  points  is  completely  irrelevant.  
>  > The  first  is
>  > irrelevant too, unless there is a reasonable alternative
>  > proposed which does
>  > more,  or if the  current proposal  doe so  little that  SPs
>  > don't  think it
>  > worthwhile.   The MPLS OAM  stuff you've  been pushing  is
>  > not  a reasonable
>  > alternative of  this sort  because (a)  it is MPLS-specific, 
>  > and (b)  it is
>  > already crystal  clear that it will not  be accepted in the 
>  > IETF.  And it's
>  > pretty clear  that a number of SPs  do think that what  the
>  > current proposal
>  > does is worthwhile.
>  >
>  > If  you can actually  cite specific  security issues  with
>  > the  proposal, it
>  > would be valuable to know about them.
>  >
>  > Suggestions for reducing complexity would  also be valuable,
>  > if you have any
>  > specific suggestions in that area.
>  >
>  > I don't understand what the backwards compatibility issue is,
>  > as there is no
>  > previous version to be compatible with.
>  >
>  > If you think there  are layer violation issues, then what you
>  >  need to do is
>  > exhibit the particular set of  specific problems that will
>  > arise in practice
>  > as a result of those violations.   If you cannot do this
>  > without referencing
>  > some arcane ITU  architecture document, then the natural 
>  > conclusion is that
>  > the  problem  is with  that  architecture's  layering  model,
>  > not  with  the
>  > proposal.
>  >
>  >
>  >
>  >
>  >
>  >
> 

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

Delivery-date: Thu, 28 Feb 2002 07:20:09 -0800
From: Randy Bush <[email-masked]>
To: Shahram Davari <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 07:19:41 -0800

> What is missing here is that the discussions with the AUTHOR on the list
> indicate that many of the concerns are being addressed in the next
> revision. Can we simply agree that Ron's next version be the basis for
> this discussion.

yup.  that's what we do with a wg document.

randy

Delivery-date: Thu, 28 Feb 2002 07:10:20 -0800
From: "David Allan"<[email-masked]>
To: [email-masked], Shahram Davari <[email-masked]>
Cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02 
Date: Thu, 28 Feb 2002 10:09:34 -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_01C1C069.EE320880
Content-Type: text/plain;
	charset="iso-8859-1"

Eric:

I guess you didn't read all the emails. I raised a number of concerns and
somewhere in all this noise had a useful and productive dialog going with
Ron which suggested (to me at least) most were on their way to resolution in
the next version of the draft. Which then IMHO would be a reasonable
starting point for a WG document.

As this is a requirements document, I'm a little confused as to how it
consistutes a proposal against which solutions that can do more should be
evaluated. There seems to be a blurring of requirements and the candidate
solution set in this discussion which should be irrelevant in discussing a
requirements document. 

I'm simply interested in seeing the requirements, concise, sustainable and
justifiable.

cheers
Dave

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 9:59 AM
> To: Shahram Davari
> Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02 
> 
> 
> 
> Shahram> It  has serious  security, complexity,  backward  
> compatibility and
> Shahram> layer violation issues.
> 
> Tom> Can you elaborate on what you think these are? 
> 
> Shahram> Please refer to previous emails by me and David 
> Allan. Most of them
> Shahram> are listed there.  
> 
> I'm sorry, but  as far as I  can tell, those previous mails  
> simply say that
> (a)  the  proposed  solution doesn't  do  some  things  that 
> you  think  are
> valuable,  and (b)  the proposed  solution doesn't  fit well  
> into  some ITU
> architecture.
> 
> The  second  of  these  points  is  completely  irrelevant.   
> The  first  is
> irrelevant too, unless there is a reasonable alternative 
> proposed which does
> more,  or if the  current proposal  doe so  little that  SPs 
> don't  think it
> worthwhile.   The MPLS OAM  stuff you've  been pushing  is 
> not  a reasonable
> alternative of  this sort  because (a)  it is MPLS-specific,  
> and (b)  it is
> already crystal  clear that it will not  be accepted in the  
> IETF.  And it's
> pretty clear  that a number of SPs  do think that what  the 
> current proposal
> does is worthwhile.
> 
> If  you can actually  cite specific  security issues  with 
> the  proposal, it
> would be valuable to know about them. 
> 
> Suggestions for reducing complexity would  also be valuable, 
> if you have any
> specific suggestions in that area. 
> 
> I don't understand what the backwards compatibility issue is, 
> as there is no
> previous version to be compatible with.
> 
> If you think there  are layer violation issues, then what you 
>  need to do is
> exhibit the particular set of  specific problems that will 
> arise in practice
> as a result of those violations.   If you cannot do this 
> without referencing
> some arcane ITU  architecture document, then the natural  
> conclusion is that
> the  problem  is with  that  architecture's  layering  model, 
> not  with  the
> proposal.
> 
> 
> 
> 
> 
> 

------_=_NextPart_001_01C1C069.EE320880
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02 </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Eric:</FONT>
</P>

<P><FONT SIZE=3D2>I guess you didn't read all the emails. I raised a =
number of concerns and somewhere in all this noise had a useful and =
productive dialog going with Ron which suggested (to me at least) most =
were on their way to resolution in the next version of the draft. Which =
then IMHO would be a reasonable starting point for a WG =
document.</FONT></P>

<P><FONT SIZE=3D2>As this is a requirements document, I'm a little =
confused as to how it consistutes a proposal against which solutions =
that can do more should be evaluated. There seems to be a blurring of =
requirements and the candidate solution set in this discussion which =
should be irrelevant in discussing a requirements document. </FONT></P>

<P><FONT SIZE=3D2>I'm simply interested in seeing the requirements, =
concise, sustainable and justifiable.</FONT>
</P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Eric Rosen [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, February 28, 2002 9:59 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Shahram Davari</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: draft-bonica-tunneltrace-02 =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Shahram&gt; It&nbsp; has serious&nbsp; =
security, complexity,&nbsp; backward&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; compatibility and</FONT>
<BR><FONT SIZE=3D2>&gt; Shahram&gt; layer violation issues.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Tom&gt; Can you elaborate on what you think =
these are? </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Shahram&gt; Please refer to previous emails by =
me and David </FONT>
<BR><FONT SIZE=3D2>&gt; Allan. Most of them</FONT>
<BR><FONT SIZE=3D2>&gt; Shahram&gt; are listed there.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm sorry, but&nbsp; as far as I&nbsp; can =
tell, those previous mails&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; simply say that</FONT>
<BR><FONT SIZE=3D2>&gt; (a)&nbsp; the&nbsp; proposed&nbsp; solution =
doesn't&nbsp; do&nbsp; some&nbsp; things&nbsp; that </FONT>
<BR><FONT SIZE=3D2>&gt; you&nbsp; think&nbsp; are</FONT>
<BR><FONT SIZE=3D2>&gt; valuable,&nbsp; and (b)&nbsp; the =
proposed&nbsp; solution doesn't&nbsp; fit well&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; into&nbsp; some ITU</FONT>
<BR><FONT SIZE=3D2>&gt; architecture.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The&nbsp; second&nbsp; of&nbsp; these&nbsp; =
points&nbsp; is&nbsp; completely&nbsp; irrelevant.&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; The&nbsp; first&nbsp; is</FONT>
<BR><FONT SIZE=3D2>&gt; irrelevant too, unless there is a reasonable =
alternative </FONT>
<BR><FONT SIZE=3D2>&gt; proposed which does</FONT>
<BR><FONT SIZE=3D2>&gt; more,&nbsp; or if the&nbsp; current =
proposal&nbsp; doe so&nbsp; little that&nbsp; SPs </FONT>
<BR><FONT SIZE=3D2>&gt; don't&nbsp; think it</FONT>
<BR><FONT SIZE=3D2>&gt; worthwhile.&nbsp;&nbsp; The MPLS OAM&nbsp; =
stuff you've&nbsp; been pushing&nbsp; is </FONT>
<BR><FONT SIZE=3D2>&gt; not&nbsp; a reasonable</FONT>
<BR><FONT SIZE=3D2>&gt; alternative of&nbsp; this sort&nbsp; because =
(a)&nbsp; it is MPLS-specific,&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; and (b)&nbsp; it is</FONT>
<BR><FONT SIZE=3D2>&gt; already crystal&nbsp; clear that it will =
not&nbsp; be accepted in the&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; IETF.&nbsp; And it's</FONT>
<BR><FONT SIZE=3D2>&gt; pretty clear&nbsp; that a number of SPs&nbsp; =
do think that what&nbsp; the </FONT>
<BR><FONT SIZE=3D2>&gt; current proposal</FONT>
<BR><FONT SIZE=3D2>&gt; does is worthwhile.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If&nbsp; you can actually&nbsp; cite =
specific&nbsp; security issues&nbsp; with </FONT>
<BR><FONT SIZE=3D2>&gt; the&nbsp; proposal, it</FONT>
<BR><FONT SIZE=3D2>&gt; would be valuable to know about them. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Suggestions for reducing complexity would&nbsp; =
also be valuable, </FONT>
<BR><FONT SIZE=3D2>&gt; if you have any</FONT>
<BR><FONT SIZE=3D2>&gt; specific suggestions in that area. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I don't understand what the backwards =
compatibility issue is, </FONT>
<BR><FONT SIZE=3D2>&gt; as there is no</FONT>
<BR><FONT SIZE=3D2>&gt; previous version to be compatible with.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If you think there&nbsp; are layer violation =
issues, then what you </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; need to do is</FONT>
<BR><FONT SIZE=3D2>&gt; exhibit the particular set of&nbsp; specific =
problems that will </FONT>
<BR><FONT SIZE=3D2>&gt; arise in practice</FONT>
<BR><FONT SIZE=3D2>&gt; as a result of those violations.&nbsp;&nbsp; If =
you cannot do this </FONT>
<BR><FONT SIZE=3D2>&gt; without referencing</FONT>
<BR><FONT SIZE=3D2>&gt; some arcane ITU&nbsp; architecture document, =
then the natural&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; conclusion is that</FONT>
<BR><FONT SIZE=3D2>&gt; the&nbsp; problem&nbsp; is with&nbsp; =
that&nbsp; architecture's&nbsp; layering&nbsp; model, </FONT>
<BR><FONT SIZE=3D2>&gt; not&nbsp; with&nbsp; the</FONT>
<BR><FONT SIZE=3D2>&gt; proposal.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C069.EE320880--

Delivery-date: Thu, 28 Feb 2002 06:59:15 -0800
To: Shahram Davari <[email-masked]>
cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02 
Reply-To: [email-masked]
Date: Thu, 28 Feb 2002 09:58:32 -0500
From: Eric Rosen <[email-masked]>

Shahram> It  has serious  security, complexity,  backward  compatibility and
Shahram> layer violation issues.

Tom> Can you elaborate on what you think these are? 

Shahram> Please refer to previous emails by me and David Allan. Most of them
Shahram> are listed there.  

I'm sorry, but  as far as I  can tell, those previous mails  simply say that
(a)  the  proposed  solution doesn't  do  some  things  that you  think  are
valuable,  and (b)  the proposed  solution doesn't  fit well  into  some ITU
architecture.

The  second  of  these  points  is  completely  irrelevant.   The  first  is
irrelevant too, unless there is a reasonable alternative proposed which does
more,  or if the  current proposal  doe so  little that  SPs don't  think it
worthwhile.   The MPLS OAM  stuff you've  been pushing  is not  a reasonable
alternative of  this sort  because (a)  it is MPLS-specific,  and (b)  it is
already crystal  clear that it will not  be accepted in the  IETF.  And it's
pretty clear  that a number of SPs  do think that what  the current proposal
does is worthwhile.

If  you can actually  cite specific  security issues  with the  proposal, it
would be valuable to know about them. 

Suggestions for reducing complexity would  also be valuable, if you have any
specific suggestions in that area. 

I don't understand what the backwards compatibility issue is, as there is no
previous version to be compatible with.

If you think there  are layer violation issues, then what you  need to do is
exhibit the particular set of  specific problems that will arise in practice
as a result of those violations.   If you cannot do this without referencing
some arcane ITU  architecture document, then the natural  conclusion is that
the  problem  is with  that  architecture's  layering  model, not  with  the
proposal.

Delivery-date: Thu, 28 Feb 2002 06:59:12 -0800
From: Shahram Davari <[email-masked]>
To: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 06:57:55 -0800

What is missing here is that the discussions with the AUTHOR on the list indicate that many of the concerns are being addressed in the next revision. Can we simply agree that Ron's next version be the basis for this discussion. 

-Shahram

> -----Original Message-----
> From: Shahram Davari 
> Sent: Thursday, February 28, 2002 9:25 AM
> To: 'Thomas D. Nadeau'
> Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> Please refer to previous emails by me and David Allan. Most 
> of them are listed there.
> 
> -Shahram
> 
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:[email-masked]]
> > Sent: Thursday, February 28, 2002 9:24 AM
> > To: Shahram Davari
> > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02
> > 
> > 
> > 
> > >It has serious security, complexity, backward compatibility 
> > and layer 
> > >violation issues.
> > 
> >          Can you elaborate on what you think these are?
> > 
> >          --Tom
> > 
> > 
> > 
> > >-Shahram
> > >
> > > > -----Original Message-----
> > > > From: Randy Bush [mailto:[email-masked]]
> > > > Sent: Thursday, February 28, 2002 8:56 AM
> > > > To: Shahram Davari
> > > > Cc: Cuevas, Enrique G, ALASO; [email-masked]
> > > > Subject: RE: draft-bonica-tunneltrace-02
> > > >
> > > >
> > > > > Are you suggesting that any draft that falls in the
> > > > charter, no matter how
> > > > > good or bad it is, MUST become a WG document?
> > > >
> > > > one can imagine extreme cases of any principle.  one can also
> > > > just get to
> > > > work.
> > > >
> > > > randy
> > > >
> > 
> > 
> > 
> > --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of our time. 
> > 
> 

Delivery-date: Thu, 28 Feb 2002 06:25:46 -0800
From: Shahram Davari <[email-masked]>
To: "'Thomas D. Nadeau'" <[email-masked]>
Cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 06:25:28 -0800

Please refer to previous emails by me and David Allan. Most of them are listed there.

-Shahram

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 9:24 AM
> To: Shahram Davari
> Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> 
> >It has serious security, complexity, backward compatibility 
> and layer 
> >violation issues.
> 
>          Can you elaborate on what you think these are?
> 
>          --Tom
> 
> 
> 
> >-Shahram
> >
> > > -----Original Message-----
> > > From: Randy Bush [mailto:[email-masked]]
> > > Sent: Thursday, February 28, 2002 8:56 AM
> > > To: Shahram Davari
> > > Cc: Cuevas, Enrique G, ALASO; [email-masked]
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > > > Are you suggesting that any draft that falls in the
> > > charter, no matter how
> > > > good or bad it is, MUST become a WG document?
> > >
> > > one can imagine extreme cases of any principle.  one can also
> > > just get to
> > > work.
> > >
> > > randy
> > >
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 

Delivery-date: Thu, 28 Feb 2002 06:24:24 -0800
Date: Thu, 28 Feb 2002 09:23:32 -0500
To: Shahram Davari <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
Cc: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]

>It has serious security, complexity, backward compatibility and layer 
>violation issues.

         Can you elaborate on what you think these are?

         --Tom

>-Shahram
>
> > -----Original Message-----
> > From: Randy Bush [mailto:[email-masked]]
> > Sent: Thursday, February 28, 2002 8:56 AM
> > To: Shahram Davari
> > Cc: Cuevas, Enrique G, ALASO; [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> > > Are you suggesting that any draft that falls in the
> > charter, no matter how
> > > good or bad it is, MUST become a WG document?
> >
> > one can imagine extreme cases of any principle.  one can also
> > just get to
> > work.
> >
> > randy
> >

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Thu, 28 Feb 2002 06:17:38 -0800
From: Randy Bush <[email-masked]>
To: Shahram Davari <[email-masked]>
Cc: "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 06:16:47 -0800

> Then I guess this draft is one of those extreme cases. It has serious
> security, complexity, backward compatibility and layer violation issues.

opinions seem to vary.  in which case, i guess it may not be so extreme.

randy

Delivery-date: Thu, 28 Feb 2002 06:03:23 -0800
From: Shahram Davari <[email-masked]>
To: "'Randy Bush'" <[email-masked]>
Cc: "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 06:02:51 -0800

Then I guess this draft is one of those extreme cases. It has serious security, complexity, backward compatibility and layer violation issues.

-Shahram

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 8:56 AM
> To: Shahram Davari
> Cc: Cuevas, Enrique G, ALASO; [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> > Are you suggesting that any draft that falls in the 
> charter, no matter how
> > good or bad it is, MUST become a WG document?
> 
> one can imagine extreme cases of any principle.  one can also 
> just get to
> work.
> 
> randy
> 

Delivery-date: Thu, 28 Feb 2002 05:56:15 -0800
From: Randy Bush <[email-masked]>
To: Shahram Davari <[email-masked]>
Cc: "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 05:55:58 -0800

> Are you suggesting that any draft that falls in the charter, no matter how
> good or bad it is, MUST become a WG document?

one can imagine extreme cases of any principle.  one can also just get to
work.

randy

Delivery-date: Thu, 28 Feb 2002 05:55:56 -0800
From: Shahram Davari <[email-masked]>
To: "'Randy Bush'" <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 05:54:04 -0800

Are you suggesting that any draft that falls in the charter, no matter how good or bad it is, MUST become a WG document?

-Shahram

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2002 7:45 PM
> To: Cuevas, Enrique G, ALASO
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> > (a) it should be a WG document?
> > (b) it's good stuff, but not ready?
> > (c) we need a new start?
> > 
> > With all the issues raised by Neil, Sharham, Dave, and 
> others the document
> > is definitely not ready.
> 
> in most wgs, if it is not a wg document we don't discuss it in the wg.
> 
> if it is ready, we give it to the iesg.
> 
> wgs exist to make in-charter documents ready.  otherwise the 
> iesg would
> just process individual submissions.
> 
> randy
> 

Delivery-date: Thu, 28 Feb 2002 04:07:36 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 28 Feb 2002 12:02:14 -0000

Hi Ping....please see my response below.

regards, Neil

>
> Here is what I think on auto-detection and atuo-handling:
> 
> 1. The operators should have the option to turn on some "ping-like" 
> function on the suspicious LSPs at ingress LSRs. These LSPs will be 
> queries periodically. It's important to make sure that this function 
> won't introduce too much overhead.
NH=> Well I agree that is 1 option, and for some operators/applications this
may be good enough.  However it has some limitations:
-	because you don't know a priori where faults will occur you either
(i) have to turn it on for all important LSPs or (ii) revert back to using
the customer as the defect detection tool;
-	it can't detect/diagnose defects other than simple breaks (these
should be easy to spot anyway IMO);
-	it takes no consequent actions.....like suppressing alarms in client
layers, or protecting customer traffic (ie squelching traffic) if there is
traffic leakage observed, etc;
-	there are no well-defined/agreed defects (and no agreed consequent
action as noted above), and as a consequence no well defined availability
metrics....and as a further consequence no possibility to relate any QoS
metrics gathered to available time.  This has both interworking implications
and means operators/customers have no agreed base for availability/QoS SLAs;
-	LSP-ping only works with RSVP-TE....we need a solution that is
control-plane agnostic (inc case of no control-plane) and client layer
agnostic (ie XoverMPLS). 

Can I ask if you have ever read Y.1710/1711?  All the above is catered for
by very simple means.  A trivial keepalive flow (CV) that contains the LSP
source address....and an FDI, sent upwards of failure, to tell higher layers
'failure lower down so don't raise alarms'.  There is also a BDI in case you
want to tell the upstream end of a downstream problem, eg unidirectional
monitoring of availability of a bi-directional LSP or for invoking 1/M:1/N
prot-sw.  And that's about it......so Y.1711 is generic, extremely powerful
and comprehensive and yet very simple.
> 
> 2. If a LSP is in trouble, it would be nice to have the "traceroute" 
> function kick in automatically. Eventually, the trouble spot can be 
> located and reported.
NH=> Well I think its more than this as noted above.  Trace-Route is a 'nice
to have' ad hoc diagnostic tool.  I looked at how to do it for MPLS sometime
ago (and I think I have a good solution) but I put it on a back-burner
because defect detection/handling and how to measure availability needed
sorting 1st....I can now return to the area of enhanced ad hoc tools.  I
(and my Ops people) also want to define a P-flow so we can turn-on some more
detailed QoS metric collection, so I intend to look at that also.
<snipped NH>

Delivery-date: Thu, 28 Feb 2002 04:07:33 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-mannie-ccamp-gmpls-sonet-sdh-ospf-isis-00.txt
Date: Thu, 28 Feb 2002 07:06:32 -0500

--NextPart

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

	Title		: GMPLS Extensions to OSPF and IS-IS for SONET/SDH 
                          Control
	Author(s)	: E. Mannie, D. Papadimitriou
	Filename	: draft-mannie-ccamp-gmpls-sonet-sdh-ospf-isis-00.txt
	Pages		: 13
	Date		: 27-Feb-02
	
This document discusses and explains some of the extensions required
in existing IGP routing protocols to support sub-sequent signalling
for dynamically established SONET/SDH circuits using GMPLS-based
control plane architecture [GMPLS-ARCH]. In particular, it specifies
the GMPLS routing extensions to OSPF and IS-IS routing protocols for
SONET/SDH networks using [GMPLS-RTG] as guideline.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-sonet-sdh-ospf-isis-00.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-mannie-ccamp-gmpls-sonet-sdh-ospf-isis-00.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-mannie-ccamp-gmpls-sonet-sdh-ospf-isis-00.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-mannie-ccamp-gmpls-sonet-sdh-ospf-isis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mannie-ccamp-gmpls-sonet-sdh-ospf-isis-00.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, 27 Feb 2002 19:02:28 -0800
content-class: urn:content-classes:message
Subject: RE: WG (rough) consensus) [was RE: WG document status]
Date: Wed, 27 Feb 2002 21:58:06 -0500
From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>, "Ben Mack-Crane" <[email-masked]>, <[email-masked]>

Thank you Bert:

Kireeti> WG Last Call for this draft is over.  And over.  And over.  =
It's
Kireeti> DONE.  Consensus was rather rough.  That's a pity -- it would =
be
Kireeti> nice to make everyone happy.

Jerry> Yes, last call was *declared* over.

Kireeti> That's what a chair is supposed to do.  Check with the ADs.

Bert> I support that a WG chair(s) has(ve) the responsibility to figure =
out what
Bert> the (rough, sometimes even very rough) consensus is. In fact, =
RFC2418,
Bert> sect 3.3 explains this.
Bert> It is great/best if he (they) declare(s) that on the mailing list, =

Bert> so that everybody can see (and hopefully understand) exactly what=20
Bert> the WG chair will report to the AD (and thus IESG) as being the WG
Bert> (very rough or rough) consensus.
Bert> When/if the WG chair(s) DO make such a declaration, and a WG =
member feels
Bert> that this is NOT true, then you can raise that to the mailing list =
or
Bert> just to the WG chairs and copy ADs.

The point I tried to make was that several experts on SONET/SDH had many =
times commented on the gen-signaling draft (during the 2 or 3 last =
calls, over a period of many months) about the LSP encoding type re =
SONET/SDH.  The points made are closely related to the 'SONET/SDH =
labels' issue now being discussed.  Even today Zhi and Deborah =
elaborated on the relationship, but the issue raised is unanswered and =
unresolved.  Rather than *declaring* the issue resolved, it seems we =
could use the rough consensus reached on the SONET/SDH labels to also =
resolve the issue on LSP encoding type.

Thanks,
Jerry Ash

Delivery-date: Wed, 27 Feb 2002 17:04:13 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Cc: Ben Mack-Crane <[email-masked]>, [email-masked]
Subject: FW: WG (rough) consensus) [was RE: WG document status]
Date: Thu, 28 Feb 2002 02:02:45 +0100

Kireeti writes:
> > > WG Last Call for this draft is over.  And over.  And over.  It's
> > > DONE.  Consensus was rather rough.  That's a pity -- it would be
> > > nice to make everyone happy.
> > 
> > Yes, last call was *declared* over.
> 
> That's what a chair is supposed to do.  Check with the ADs.
> 
I support that a WG chair(s) has(ve) the responsibility to figure out what
the (rough, sometimes even very rough) consensus is. In fact, RFC2418,
sect 3.3 explains this.
It is great/best if he (they) declare(s) that on the mailing list, 
so that everybody can see (and hopefully understand) exactly what 
the WG chair will report to the AD (and thus IESG) as being the WG
(very rough or rough) consensus.

When/if the WG chair(s) DO make such a declaration, and a WG member feels
that this is NOT true, then you can raise that to the mailing list or
just to the WG chairs and copy ADs.

Be prepared to point out exactly why you think the chair is wrong and
what you think the (rough) consensus is and why. WG chairs will answer,
and if you cannot get to agreement with WG chair(s), then you can ask
ADs for their opinion (this is the escalation stage).
For exact escalation procedure, see RFC 2026 sect 6.5

So... this WG has been (re-)discussing many topics many times.
I am very happy to see that the chair(s) are now trying to gauge 
(rough) consensus on some topics. I would hope everybody tries to 
help to reach (rough) consensus. 

So that also means that if you have serious concern that the WG chairs
are NOT reading the (rough) consensus properly, then NOW is the time
to speak up and explain why. Not recycle the whole detailed discussions.
Explain what you think the (rough) consensus is in your view and why.

Bert and Scott
speaking as ADs.

Delivery-date: Wed, 27 Feb 2002 16:45:28 -0800
From: Randy Bush <[email-masked]>
To: "Cuevas, Enrique G, ALASO" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 27 Feb 2002 16:44:50 -0800

> (a) it should be a WG document?
> (b) it's good stuff, but not ready?
> (c) we need a new start?
> 
> With all the issues raised by Neil, Sharham, Dave, and others the document
> is definitely not ready.

in most wgs, if it is not a wg document we don't discuss it in the wg.

if it is ready, we give it to the iesg.

wgs exist to make in-charter documents ready.  otherwise the iesg would
just process individual submissions.

randy

Delivery-date: Wed, 27 Feb 2002 15:54:54 -0800
content-class: urn:content-classes:message
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 27 Feb 2002 18:51:21 -0500
From: "Cuevas, Enrique G, ALASO" <[email-masked]>
To: <[email-masked]>

(a) it should be a WG document?
(b) it's good stuff, but not ready?
(c) we need a new start?

With all the issues raised by Neil, Sharham, Dave, and others the =
document is definitely not ready.
I vote for (b)

Enrique
_______________
[email-masked]

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Sunday, February 24, 2002 7:47 PM
To: David Allan
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: draft-bonica-tunneltrace-02

Let me say a few words:

1) There was good support for this work (the requirements doc) to
   be a WG document at a previous IETF.  It is a good thing to
   follow up and check what the mailing list thinks, as not everyone
   attends IETFs.

2) It is interesting that no one brought up the issue of whether this
   work (tunnel tracing) is in the charter or not at the meeting.
   There are those who think the charter isn't explicit enough.  I'll
   talk to the ADs and see (a) if they think that this *is* in the
   charter; (b) if not, are they willing to take it to the IESG and
   add it to the charter.

   My input on this (as WG chair) is that CCAMP is all about tunnels,
   and a protocol to debug and test tunnels is well within scope, even
   if not called out explicitly.

   Note that the charter is *not* subject to WG consensus, nor even
   the WG chairs.  The IESG (and IAB?) are solely responsible,
   although the WG and chairs can suggest changes.

3) A document that is "in the right spirit" can become a WG document,
   even if there are disagreements about some details, and even
   "fundamental" questions.  Note that "fundamental" is often
   subjective.

I would like to have the mailing list equivalent of a 'show of hands'
regarding this draft.  Do you think:
(a) it should be a WG document?
(b) it's good stuff, but not ready?
(c) we need a new start?

Please send in your opinions with one of the above up top.  Any
detailed reasoning you have for your opinion may follow.

Thanks!
Kireeti.

Delivery-date: Wed, 27 Feb 2002 11:58:10 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 27 Feb 2002 19:55:12 -0000

Hi Ping,  I've tried to be brief but sufficiently comprehensive.  Hope this
helps you understand our perspective on this.
regards, Neil
> > 
> > -	a trail-tracing function is one diagnostic tool which 
> is 'desirable'
> > to help operations people verify routing......it is not the 
> only 'desirable'
> > diagnostic tool required.  Moreover, it is not a defect 
> detection/handling
> > tool, which is an 'essential' function IMO.  I hardly think 
> it appropriate
> > that in all the cases we want to use IP/MPLS technologies 
> to expect the
> > customer to act as the defect detection mechanism.  I see this as
> > particularly ironic and inconsistent given that in the 
> GMPLS work it is
> > taken for granted that the defect detection/handling 
> mechanisms relevant to
> > the traffic/data-plane of a L1 layer network (eg SDH) must indeed be
> > present....such as correct framing, BIP-X violations, trail-trace
> > violations, FDI to suppress higher client layer alarms, etc. ...
> 
> 
> Neil,
> 
> Just curious, what's wrong with using IP "tools" to detect data-plane 
> LSP problems?  That's how we have been doing things in the 
> Internet for 
> years.
NH=> I assume you are meaning wrt MPLS rather than GMPLS?.....as latter (eg
SDH, OTN) do have the right things specified wrt data-plane....again because
its something operators have been doing for years in such bulk-transport
networks.  The tools one invokes depends on the service application, however
the basic network principles are generic (I'll come back on that shortly).
Using MPLS for VPNs or supporting XoverMPLS can have quite different
customer/operational SLA expectancies than using MPLS for mass-market
BE/Internet service.  I know the ping tools have been around for years and
that's why we'd like something better now....Peter Willis, who represented
BT at the last mtg/BoF if you recall, used to operate our IP networks has
vast experience of the limitations of such tools.  I am sure Peter would be
very happy to share his views with you on the limitation of such tools if
you'd like some time.

If you get chance please have a read of Y.1710, the principles/requirements
therein offer a good guidance to what operators want to see addressed (or at
least operators like BT, NTT, AT&T, etc...I believe there was a list of
those operators supporting these requirements given at the last mtg/BoF).
But in summary:

The major drivers for operators are:
-	reduce Opex costs by providing auto defect (i) detection (ii)
handling (ii) diagnostics;
-	seek to improve the customer service/experience as/where
needed....and certainly don't expect to use customers as defect detectors;
-	be able to offer robust/measureable availabilty and QoS SLAs to
customers as/where needed;
-	provide a trigger mechanism for prot-sw as/where needed.

To address these drivers we need to (and there is an ordering requirement
here):
-	1st identify all types of defect;
-	2nd identify a mechanism(s) that will automatically detect the
defects, specify their entry/exit criteria, specify the appropriate
consequent actions (which may vary between different defects)....items for
consideration wrt consequent actions are:
	* sending FDI to higher layers to suppress alarm storms (also works
other way round, ie L1 FDI suppresses MPLS alarms....this is how we require
that SDH AIS be used for example)
	* squelch traffic if there is any chance that an important
customer's traffic being misdelivered
	* send indication to head-end (for single-ended mon, prot-sw
reasons)
	* raise appropriate alarms
-	3rd use persistency of defects to define unavailability entry/exit
criteria;
-	4th use above to determine the time over which QoS metrics are
valid, ie QoS aggregation needs suspending during unavailabilty as its makes
no sense to keep collecting it here against QoS SLAs.

Some simple but IMO very powerful solutions have been developed in Y.1711 to
satisfy these requirements...some people mistakenly think Y.1711 is complex,
but its just the opposite and it has been kept simple on purpose.  The
requirements also ask for the following additional characteristics:
-	both continuous and on-demand (this is the distinction between auto
defect detection/handling and ad hoc diagnostic tools I referred to
previously);
-	a single defect should not give rise to multiple alarms or multiple
corrective actions;
-	should cater for simple breaks (and be able to differentiate server
from within same layer breaks), swapped/misconfigurations, unintended
replication (with or without offending traffic being impacted) and
unintended self replication (eg loops, DOS attack);
-	OAM functions should be backwards compatible and optional for
operators;
-	one layer network's data-plane OAM should not rely on another layer
network's data-plane OAM (be that server or client relative to the layer
considered);
-	data-plane defect handling should not be dependent on any
control-plane or management-plane protocols (inc the 'no control-plane'
case);
-	defect detection/handling should not be dependent on customer
traffic activity levels;
-	defect detection/handling should work relaible under degraded
conditions, ie error events.

So.....if we can satisfy this lot as simply as Y.1711 can then that's great.

> 
> People may forget how "ping" and "traceroute" were used in 
> the Internet 
> years ago: they were used to solve the similar problems that we are 
> facing today in (G)MPLS networks, i.e., to detect and locate trouble 
> spots. In the NSFnet days, we had always used both commands (and some 
> more) to detect microcode and HDLC bugs in the network....
> 
> When (G)MPLS technology becomes more mature one day, there may not be 
> much need to use any tool for detecting physical layer 
> problem. But now, 
> there is urgent need to have the tools. Instead of working out 
> philosophical issues, why don't we just solve the problem?
NH=> Done it....its in Y.1711.  Why not tell us what's wrong with this?
Note - Its not the complete answer, as it currently only addresses defect
detection/handling.  The 'desirable' ad hoc diagnostic tools like
trail-trace and P-flows (ie to invoke more detailed QoS metrics) are the
next things to address.

Delivery-date: Wed, 27 Feb 2002 10:58:45 -0800
Date: Wed, 27 Feb 2002 10:58:12 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
cc: Ben Mack-Crane <[email-masked]>, [email-masked]
Subject: RE: WG document status

Hi Jerry,

On Wed, 27 Feb 2002, Ash, Gerald R (Jerry), ALASO wrote:

> > WG Last Call for this draft is over.  And over.  And over.  It's
> > DONE.  Consensus was rather rough.  That's a pity -- it would be
> > nice to make everyone happy.
> 
> Yes, last call was *declared* over.

That's what a chair is supposed to do.  Check with the ADs.

> But the SDH/SONET issue pertains to this draft too.  And that comment
> was made again.  And again.  And again.  And still *not* resolved.

You seem confused.  The only aspect of SDH/SONET in the generalized
draft is the LSP encoding.  That is under discussion; to be more
precise, the SDH/SONET label format, the traffic parameters and two
code points in the LSP encoding are under discussion.

If the tone in my reply to Ben offends you or Ben, let me explain:
feel free to dredge up the past, and rehash old arguments.  I have
work to do, however, and as far as I am concerned, the issues that
Ben raised are *resolved*; if you prefer, *declared resolved*.

Kireeti.

Delivery-date: Wed, 27 Feb 2002 10:48:27 -0800
Date: Wed, 27 Feb 2002 10:49:45 -0800
From: Ping Pan <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

[email-masked] wrote:

>>>-	what is the impact on customers?
>>>
>>When there is a problem, without a good application, it may 
>>take hours 
>>for the operators to figure out where the problem is.... I am pretty 
>>sure BT had experienced this in the past. :-)
>>
> NH=> OK thanks....I was wondering if there was some new problem that had
> arisen, and that's why yourself/Loa were saying this is urgent (hence my
> question).  But yes connectivity problems happen...and not just in the past
> either.  Big push coming down from above here for increased robustness and
> reduced opex...one aspect of which is (i) auto detection of defect (ii) auto
> handling of defect.....then we need tools to diagnose/clear.
> 

Neil,

Here is what I think on auto-detection and atuo-handling:

1. The operators should have the option to turn on some "ping-like" 
function on the suspicious LSPs at ingress LSRs. These LSPs will be 
queries periodically. It's important to make sure that this function 
won't introduce too much overhead.

2. If a LSP is in trouble, it would be nice to have the "traceroute" 
function kick in automatically. Eventually, the trouble spot can be 
located and reported.

3. Now, when a problem is identified, there are two ways to handle this:

(1) Page the operators asap, and have them to fix the problem.
(2) Fix the problem automatically. For example, the ingress LSR can 
repair the LSP by setting up a new one that skips the trouble nodes.

 From the development point of view, we can do both, but the operators 
can tell us what they prefer.

Regards,

- Ping

Envelope-to: [email-masked]
Delivery-date: Wed, 27 Feb 2002 10:30:31 -0800
Date: Wed, 27 Feb 2002 10:28:51 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: SDH/SONET label issue

Thanks, everyone who's replied so far for your comments.

Those who haven't but plan to, please do so by 5pm EST Thursday
(tomorrow), so that perhaps we can have a new version of
draft-ietf-ccamp-glmps-sonet-sdh-xx.txt by the Friday deadline.
Note that this does not mean that the issue will be closed; this
is just to get an interim document for folks to read for the
upcoming IETF.

Also, Eric proposed an option (4).  That is a valid option; if
you choose to change a previous opinion, PLEASE state that you
had chosen x, and now opt to change to y.

Eric has a more complex set of options as well; we can try evaluate
them over the next couple of weeks and at the IETF meeting.

Thanks,
Kireeti.

Delivery-date: Wed, 27 Feb 2002 09:36:25 -0800
From: "Bernstein, Greg" <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: Routing drafts
Date: Wed, 27 Feb 2002 09:35:37 -0800

It's really a matter of how efficient one wants to be with optical and/or
TDM bandwidth.  
I'm not sure what you mean about carrying the information differently in
signaling and routing.  For SONET/SDH signaling we specify the number of
STS-1s, VC-4s etc that we want with simple relatively small integers.  Not
with floating point numbers (or collections of floating point numbers).
Hence we already made this decision with signaling and would like routing
consistent with it.

I'd like to update bandwidth often (from the optical networking perspective)
and keep the impact to the control plane to a minimum (since it doesn't take
much info to convey these bandwidth updates).  

Greg B.
-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2002 9:52 PM
To: Bernstein, Greg
Cc: [email-masked]
Subject: RE: Routing drafts

Hi Greg,
Snip...
> (b) Big issue -- The parameters for representing bandwidth on a link are
not
> very appropriate for TDM signals or WDM signals.  I've included below some
> more explanation taken from the IPO working group draft. However, this is
> the same thing that led to us breaking out the traffic descriptor stuff in
> GMPLS signaling for the SONET/SDH case.  This is really needed here too.

I don't know that this is _really needed_.  Note that the bandwidth
encoding in signaling is a floating point number.  Perhaps this isn't
the most aesthetic way of carrying TDM signal information, but it works
adequately.  Is it worth carrying the information differently in
signaling and in routing, and differently for each switching type?
What is the tangible gain?

Which is not to say we can't discuss this.

Kireeti.

Delivery-date: Wed, 27 Feb 2002 09:27:39 -0800
From: Hai Vodinh <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, "Mannie, Eric" <[email-masked]>
Cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Wed, 27 Feb 2002 09:27:03 -0800

Kireeti,

(1) for me.

Regards,
Hai

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 3:39 PM
To: Mannie, Eric
Cc: 'Wijnen, Bert (Bert)'; ccamp-wg
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Kireeti,

1 for me.

Regards,

Maarten

Delivery-date: Wed, 27 Feb 2002 09:20:13 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 27 Feb 2002 17:18:47 -0000

many thanks Ping for your answers.....some additional points below.
regards, Neil

> > -	what is the problem?
> Detect and locate detect data plane failures in LSPs.
NH=> I can buy into the latter (ie locate) for simple connectivity breaks at
least, but I am struggling understanding the initial detection bit.  Are you
saying GTTP is somehow running continuously then?
> 
> > -	what is the impact on customers?
> When there is a problem, without a good application, it may 
> take hours 
> for the operators to figure out where the problem is.... I am pretty 
> sure BT had experienced this in the past. :-)
NH=> OK thanks....I was wondering if there was some new problem that had
arisen, and that's why yourself/Loa were saying this is urgent (hence my
question).  But yes connectivity problems happen...and not just in the past
either.  Big push coming down from above here for increased robustness and
reduced opex...one aspect of which is (i) auto detection of defect (ii) auto
handling of defect.....then we need tools to diagnose/clear.
> 
> > -	how does the operator detect detect the problem in the 
> 1st place?
> Currently, operators read memory dumps from many LSRs to 
> figure out if 
> there is a label mismatch for a LSP.
NH=> I read from this that you have evidence of more than simple
connectivity breaks....is that correct?  I agree this would indeed be a
tedious way to diagnose.
<snipped to end NH>

Delivery-date: Wed, 27 Feb 2002 08:47:26 -0800
From: "Brungard, Deborah A, ALASO" <[email-masked]>
To: "'Zhi-Wei Lin'" <[email-masked]>, "Mannie, Eric" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>, Kireeti Kompella <[email-masked]>, Ben Mack-Crane <[email-masked]>, [email-masked]
Subject: RE: WG document status
Date: Wed, 27 Feb 2002 11:32:42 -0500

Eric and Zhi are both correct -

gen-signaling-07, on the LSP encoding type values, has two separate codes to
support SDH ITU-T G.707 and SONET ANSI T1.105, and two different codes for
ANSI PDH and ETSI PDH. This excludes PDH types supported outside of ANSI and
ETSI. I have many times suggested simply one code for ITU-T PDH, which
includes everyone (all types are captured in ITU-T).
 
[Also true for SDH, the ANSI STS-3 (SDH AU-3) structure is used in SDH
countries (SDH countries do exist outside of Europe). The use of two codes
for SDH and SONET does not simplify the groups of structures which one needs
to support. The full ITU-T set needs to be supported in the U.S., Europe,
and everywhere.]

My comment was to say the question to use different values for SDH and
SONET, depending the outcome, will also impact the gen-signalling document.
And to remind everyone, at the LSP level, there are also two code points.
There are code points for differentiating SDH/SONET at all levels
(redundant?).

Deborah

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, February 27, 2002 9:18 AM
To: Mannie, Eric
Cc: Ash, Gerald R (Jerry), ALASO; Kireeti Kompella; Ben Mack-Crane;
[email-masked]; Brungard, Deborah A, ALASO
Subject: Re: WG document status

Hi,

I think Jerry's point is that in 
draft-ietf-mpls-generalized-signaling-07.txt, section 3.1.1, LSP 
encoding type:

Value 5: SDH ITU-T G.707
Value 6: SONET ANSI T1.105

is still separate and should be:

Value 5 (or xx): SDH ITU-T G.707

Also, based on one of Deborah's earlier email, the same probably holds 
true for the PDH:

Value 3: ANSI PDH
Value 4: ETSI PDH

should be:

Value 3 (or yy): ITU-T PDH

Is this correct, Jerry or Deborah?

Zhi

Mannie, Eric wrote:
> Hello Gerald,
> 
> 
>>Disagree.  As Deborah just said again on Monday, the SONET/SDH label issue
>>
> applies to the gen-signaling draft too, where the SDH and SONET labels are
> defined.  This comment has been made again.  And again.  And now again.
> 
> Not at all, the SDH/SONET labels are NOT defined in the generalized
> signaling drafts. Please check the drafts. The whole SDH/SONET, including
> the labels, is in the two SDH/SONET drafts, except of course the values of
> the LSP Encoding Type that are listed in the generalized signaling draft.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2002 2:16 PM
> To: Kireeti Kompella; Ben Mack-Crane
> Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]
> Subject: RE: WG document status
> 
> 
> Kireeti,
> 
> 
>>>Regarding the generalized signaling draft, I submitted
>>>several comments after the last IETF identifying technical
>>>issues
>>>
> 
>>WG Last Call for this draft is over.  And over.  And over.  It's
>>DONE.  Consensus was rather rough.  That's a pity -- it would be
>>nice to make everyone happy.
>>
> 
> Yes, last call was *declared* over.  But the SDH/SONET issue pertains to
> this draft too.  And that comment was made again.  And again.  And again.
> And still *not* resolved.
> 
> 
>>Right now, the only issue on the signaling front is the SDH/SONET
>>label issue.  And that's a _different_ draft.
>>
> 
> Disagree.  As Deborah just said again on Monday, the SONET/SDH label issue
> applies to the gen-signaling draft too, where the SDH and SONET labels are
> defined.  This comment has been made again.  And again.  And now again.
> 
> Jerry Ash
> 
> 

Delivery-date: Wed, 27 Feb 2002 08:27:14 -0800
Date: Wed, 27 Feb 2002 08:28:15 -0800
From: Ping Pan <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

[email-masked] wrote:

> 
> -	a trail-tracing function is one diagnostic tool which is 'desirable'
> to help operations people verify routing......it is not the only 'desirable'
> diagnostic tool required.  Moreover, it is not a defect detection/handling
> tool, which is an 'essential' function IMO.  I hardly think it appropriate
> that in all the cases we want to use IP/MPLS technologies to expect the
> customer to act as the defect detection mechanism.  I see this as
> particularly ironic and inconsistent given that in the GMPLS work it is
> taken for granted that the defect detection/handling mechanisms relevant to
> the traffic/data-plane of a L1 layer network (eg SDH) must indeed be
> present....such as correct framing, BIP-X violations, trail-trace
> violations, FDI to suppress higher client layer alarms, etc. ...

Neil,

Just curious, what's wrong with using IP "tools" to detect data-plane 
LSP problems?  That's how we have been doing things in the Internet for 
years.

People may forget how "ping" and "traceroute" were used in the Internet 
years ago: they were used to solve the similar problems that we are 
facing today in (G)MPLS networks, i.e., to detect and locate trouble 
spots. In the NSFnet days, we had always used both commands (and some 
more) to detect microcode and HDLC bugs in the network....

When (G)MPLS technology becomes more mature one day, there may not be 
much need to use any tool for detecting physical layer problem. But now, 
there is urgent need to have the tools. Instead of working out 
philosophical issues, why don't we just solve the problem?

Regards,

- Ping

Delivery-date: Wed, 27 Feb 2002 08:02:29 -0800
Date: Wed, 27 Feb 2002 08:02:47 -0800
From: Ping Pan <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

Neil,

[email-masked] wrote:

> Ping/Loa,
> 
> Can you please be more specific about the 'problem' you are talking about
> here.....and are you both talking about the same problem or different
> problems?  It would help me at least understand better if you can explain:
> -	what is the problem?

Detect and locate detect data plane failures in LSPs.

> -	what is the impact on customers?

When there is a problem, without a good application, it may take hours 
for the operators to figure out where the problem is.... I am pretty 
sure BT had experienced this in the past. :-)

> -	how does the operator detect detect the problem in the 1st place?

Currently, operators read memory dumps from many LSRs to figure out if 
there is a label mismatch for a LSP.

> -	how does tunneltrace diagnose the problem?

To diagnose a LSP, the operators can use traceroute to verify LSP 
connectivity at each hop. The LSR where there is a label mismatch can be 
found rather quickly.

> -	what are the expected consequent actions to fix it?
> 

When a "bad" LSP is found, it's up to the operator to decide what to do 
with it.

Regards,

- Ping

Delivery-date: Wed, 27 Feb 2002 06:22:06 -0800
Cc: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>
Date: Wed, 27 Feb 2002 00:38:56 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

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

Kireeti,

1 for me.

Regards,

Maarten
--------------BCCFB865BFD943FA5A3F1034
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;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------BCCFB865BFD943FA5A3F1034--

Delivery-date: Wed, 27 Feb 2002 06:20:49 -0800
Cc: "'Stephen Trowbridge'" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Date: Wed, 27 Feb 2002 01:35:18 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Heiles Juergen <[email-masked]>
Original-CC: "'Stephen Trowbridge'" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Re: Simple solution to terminate the discussion about SONET versus SDH

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

Eric, 

In addition to those things stated by Juergen/Steve, there are SDH networks
(outside of the USA) that use 64 byte trace identifiers. Also we have the
M0/M0M1 difference for MS-REI, the 1/16 byte J0, SSM Option I/II/III and most
likely a few more low level options defined within SDH.

When you have to set up a monitored connection, you have to take care of these
options during connection set up. This is identical with today's case of
permanent connections where the network management system takes care of these
options. 
This is to be addressed as part of the "setting up of a monitored connection"
work I referred to in my presentation during the IETF52 meeting.

Regards,

Maarten

Heiles Juergen wrote:
> 
> I wanted to add some clarifications to my "YES", but Steve did it first.
> 
> Both SONET and SDH have Options like the 16 or 64 byte trace for the J1. SDH defines the 16 byte trace as a must when crossing international borders or operator domains, if not mutual agreed otherwise by the involved operators and it allows the 64 byte trace within national networks and operator domains.
> Also the "SONET enhanced RDI" is described as an option for SDH in an Appendix of G.707.
> 
> If you want to have interworking even within a "SDH or SONET network" you have to consider these options. A general selection between SDH and SONET doesn't help at all.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 4:22 PM
> > To: Mannie, Eric
> > Cc: 'Heiles Juergen'; [email-masked]'; Wijnen, Bert (Bert);
> > [email-masked]'; ccamp-wg; [email-masked]'; 'Kireeti Kompella'
> > Subject: Re: Simple solution to terminate the discussion about SONET
> > versus SDH
> >
> >
> > Eric,
> > I don't think you ask quite the right question.
> > The right question is:
> > Can all frame structures which are common to SONET and SDH be
> > interconnected,
> > and do they interoperate? This is what we care about from the
> > viewpoint of
> > establishing switched connections.
> > The answer to this is YES.
> >
> > Are they fully identical from all points of view? As Juergen
> > says, this is the
> > tricky question, as the answer of "No" might mislead some
> > into thinking that
> > these signals cannot be interconnected between SONET and SDH.
> > This is not
> > the case.
> >
> > For those who care, some of the key differences are as
> > follows. Note that these
> > do NOT affect the ability to interconnect these signals
> > (although sometimes there
> > are rules about HOW to interconnect them).
> >
> > SS bits - In the past, this was an issue in the high order
> > pointers. SDH sent
> > and expected "10", for SONET these bits were unspecified.
> > This problem was corrected
> > a few years ago by requiring that ALL equipment send "10" and
> > ignore the incoming
> > bits. Note that even prior to aligning the standards, a great
> > deal of the older
> > equipment followed this strategy as VC-4s and STS-3cs were
> > interconnected long
> > before the standards alignment.
> >
> > Trace identifier - For J1, within SONET, a 64 byte format is
> > normally used. For SDH,
> > a 16 byte format is normally used. SONET specifies that in
> > the case that the far end
> > is SDH, a 16 byte format should be used to allow
> > interworking. For J2, this is normally
> > used in SDH and not normally in SONET. Interworking is
> > acheived by having the SDH end
> > ignore the incoming trace identifier (a required capability
> > in the standards).
> >
> > RDI - SONET uses some extra bits that are reserved in SDH to
> > further classify far end
> > alarms (called ENHANCED RDI). This provides no obstacle to
> > interworking: The SONET
> > side will not be able to provide a more detailed
> > classification of SDH end alarms (it
> > does know there is a far end alarm). The SDH end ignores the
> > extra bits. The Enhanced
> > RDI feature only operates if both ends are SONET.
> >
> > BIP - The coding for BIP is identical. The way degrade is
> > detected is different.
> > SONET generally uses a Poisson algorithm to declare degrade
> > and SDH normally uses
> > a bursty error detection algorithm. This provides no obstacle
> > to interconnect - the
> > criteria for declaring dDEG is just slightly different. Also,
> > SONET provides an
> > EXC alarm for BER > 10^-3 which does not appear in SDH. This
> > also does not prevent
> > interconnect - you just have an alarm which can be declared
> > at one end and not the
> > other.
> >
> > These are the major differences (besides the fact that SONET
> > and SDH tend to have
> > different names for identical things- This is just a
> > US/Europe language issue).
> > Regards,
> > Steve
> >
> > "Mannie, Eric" wrote:
> > >
> > > Dear All,
> > >
> > > There is an easy way to stop definitively this discussion
> > based on technical
> > > facts:
> > >
> > > Stephen, Juergen and Maarten, please tell us: today, are the frame
> > > structures and all the bytes in the SDH and SONET overhead
> > completely
> > > identical, used and interpreted in the same way, is the
> > monitoring exactly
> > > the same ? In particular, if I provision and operate an SDH
> > circuit/LSP is
> > > this fully identical to a SONET circuit/LSP from *all*
> > point of views ?
> > >
> > > PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not
> > needed at this
> > > stage.
> > >
> > > If the answer is yes: SONET is totally identical to SDH.
> > > If the answer is no: SONET is not the same as SDH.
> > >
> > > I think that without that answer we cannot take any
> > *technical* decision on
> > > this mailing list and at the IETF.
> > >
> > > Thanks to answer.
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > ps: feel free to forward this e-mail to any ITU-T mailing list if a
> > > confirmation is needed.
> >
--------------98FC49479DC6DB6A98D55D18
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;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------98FC49479DC6DB6A98D55D18--

Delivery-date: Wed, 27 Feb 2002 06:17:05 -0800
Date: Wed, 27 Feb 2002 09:17:33 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'Ash, Gerald R (Jerry), ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Ben Mack-Crane <[email-masked]>, [email-masked], Deborah Brungard <[email-masked]>
Subject: Re: WG document status

Hi,

I think Jerry's point is that in 
draft-ietf-mpls-generalized-signaling-07.txt, section 3.1.1, LSP 
encoding type:

Value 5: SDH ITU-T G.707
Value 6: SONET ANSI T1.105

is still separate and should be:

Value 5 (or xx): SDH ITU-T G.707

Also, based on one of Deborah's earlier email, the same probably holds 
true for the PDH:

Value 3: ANSI PDH
Value 4: ETSI PDH

should be:

Value 3 (or yy): ITU-T PDH

Is this correct, Jerry or Deborah?

Zhi

Mannie, Eric wrote:
> Hello Gerald,
> 
> 
>>Disagree.  As Deborah just said again on Monday, the SONET/SDH label issue
>>
> applies to the gen-signaling draft too, where the SDH and SONET labels are
> defined.  This comment has been made again.  And again.  And now again.
> 
> Not at all, the SDH/SONET labels are NOT defined in the generalized
> signaling drafts. Please check the drafts. The whole SDH/SONET, including
> the labels, is in the two SDH/SONET drafts, except of course the values of
> the LSP Encoding Type that are listed in the generalized signaling draft.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2002 2:16 PM
> To: Kireeti Kompella; Ben Mack-Crane
> Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]
> Subject: RE: WG document status
> 
> 
> Kireeti,
> 
> 
>>>Regarding the generalized signaling draft, I submitted
>>>several comments after the last IETF identifying technical
>>>issues
>>>
> 
>>WG Last Call for this draft is over.  And over.  And over.  It's
>>DONE.  Consensus was rather rough.  That's a pity -- it would be
>>nice to make everyone happy.
>>
> 
> Yes, last call was *declared* over.  But the SDH/SONET issue pertains to
> this draft too.  And that comment was made again.  And again.  And again.
> And still *not* resolved.
> 
> 
>>Right now, the only issue on the signaling front is the SDH/SONET
>>label issue.  And that's a _different_ draft.
>>
> 
> Disagree.  As Deborah just said again on Monday, the SONET/SDH label issue
> applies to the gen-signaling draft too, where the SDH and SONET labels are
> defined.  This comment has been made again.  And again.  And now again.
> 
> Jerry Ash
> 
> 

Delivery-date: Wed, 27 Feb 2002 06:13:57 -0800
Date: Wed, 27 Feb 2002 02:07:27 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status]

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

ASON supports both the peer and the overlay model. When the interconnect is a
NNI (trust relation) there is a peer relation, when there is a UNI (no trust
relation) there is an overlay.

ASON defines its connection setup within the scope of one layer network (e.g.
VC-4, ODU3). If e.g. a Router with a VC-4 port needs to set up a VC-4 trail to
support an IP link, the router can have a VC-4 UNI or VC-4 NNI into the network. 
- For the VC-4 UNI case, the router "includes" a VC-4 Calling/Called Party Call
Controller (CCC) function (intra-layer overlay model support). 
- For the VC-4 NNI case, the router "includes" a VC-4 Connection Controller (CC)
function (intra-layer peer model support).

The above addresses intra-layer overlay/peering situations. 
There is also the inter-layer overlay/peering case. 

The network engineering process (for inter-layer interactions) is currently
under study within ASON. One can consider the following for the moment: when the
network engineering process within the IP layer network decides it needs an
additional IP Link, or an extension of an already existing IP Link between nodes
X and Y, then the IP Network Engineering Controller may issue a VC-4 call
request to the VC-4 Network Call Controller (NCC). The endpoint of the call are
a VC-4 SNP (Pool) representing a VC-4 port (group) in X and a VC-4 SNP (Pool) in
Y (case of inter-layer overlay model). 
Not yet considered, but not impossible would be that the IP network engineering
controller could "include" a VC-4 CC (case of inter-layer peering model).
Whether this is more theoretical than practical is not the issue of this thought
here.

Regards,

Maarten

> Osama Aboul-Magd wrote:
> 
> Dimitri,
> 
> You can also look at GMPLS as a tool kit that is applicable to different
> models, ASON being one of them.
> 
> Yes, ASON is an overlay model. There is no reason why GMPLS based protocols
> for signaling and routing could not be used for ASON control plane
> implementation. Your statement regarding "restricting" routing information
> between client and server networks only reflects your preference to deploy a
> peer model. This is fine, but do not impose artificial requirements that
> wouldn't allow the application of GMPLS protocols to other models. The last
> time I looked at the IP over optical framework, overlay was one of the models
> discussed.
> 
> I have been saying in a number of presentations to the IPO WG (in the context
> of "draft-ietf-ipo-ason-01.txt") that ASON and GMPLS are complementary in the
> sense that GMPLS protocols could be used for ASON control plane realizations.
> The latest activities at the ITU just prove that.
> 
> Regards;
> 
> Osama Aboul-Magd
> Nortel Networks
> P.O. Box 3511, Station "C"
> Ottawa, ON, Canada
> K1Y - 4H7
> Tel: 613-763-5827
> e.mail: [email-masked]
> 
>  -----Original Message-----
> From:   [email-masked]
> [mailto:[email-masked]]
> Sent:   Tuesday, February 26, 2002 8:43 AM
> To:     Wijnen, Bert (Bert)
> Cc:     Mannie, Eric; 'Mak, L (Leen)'; [email-masked]; Kireeti Kompella
> Subject:        Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG
> dcoument status]
> 
> Bert,
> 
> i see many issues, the statement refers to "call" while from the
> ietf terminology, this term is referred to as "session"; as such
> it could be appropriate from our side to review the statement
> made in the "ITU liaison" because the proposed separation plugs
> a "telephony-oriented" model (or telephony-like model) to a data
> /circuit switched oriented network - but not with "64kb" - one
> speak here about connections from 51.84 Mb (more precisely the
> payload of a C3 is 48384 kbps) to 2.5, 10 or even 40 Gbps !
> This separation (adapted for public telephony network) is also
> constructed on an assumption that there is no control plane
> protocol as we have today with GMPLS protocols but that connection
> signalling is performed by the transport plane (using embedded
> signalling) or through management plane. So there is an under-
> lying fundamental question isn't the G.ASON model only a "public
> overlay model" and then we have to ask ourself if the scope of
> GMPLS has to be adapated/restricted to such public networks
> using an overlay control plane inter-connection: imho, clearly no
> but what could be considered is a "GMPLS profile" for G.ASON.
> 
> Moreover this "assumption" resulted to the fact that G.ASON is
> based on a fundamental assumption: no routing information exchange
> between the client and server layer. GMPLS does not have such
> stringent restriction. Consequently, this makes the separation
> call/connection (while mandatory per requirement in the stringent
> G.ASON model) not at all mandatory in the IETF scope since the
> "routing exchanges" fulfill the role played by the call operation:
> the source knows the status and the availability of the set of
> destinations it can reach. Since routing is one of the foundation
> of any data network, i think we should probably also discuss if
> this separation is adapted for other types of GMPLS networks. In
> brief, i don't think we have to restrict the ubiquity of the GMPLS
> protocol suite.
> 
> Hope this clarifies,
> 
> regards,
> - dimitri.
> 
> "Wijnen, Bert (Bert)" wrote:
> >
> > Erik et all, the "official communications from the ITU" are
> > listed under the Liaison Statements on the IETF Web Page.
> > The page is at: http://www.ietf.org/IESG/liaison.html
> >
> > If you see trouble/issues with any of those, pls let WG chairs and
> > ADs know, so we can take action.
> >
> > Bert
> 
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
> Address: Alcatel - Optical NA, Fr. Wellesplein, 1
>          B-2018 Antwerpen, Belgium
> Phone:   Work: +32 3 2408491 - Home: +32 2 3434361
--------------DBCC5E5A8F1CA1DCCC54303B
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;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------DBCC5E5A8F1CA1DCCC54303B--

Delivery-date: Wed, 27 Feb 2002 05:43:05 -0800
From: "Mannie, Eric" <[email-masked]>
To: "'Ash, Gerald R (Jerry), ALASO'" <[email-masked]>, Kireeti Kompella <[email-masked]>, Ben Mack-Crane <[email-masked]>
Cc: [email-masked]
Subject: RE: WG document status
Date: Wed, 27 Feb 2002 14:40:21 +0100

Hello Gerald,

> Disagree.  As Deborah just said again on Monday, the SONET/SDH label issue
applies to the gen-signaling draft too, where the SDH and SONET labels are
defined.  This comment has been made again.  And again.  And now again.

Not at all, the SDH/SONET labels are NOT defined in the generalized
signaling drafts. Please check the drafts. The whole SDH/SONET, including
the labels, is in the two SDH/SONET drafts, except of course the values of
the LSP Encoding Type that are listed in the generalized signaling draft.

Kind regards,

Eric

-----Original Message-----
From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]]
Sent: Wednesday, February 27, 2002 2:16 PM
To: Kireeti Kompella; Ben Mack-Crane
Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]
Subject: RE: WG document status

Kireeti,

> > Regarding the generalized signaling draft, I submitted
> > several comments after the last IETF identifying technical
> > issues

> WG Last Call for this draft is over.  And over.  And over.  It's
> DONE.  Consensus was rather rough.  That's a pity -- it would be
> nice to make everyone happy.

Yes, last call was *declared* over.  But the SDH/SONET issue pertains to
this draft too.  And that comment was made again.  And again.  And again.
And still *not* resolved.

> Right now, the only issue on the signaling front is the SDH/SONET
> label issue.  And that's a _different_ draft.

Disagree.  As Deborah just said again on Monday, the SONET/SDH label issue
applies to the gen-signaling draft too, where the SDH and SONET labels are
defined.  This comment has been made again.  And again.  And now again.

Jerry Ash

Delivery-date: Wed, 27 Feb 2002 05:16:43 -0800
content-class: urn:content-classes:message
Subject: RE: WG document status
Date: Wed, 27 Feb 2002 08:15:49 -0500
From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, "Ben Mack-Crane" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>, <[email-masked]>

Kireeti,

> > Regarding the generalized signaling draft, I submitted
> > several comments after the last IETF identifying technical
> > issues

> WG Last Call for this draft is over.  And over.  And over.  It's
> DONE.  Consensus was rather rough.  That's a pity -- it would be
> nice to make everyone happy.

Yes, last call was *declared* over.  But the SDH/SONET issue pertains to =
this draft too.  And that comment was made again.  And again.  And =
again.  And still *not* resolved.

> Right now, the only issue on the signaling front is the SDH/SONET
> label issue.  And that's a _different_ draft.

Disagree.  As Deborah just said again on Monday, the SONET/SDH label =
issue applies to the gen-signaling draft too, where the SDH and SONET =
labels are defined.  This comment has been made again.  And again.  And =
now again.

Jerry Ash

Delivery-date: Wed, 27 Feb 2002 04:54:24 -0800
From: Silman Lionel <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Wed, 27 Feb 2002 11:24:58 +0200

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_01C1BF71.683B6B3E
Content-Type: text/plain;
	charset="windows-1255"

[ post from non-subscriber ]

I support (1).

As explained by Trowbridge and Juergen, despite small possible differences
in some header fields, SDH and SONET do interwork. Paths do cross from SONET
domains to SDH domains - with variable degrees of gateworking required (and
often none). It is thus not appropriate to classify the path as SONET or
SDH. It is more convenient to have single label scheme.

------------------------------------------------------------------------
Lionel Silman, Ph.D. System Design Director
Enavis Networks
16, Martin Gehl Street, Petach Tikva 49194 Israel
Work:+972(3)9261537   Fax:   +972(3)9261845 
Home:+972(3)6417464  Email:[email-masked]

------_=_NextPart_001_01C1BF71.683B6B3E
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Re: SONET/SDH label agreement for IETF, ITU-T and OIF</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I support (1).</FONT>
</P>

<P><FONT SIZE=3D2>As explained by Trowbridge and Juergen, despite small =
possible differences in some header fields, SDH and SONET do interwork. =
Paths do cross from SONET domains to SDH domains - with variable =
degrees of gateworking required (and often none). It is thus not =
appropriate to classify the path as SONET or SDH. It is more convenient =
to have single label scheme.</FONT></P>
<BR>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
---------</FONT>
<BR><FONT SIZE=3D2>Lionel Silman, Ph.D. System Design Director</FONT>
<BR><FONT SIZE=3D2>Enavis Networks</FONT>
<BR><FONT SIZE=3D2>16, Martin Gehl Street, Petach Tikva 49194 =
Israel</FONT>
<BR><FONT SIZE=3D2>Work:+972(3)9261537&nbsp;&nbsp; Fax:&nbsp;&nbsp; =
+972(3)9261845 </FONT>
<BR><FONT SIZE=3D2>Home:+972(3)6417464&nbsp; =
Email:[email-masked]</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1BF71.683B6B3E--

Delivery-date: Wed, 27 Feb 2002 04:54:20 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 27 Feb 2002 12:53:52 -0000

Thanks Loa.....yes I did read that but it did not answer my specific
questions.

Ron...it is possible perhaps you can help me with specific answers? 

regards, Neil

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: 27 February 2002 12:28
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02
> 
> 
> Neil,
> 
> from the draft:
> 
> 
>    "Although these tunneling technologies provide operators with many
>     useful features, they also present management challenges. 
>  Operators
>     require a generic route tracing application that they can use to
>     verify tunnel paths and diagnose tunnel faults."
> 
> /Loa
> 
> [email-masked] wrote:
> 
> > Ping/Loa,
> > 
> > Can you please be more specific about the 'problem' you are 
> talking about
> > here.....and are you both talking about the same problem or 
> different
> > problems?  It would help me at least understand better if 
> you can explain:
> > -	what is the problem?
> > -	what is the impact on customers?
> > -	how does the operator detect detect the problem in the 
> 1st place?
> > -	how does tunneltrace diagnose the problem?
> > -	what are the expected consequent actions to fix it?
> > 
> > thanks, Neil
> > 
> > 
> >>-----Original Message-----
> >>From: Loa Andersson [mailto:[email-masked]]
> >>Sent: 27 February 2002 08:53
> >>To: Ping Pan
> >>Cc: 'Kireeti Kompella'; [email-masked]; [email-masked]
> >>Subject: Re: draft-bonica-tunneltrace-02
> >>
> >>
> >>All,
> >>
> >>
> >>don't know if my opinion registred in this show of hands. 
> Anyway I say
> >>(a). It is an identified problem, we need to deal with it and 
> >>by making
> >>a WG doc, the working groupd can start working with it.
> >>
> >>/Loa
> >>
> >>Ping Pan wrote:
> >>
> >>
> >>>Kireeti,
> >>>
> >>>
> >>>The requirement from Ron address the problem that we have 
> >>>
> >>been seen in 
> >>
> >>>the network today. This is an issue that we have to deal 
> >>>
> >>with it NOW. I 
> >>
> >>>vote (a).
> >>>
> >>>- Ping
> >>>
> >>>
> >>>
> >>>>>-----Original Message-----
> >>>>>From: Kireeti Kompella [mailto:[email-masked]]
> >>>>>Sent: Sunday, February 24, 2002 7:47 PM
> >>>>>To: David Allan
> >>>>>Cc: [email-masked]; [email-masked]; 
> >>>>>
> >>[email-masked]
> >>
> >>>>>Subject: RE: draft-bonica-tunneltrace-02
> >>>>>
> >>>>>
> >>>>>
> >>>>>Let me say a few words:
> >>>>>
> >>>>>1) There was good support for this work (the requirements doc) to
> >>>>>  be a WG document at a previous IETF.  It is a good thing to
> >>>>>  follow up and check what the mailing list thinks, as 
> >>>>>
> >>not everyone
> >>
> >>>>>  attends IETFs.
> >>>>>
> >>>>>2) It is interesting that no one brought up the issue of 
> >>>>>
> >>whether this
> >>
> >>>>>  work (tunnel tracing) is in the charter or not at the meeting.
> >>>>>  There are those who think the charter isn't explicit 
> >>>>>
> >>enough.  I'll
> >>
> >>>>>  talk to the ADs and see (a) if they think that this *is* in the
> >>>>>  charter; (b) if not, are they willing to take it to 
> the IESG and
> >>>>>  add it to the charter.
> >>>>>
> >>>>>  My input on this (as WG chair) is that CCAMP is all 
> >>>>>
> >>about tunnels,
> >>
> >>>>>  and a protocol to debug and test tunnels is well within 
> >>>>>
> >>scope, even
> >>
> >>>>>  if not called out explicitly.
> >>>>>
> >>>>>  Note that the charter is *not* subject to WG 
> consensus, nor even
> >>>>>  the WG chairs.  The IESG (and IAB?) are solely responsible,
> >>>>>  although the WG and chairs can suggest changes.
> >>>>>
> >>>>>3) A document that is "in the right spirit" can become a 
> >>>>>
> >>WG document,
> >>
> >>>>>  even if there are disagreements about some details, and even
> >>>>>  "fundamental" questions.  Note that "fundamental" is often
> >>>>>  subjective.
> >>>>>
> >>>>>I would like to have the mailing list equivalent of a 
> >>>>>
> >>'show of hands'
> >>
> >>>>>regarding this draft.  Do you think:
> >>>>>(a) it should be a WG document?
> >>>>>(b) it's good stuff, but not ready?
> >>>>>(c) we need a new start?
> >>>>>
> >>>>>Please send in your opinions with one of the above up top.  Any
> >>>>>detailed reasoning you have for your opinion may follow.
> >>>>>
> >>>>>Thanks!
> >>>>>Kireeti.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >>-- 
> >>Loa Andersson
> >>Chief Architect,
> >>Utfors Research, Architecture and Future Lab (URAX)
> >>Utfors AB
> >>Råsundavägen 12
> >>Box 525, 169 29 Solna
> >>Office          +46 8 5270 2000
> >>Office direct   +46 8 5270 5038
> >>Mobile          +46 70 848 5038
> >>Email           [email-masked]
> >>WWW             www.utfors.se
> >>
> >>
> >>
> > 
> 
> 
> -- 
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> Råsundavägen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           [email-masked]
> WWW             www.utfors.se
> 

Delivery-date: Wed, 27 Feb 2002 04:46:40 -0800
Date: Wed, 27 Feb 2002 09:46:39 +0100
From: Gert Grammel <[email-masked]>
To: [email-masked]
CC: Kireeti Kompella <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

[ post by non-subscriber ]

vote  2),

Gert

>
> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Sunday, February 24, 2002 4:11 PM
> To: Wijnen, Bert (Bert)
> Cc: Mannie, Eric; [email-masked]'; [email-masked]'; ccamp-wg;
> [email-masked]'
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
>
> On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:
>
> > Guys... I have seen to much of this. I have asked Kireeti
> > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> > WG mailing list. I do NOT want another 500 emails going back
> > and forth on this issue. We need to approach this pragmatically.
> >
> > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the
> >   WG mailing list on what exactly we agreed in SLC. That will
> >   help to prepare a response to ITU-T as well
>
> First off, I should apologize for letting this go on unchecked.
>
> Second, I should make it known to the WG as a whole that there was
> a discussion of this issue at SLC among several folks directly
> involved, the ADs and the chairs.  I thought we had achieved
> consensus, but now it seems not.
>
> Here's what I thought we had agreed:
>
> 1) There is a document in the ITU that defines a *single* standard that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the only such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET
>    that do not match the ITU document.
>
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
>
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
>
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
>
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
>
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
>
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
>
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
>
> Thanks,
> Kireeti.

--
Alcatel Optics Group            Gert Grammel
Network Strategy                phone:+39 039 686-4453
Via Trento, 30                  fax:+39 039 686-4871
I-20059 Vimercate (Mi)          mailto:[email-masked]

Delivery-date: Wed, 27 Feb 2002 04:28:29 -0800
From: Silman Lionel <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Wed, 27 Feb 2002 09:18:18 +0200

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_01C1BF5F.B52BBB68
Content-Type: text/plain;
	charset="windows-1255"

[ post fron non-subscrier ]

I support (1).

As explained by Trowbridge and Juergen, despite small possible differences
in some header fields, SDH and SONET do interwork. Paths do cross from SONET
domains to SDH domains - with variable degrees of gateworking required (and
often none). It is thus not appropriate to classify the path as SONET or
SDH. It is more convenient to have single label scheme.

------------------------------------------------------------------------
Lionel Silman, Ph.D. System Design Director
Enavis Networks
16, Martin Gehl Street, Petach Tikva 49194 Israel
Work:+972(3)9261537   Fax:   +972(3)9261845 
Home:+972(3)6417464  Email:[email-masked]

------_=_NextPart_001_01C1BF5F.B52BBB68
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Re: SONET/SDH label agreement for IETF, ITU-T and OIF</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I support (1).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As explained by Trowbridge and =
Juergen, despite small possible differences in some header fields, SDH =
and SONET do interwork. Paths do cross from SONET domains to SDH =
domains - with variable degrees of gateworking required (and often =
none). It is thus not appropriate to classify the path as SONET or SDH. =
It is more convenient to have single label scheme.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
---------------</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Lionel Silman, =
Ph.D. System Design Director</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Enavis =
Networks</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">16, Martin Gehl =
Street, Petach Tikva 49194 Israel</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">Work:+972(3)9261537&nbsp;&nbsp; Fax:&nbsp;&nbsp; =
+972(3)9261845 </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">Home:+972(3)6417464&nbsp; =
Email:[email-masked]</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1BF5F.B52BBB68--

Delivery-date: Wed, 27 Feb 2002 04:28:04 -0800
Date: Wed, 27 Feb 2002 13:27:41 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

Neil,

from the draft:

   "Although these tunneling technologies provide operators with many
    useful features, they also present management challenges.  Operators
    require a generic route tracing application that they can use to
    verify tunnel paths and diagnose tunnel faults."

/Loa

[email-masked] wrote:

> Ping/Loa,
> 
> Can you please be more specific about the 'problem' you are talking about
> here.....and are you both talking about the same problem or different
> problems?  It would help me at least understand better if you can explain:
> -	what is the problem?
> -	what is the impact on customers?
> -	how does the operator detect detect the problem in the 1st place?
> -	how does tunneltrace diagnose the problem?
> -	what are the expected consequent actions to fix it?
> 
> thanks, Neil
> 
> 
>>-----Original Message-----
>>From: Loa Andersson [mailto:[email-masked]]
>>Sent: 27 February 2002 08:53
>>To: Ping Pan
>>Cc: 'Kireeti Kompella'; [email-masked]; [email-masked]
>>Subject: Re: draft-bonica-tunneltrace-02
>>
>>
>>All,
>>
>>
>>don't know if my opinion registred in this show of hands. Anyway I say
>>(a). It is an identified problem, we need to deal with it and 
>>by making
>>a WG doc, the working groupd can start working with it.
>>
>>/Loa
>>
>>Ping Pan wrote:
>>
>>
>>>Kireeti,
>>>
>>>
>>>The requirement from Ron address the problem that we have 
>>>
>>been seen in 
>>
>>>the network today. This is an issue that we have to deal 
>>>
>>with it NOW. I 
>>
>>>vote (a).
>>>
>>>- Ping
>>>
>>>
>>>
>>>>>-----Original Message-----
>>>>>From: Kireeti Kompella [mailto:[email-masked]]
>>>>>Sent: Sunday, February 24, 2002 7:47 PM
>>>>>To: David Allan
>>>>>Cc: [email-masked]; [email-masked]; 
>>>>>
>>[email-masked]
>>
>>>>>Subject: RE: draft-bonica-tunneltrace-02
>>>>>
>>>>>
>>>>>
>>>>>Let me say a few words:
>>>>>
>>>>>1) There was good support for this work (the requirements doc) to
>>>>>  be a WG document at a previous IETF.  It is a good thing to
>>>>>  follow up and check what the mailing list thinks, as 
>>>>>
>>not everyone
>>
>>>>>  attends IETFs.
>>>>>
>>>>>2) It is interesting that no one brought up the issue of 
>>>>>
>>whether this
>>
>>>>>  work (tunnel tracing) is in the charter or not at the meeting.
>>>>>  There are those who think the charter isn't explicit 
>>>>>
>>enough.  I'll
>>
>>>>>  talk to the ADs and see (a) if they think that this *is* in the
>>>>>  charter; (b) if not, are they willing to take it to the IESG and
>>>>>  add it to the charter.
>>>>>
>>>>>  My input on this (as WG chair) is that CCAMP is all 
>>>>>
>>about tunnels,
>>
>>>>>  and a protocol to debug and test tunnels is well within 
>>>>>
>>scope, even
>>
>>>>>  if not called out explicitly.
>>>>>
>>>>>  Note that the charter is *not* subject to WG consensus, nor even
>>>>>  the WG chairs.  The IESG (and IAB?) are solely responsible,
>>>>>  although the WG and chairs can suggest changes.
>>>>>
>>>>>3) A document that is "in the right spirit" can become a 
>>>>>
>>WG document,
>>
>>>>>  even if there are disagreements about some details, and even
>>>>>  "fundamental" questions.  Note that "fundamental" is often
>>>>>  subjective.
>>>>>
>>>>>I would like to have the mailing list equivalent of a 
>>>>>
>>'show of hands'
>>
>>>>>regarding this draft.  Do you think:
>>>>>(a) it should be a WG document?
>>>>>(b) it's good stuff, but not ready?
>>>>>(c) we need a new start?
>>>>>
>>>>>Please send in your opinions with one of the above up top.  Any
>>>>>detailed reasoning you have for your opinion may follow.
>>>>>
>>>>>Thanks!
>>>>>Kireeti.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>-- 
>>Loa Andersson
>>Chief Architect,
>>Utfors Research, Architecture and Future Lab (URAX)
>>Utfors AB
>>Råsundavägen 12
>>Box 525, 169 29 Solna
>>Office          +46 8 5270 2000
>>Office direct   +46 8 5270 5038
>>Mobile          +46 70 848 5038
>>Email           [email-masked]
>>WWW             www.utfors.se
>>
>>
>>
> 

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

Delivery-date: Wed, 27 Feb 2002 04:24:21 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ash-multi-area-te-compare-00.txt
Date: Wed, 27 Feb 2002 07:23:27 -0500

--NextPart

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

	Title		: Comparison of Multi-Area TE Methods
	Author(s)	: J. Ash et al.
	Filename	: draft-ash-multi-area-te-compare-00.txt
	Pages		: 
	Date		: 26-Feb-02
	
This draft makes comparisons of various multi-area TE methods, which are 
evaluated against specific criteria.  Four basic path selection 
approaches are compared: a) distributed methods, 
b) path-computation-server (PCS) methods (centralized & distributed),
c) interarea-flooding methods, and d) multiple-path-compare methods.  
These approaches include needs to support PCS functionality, query 
functionality, crankback functionality, summary-te-LSA functionality, 
and TE feedback functionality.  The target is to converge on a reduced 
subset of required multi-area TE methods and protocol extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-multi-area-te-compare-00.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-ash-multi-area-te-compare-00.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-ash-multi-area-te-compare-00.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-ash-multi-area-te-compare-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ash-multi-area-te-compare-00.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, 27 Feb 2002 03:51:42 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 27 Feb 2002 11:50:17 -0000

Kireeti,

My vote is (b).

Rationale:

-	a trail-tracing function is one diagnostic tool which is 'desirable'
to help operations people verify routing......it is not the only 'desirable'
diagnostic tool required.  Moreover, it is not a defect detection/handling
tool, which is an 'essential' function IMO.  I hardly think it appropriate
that in all the cases we want to use IP/MPLS technologies to expect the
customer to act as the defect detection mechanism.  I see this as
particularly ironic and inconsistent given that in the GMPLS work it is
taken for granted that the defect detection/handling mechanisms relevant to
the traffic/data-plane of a L1 layer network (eg SDH) must indeed be
present....such as correct framing, BIP-X violations, trail-trace
violations, FDI to suppress higher client layer alarms, etc.  See also next
item.

-	I noted this comment from yourself:
>    My input on this (as WG chair) is that CCAMP is all about tunnels,
>    and a protocol to debug and test tunnels is well within scope, even
>    if not called out explicitly.
I have no problems with this statement per se.  However, a tunnel to me is a
server layer network relationship to a client layer network.  This can have
very many possible combinations, but some are more logical than others, eg
IPoverMPLS seems more logical than MPLSoverIP....others may disagree, but it
illustrates my point that 'tunnels' are not bounded by the example
client/server relationships given in the current draft.  In another part of
CCAMPs we see GMPLS being discussed.  Here we can have (for example) IP
served by SDH, eg IP may be using a VC-4 'tunnel'.....or LSP.....or whatever
you want to call it, architecturally its a VC-4 trail provided by a VC-4
layer network as defined in G.805, and it can act as a server layer trail
(tunnel) to many different client layer types besides IP.  I therefore find
it somewhat inconsistent:
	* to selectively choose only certain technologies and client/server
relationships when there is the above plea for generality wrt GTTP;
	* that CCAMPs is prepared to accept the need L1 traffic/data-plane
defect detection/handling tools in GMPLS work and yet refuse to accept that
the *defect detection/handling principles* applied at those layered networks
should also apply at other layer networks.

IMO we should have some consistent principles here across all layer
networks.  In terms of OAM functions this has been attempted in Y.1710
(principles/requirements)...and although aimed at MPLS in this case, if you
read them you will note that they are largely generic and apply to any layer
network to try and bring consistency of approach rather than ad hoc
expediency.

Hope that makes sense.

regards, Neil

Delivery-date: Wed, 27 Feb 2002 02:56:23 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: RE: Routing drafts
Date: Wed, 27 Feb 2002 11:55:34 +0100

You answer Greg Bernstein:
 
> > (2) On  draft-ietf-ccamp-ospf-gmpls-extensions-04.txt:
> > (a) Why does Cisco get a set of reserved sub-TLVs? 
> > 32768-32772 - Reserved for Cisco-specific extension.
> 
> The draft defines several new sub-TLVs, but includes all the sub-TLVs
> from the original TE draft so that there is one place to see all of
> them, and to check for conflicts.  This draft *doesn't* define these
> sub-TLVs -- where were you when the OSPF TE draft went through Last
> Call *twice*? :-)
> 
> But to answer your question, I believe the ADs are looking into that.
> 
If you mean the Cisco reserved allocations, then YES we are checking that.
It should not be in any stds track RFC. I am checking with Routing ADs.
But is Greg not asking for something else too?
It is not clear to me.

Bert

Delivery-date: Wed, 27 Feb 2002 02:28:25 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 27 Feb 2002 10:27:23 -0000

Ping/Loa,

Can you please be more specific about the 'problem' you are talking =
about
here.....and are you both talking about the same problem or different
problems?  It would help me at least understand better if you can =
explain:
-	what is the problem?
-	what is the impact on customers?
-	how does the operator detect detect the problem in the 1st place?
-	how does tunneltrace diagnose the problem?
-	what are the expected consequent actions to fix it?

thanks, Neil

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: 27 February 2002 08:53
> To: Ping Pan
> Cc: 'Kireeti Kompella'; [email-masked]; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02
>=20
>=20
> All,
>=20
>=20
> don't know if my opinion registred in this show of hands. Anyway I =
say
> (a). It is an identified problem, we need to deal with it and=20
> by making
> a WG doc, the working groupd can start working with it.
>=20
> /Loa
>=20
> Ping Pan wrote:
>=20
> > Kireeti,
> >=20
> >=20
> > The requirement from Ron address the problem that we have=20
> been seen in=20
> > the network today. This is an issue that we have to deal=20
> with it NOW. I=20
> > vote (a).
> >=20
> > - Ping
> >=20
> >=20
> >>> -----Original Message-----
> >>> From: Kireeti Kompella [mailto:[email-masked]]
> >>> Sent: Sunday, February 24, 2002 7:47 PM
> >>> To: David Allan
> >>> Cc: [email-masked]; [email-masked];=20
> [email-masked]
> >>> Subject: RE: draft-bonica-tunneltrace-02
> >>>
> >>>
> >>>
> >>> Let me say a few words:
> >>>
> >>> 1) There was good support for this work (the requirements doc) to
> >>>   be a WG document at a previous IETF.  It is a good thing to
> >>>   follow up and check what the mailing list thinks, as=20
> not everyone
> >>>   attends IETFs.
> >>>
> >>> 2) It is interesting that no one brought up the issue of=20
> whether this
> >>>   work (tunnel tracing) is in the charter or not at the meeting.
> >>>   There are those who think the charter isn't explicit=20
> enough.  I'll
> >>>   talk to the ADs and see (a) if they think that this *is* in the
> >>>   charter; (b) if not, are they willing to take it to the IESG =
and
> >>>   add it to the charter.
> >>>
> >>>   My input on this (as WG chair) is that CCAMP is all=20
> about tunnels,
> >>>   and a protocol to debug and test tunnels is well within=20
> scope, even
> >>>   if not called out explicitly.
> >>>
> >>>   Note that the charter is *not* subject to WG consensus, nor =
even
> >>>   the WG chairs.  The IESG (and IAB?) are solely responsible,
> >>>   although the WG and chairs can suggest changes.
> >>>
> >>> 3) A document that is "in the right spirit" can become a=20
> WG document,
> >>>   even if there are disagreements about some details, and even
> >>>   "fundamental" questions.  Note that "fundamental" is often
> >>>   subjective.
> >>>
> >>> I would like to have the mailing list equivalent of a=20
> 'show of hands'
> >>> regarding this draft.  Do you think:
> >>> (a) it should be a WG document?
> >>> (b) it's good stuff, but not ready?
> >>> (c) we need a new start?
> >>>
> >>> Please send in your opinions with one of the above up top.  Any
> >>> detailed reasoning you have for your opinion may follow.
> >>>
> >>> Thanks!
> >>> Kireeti.
> >>>
> >>>
> >>>
> >>
> >=20
> >=20
> >=20
>=20
>=20
> --=20
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> R=E5sundav=E4gen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           [email-masked]
> WWW             www.utfors.se
>=20
>=20

Delivery-date: Wed, 27 Feb 2002 01:34:41 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: FW: Choices in IETF Protocols
Date: Wed, 27 Feb 2002 10:33:45 +0100

I would like to comment on a piece of an email from Eric

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 6:45 PM
> To: 'Stephen Trowbridge'; [email-masked]
> Cc: 'Heiles Juergen'; [email-masked]'; 
> [email-masked]'; ccamp-wg;
> [email-masked]'; 'Kireeti Kompella'
> Subject: RE: Simple solution to terminate the discussion about SONET
> versu s SDH
Eric responds to Steve Trowbridge:
> 
> 
> > To have a standard, you make a choice and write it down so 
> > you can interoperate.
> 
> you are probably not aware of what profiles or implementation 
> agreements are (you don't have the same for SDH). 
>
I don't think we have much of the above in the IETF

> GMPLS is full of choices (options).

Which I think is VERY BAD

> Which signaling are you going to use: RSVP-TE or CR-LDP?
> Which routing protocol are you going to choose?
> The IETF RFCs are full of choices (options).

Which is I think BAD too. We should try to come to agreement
as to what the best standard way of doing things is.

> You never want to believe me when I told you that GMPLS is a 
> toolbox. Pick the tools you need, forget the others.
> If you disagree with this approach it is your right,
> but it is a common approach taken by many standardization
> bodies. Your freedom stops where my freedom is starting.
>
Other standards bodies can do whatever they please.
Here we are a WG in the IETF.

We may have applicability statements that explain that possibly
we have multiple protocol choices in different environments.
But in principle we try to not define a whole set of choices
that people can pick from. We may not always have succeeded.

RFC1958, sections 3.2, 3.5, 3.8 are important points to remember.

In general we (IETF) try to minimize the number of options, because
many options reduce the chances of good interoperability. Two
boxes that implement a protocol may not interoperate if they chose
different sets of options.

Note that RFC2026 tells us that if we have options that are
not implemented in an interoperable way in at least two genetically
independent implementations, then such options must be deprecated,
obsoleted or removed when you want to advance on the standards
track (i.e from PS to DS or from DS to STD)

Bert  

Delivery-date: Wed, 27 Feb 2002 01:18:35 -0800
Date: Wed, 27 Feb 2002 14:45:49 +0530
From: S Ramesh <[email-masked]>
Organization: HCL Technologies Limited
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: ccamp-wg <[email-masked]>
Subject: Re: LMP

Also, In LMP why do we need a IPv6 extension for interface ID.
Interface ID is a logical identifier that identifies a specific port.
In in-fiber signalling where the control channel is within the data
channel there is no need for having seperately two ID's for a same
physical link ( which contains the control channel as well as data
link ). The CCID can be the same as the Interface ID in this case.(
Mentioned in OIF UNI too ).

If so, then if the Interface ID is a IPv6 address means how it can be
used as CCID too, because the CCID is a 32bit field.

Does that means there will be two seperate IDs of termination, even
the control channel and data channel are within the same fiber. Is
this acceptable?

Thanks
Ramesh

"Wijnen, Bert (Bert)" wrote:

> When I look at section 14, then I wonder:
>
>   LOCAL_CCID:  Class = 1, C-Type = 1, 4 byte CC_id
>   REMOTE_CCID: Class = 2, C-Type = 1, 4 byte CC_id
>
> Why is that not:
>
>   CCID: Class = 1, LOCAL: C-Type = 1, 4 byte CC_id
>   CCID: Class = 1, LOCAL: C-Type = 2, 4 byte CC_id
>
> The above is just an example. this is type of definitions
> occur throughout section 14, and it seems we are using
> many more name space code points than really needed.
> Is this handy? Wise? Good design?
>
> Bert

Delivery-date: Wed, 27 Feb 2002 00:53:09 -0800
Date: Wed, 27 Feb 2002 09:52:36 +0100
From: Loa Andersson <[email-masked]>
To: Ping Pan <[email-masked]>
CC: 'Kireeti Kompella' <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

All,

don't know if my opinion registred in this show of hands. Anyway I say
(a). It is an identified problem, we need to deal with it and by making
a WG doc, the working groupd can start working with it.

/Loa

Ping Pan wrote:

> Kireeti,
> 
> 
> The requirement from Ron address the problem that we have been seen in 
> the network today. This is an issue that we have to deal with it NOW. I 
> vote (a).
> 
> - Ping
> 
> 
>>> -----Original Message-----
>>> From: Kireeti Kompella [mailto:[email-masked]]
>>> Sent: Sunday, February 24, 2002 7:47 PM
>>> To: David Allan
>>> Cc: [email-masked]; [email-masked]; [email-masked]
>>> Subject: RE: draft-bonica-tunneltrace-02
>>>
>>>
>>>
>>> Let me say a few words:
>>>
>>> 1) There was good support for this work (the requirements doc) to
>>>   be a WG document at a previous IETF.  It is a good thing to
>>>   follow up and check what the mailing list thinks, as not everyone
>>>   attends IETFs.
>>>
>>> 2) It is interesting that no one brought up the issue of whether this
>>>   work (tunnel tracing) is in the charter or not at the meeting.
>>>   There are those who think the charter isn't explicit enough.  I'll
>>>   talk to the ADs and see (a) if they think that this *is* in the
>>>   charter; (b) if not, are they willing to take it to the IESG and
>>>   add it to the charter.
>>>
>>>   My input on this (as WG chair) is that CCAMP is all about tunnels,
>>>   and a protocol to debug and test tunnels is well within scope, even
>>>   if not called out explicitly.
>>>
>>>   Note that the charter is *not* subject to WG consensus, nor even
>>>   the WG chairs.  The IESG (and IAB?) are solely responsible,
>>>   although the WG and chairs can suggest changes.
>>>
>>> 3) A document that is "in the right spirit" can become a WG document,
>>>   even if there are disagreements about some details, and even
>>>   "fundamental" questions.  Note that "fundamental" is often
>>>   subjective.
>>>
>>> I would like to have the mailing list equivalent of a 'show of hands'
>>> regarding this draft.  Do you think:
>>> (a) it should be a WG document?
>>> (b) it's good stuff, but not ready?
>>> (c) we need a new start?
>>>
>>> Please send in your opinions with one of the above up top.  Any
>>> detailed reasoning you have for your opinion may follow.
>>>
>>> Thanks!
>>> Kireeti.
>>>
>>>
>>>
>>
> 
> 
> 

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

Delivery-date: Wed, 27 Feb 2002 00:29:48 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: LMP
Date: Tue, 26 Feb 2002 23:26:00 +0100

When I look at section 14, then I wonder:

  LOCAL_CCID:  Class = 1, C-Type = 1, 4 byte CC_id
  REMOTE_CCID: Class = 2, C-Type = 1, 4 byte CC_id

Why is that not:

  CCID: Class = 1, LOCAL: C-Type = 1, 4 byte CC_id
  CCID: Class = 1, LOCAL: C-Type = 2, 4 byte CC_id

The above is just an example. this is type of definitions
occur throughout section 14, and it seems we are using
many more name space code points than really needed. 
Is this handy? Wise? Good design?

Bert 

Delivery-date: Wed, 27 Feb 2002 00:26:40 -0800
From: Heiles Juergen <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: RE: Simple solution to terminate the discussion about SONET versu s SDH
Date: Wed, 27 Feb 2002 09:22:59 +0100

Eric,

the point is that you cannot say SONET uses all these overhead options and SDH uses all the other overhead options. So no specific SONET and SDH profiles exist, both can come with a mixture of OH options. You find for example for both equipment that supports only an one byte J0 or equipment that supports a 16 byte J0 string. SDH as a superset covers the SONET definitions.
Saying just SONET or SDH doesn't provide interworking at all.

Regards

Juergen

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 5:31 PM
> To: 'Stephen Trowbridge'
> Cc: 'Heiles Juergen'; [email-masked]'; Wijnen, Bert (Bert);
> [email-masked]'; ccamp-wg; [email-masked]'; 'Kireeti Kompella'
> Subject: RE: Simple solution to terminate the discussion about SONET
> versu s SDH
> 
> 
> Stephen,
> 
> Of course SDH and SONET are interoperable and can be 
> interconnected. You buy
> a gateway and it is done. 
> 
> I spoke about the fact that in the control plane we should 
> know if a signal
> is using the SONET "profile" or the SDH "profile". Otherwise 
> you cannot
> achieve automatically what you described hereafter.
> 
> If at one end you generate a J1 on 64 bytes with the SONET 
> profile you need
> to interpret it at the other end as specified in the SONET 
> "profile", not
> using the SDH "profile" on 16 byte format. You cannot assume that all
> existing SONET boxes (speaking GMPLS or not) will know that 
> the other end is
> SDH. This is just one example. I think that this is now clear 
> for everybody.
> 
> Also due to a lot of legacy boxes at the network periphery, 
> SS conversion is
> still needed somewhere. These legacy boxes will not speak 
> GMPLS, but they
> will be the source of paths that will fly over GMPLS clouds 
> and that could
> even be terminated on GMPLS nodes. When signaling the LSP 
> (SNC) initiated on
> a SONET cloud and terminated in an SDH could you need to go 
> through a SS
> conversion. So you need to make a distinction between the SDH 
> and SONET
> "profiles".
> 
> Having a the same LSP Encoding Type for SDH/SONET is not 
> general enough and
> will not cover the cases where some cloud ignore that the 
> other end is SDH.
> Having a different LSP encoding type for SONET and SDH is 
> just identifying
> the profile to use. It doesn't prevent you to request an SDH 
> signal from any
> box to any box, if supported. It doesn't prevent any interoperability.
> 
> By the way we could may be add to your list other possible 
> differences in
> J0, K1/K2, E1 (?), F1 (?), E2, maybe S1 and M1 ?, etc. Just 
> taking a list
> from a tutorial without checking in details.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 4:22 PM
> To: Mannie, Eric
> Cc: 'Heiles Juergen'; [email-masked]'; Wijnen, Bert (Bert);
> [email-masked]'; ccamp-wg; [email-masked]'; 'Kireeti Kompella'
> Subject: Re: Simple solution to terminate the discussion about SONET
> versus SDH
> 
> 
> Eric,
> I don't think you ask quite the right question.
> The right question is:
> Can all frame structures which are common to SONET and SDH be
> interconnected,
> and do they interoperate? This is what we care about from the 
> viewpoint of
> establishing switched connections.
> The answer to this is YES.
> 
> Are they fully identical from all points of view? As Juergen 
> says, this is
> the
> tricky question, as the answer of "No" might mislead some 
> into thinking that
> these signals cannot be interconnected between SONET and SDH. 
> This is not
> the case.
> 
> For those who care, some of the key differences are as 
> follows. Note that
> these
> do NOT affect the ability to interconnect these signals 
> (although sometimes
> there
> are rules about HOW to interconnect them).
> 
> SS bits - In the past, this was an issue in the high order 
> pointers. SDH
> sent
> and expected "10", for SONET these bits were unspecified. 
> This problem was
> corrected
> a few years ago by requiring that ALL equipment send "10" and 
> ignore the
> incoming
> bits. Note that even prior to aligning the standards, a great 
> deal of the
> older
> equipment followed this strategy as VC-4s and STS-3cs were 
> interconnected
> long
> before the standards alignment.
> 
> Trace identifier - For J1, within SONET, a 64 byte format is 
> normally used.
> For SDH,
> a 16 byte format is normally used. SONET specifies that in 
> the case that the
> far end
> is SDH, a 16 byte format should be used to allow 
> interworking. For J2, this
> is normally
> used in SDH and not normally in SONET. Interworking is 
> acheived by having
> the SDH end
> ignore the incoming trace identifier (a required capability in the
> standards).
> 
> RDI - SONET uses some extra bits that are reserved in SDH to further
> classify far end
> alarms (called ENHANCED RDI). This provides no obstacle to 
> interworking: The
> SONET
> side will not be able to provide a more detailed 
> classification of SDH end
> alarms (it
> does know there is a far end alarm). The SDH end ignores the 
> extra bits. The
> Enhanced
> RDI feature only operates if both ends are SONET.
> 
> BIP - The coding for BIP is identical. The way degrade is detected is
> different.
> SONET generally uses a Poisson algorithm to declare degrade 
> and SDH normally
> uses
> a bursty error detection algorithm. This provides no obstacle to
> interconnect - the
> criteria for declaring dDEG is just slightly different. Also, 
> SONET provides
> an
> EXC alarm for BER > 10^-3 which does not appear in SDH. This 
> also does not
> prevent
> interconnect - you just have an alarm which can be declared 
> at one end and
> not the
> other.
> 
> These are the major differences (besides the fact that SONET 
> and SDH tend to
> have
> different names for identical things- This is just a 
> US/Europe language
> issue).
> Regards,
> Steve
> 
> "Mannie, Eric" wrote:
> > 
> > Dear All,
> > 
> > There is an easy way to stop definitively this discussion based on
> technical
> > facts:
> > 
> > Stephen, Juergen and Maarten, please tell us: today, are the frame
> > structures and all the bytes in the SDH and SONET overhead 
> completely
> > identical, used and interpreted in the same way, is the 
> monitoring exactly
> > the same ? In particular, if I provision and operate an SDH 
> circuit/LSP is
> > this fully identical to a SONET circuit/LSP from *all* 
> point of views ?
> > 
> > PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not 
> needed at this
> > stage.
> > 
> > If the answer is yes: SONET is totally identical to SDH.
> > If the answer is no: SONET is not the same as SDH.
> > 
> > I think that without that answer we cannot take any 
> *technical* decision
> on
> > this mailing list and at the IETF.
> > 
> > Thanks to answer.
> > 
> > Kind regards,
> > 
> > Eric
> > 
> > ps: feel free to forward this e-mail to any ITU-T mailing list if a
> > confirmation is needed.
> 

Delivery-date: Tue, 26 Feb 2002 22:04:30 -0800
Date: Tue, 26 Feb 2002 22:03:22 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Ben Mack-Crane <[email-masked]>
cc: [email-masked]
Subject: Re: WG dcoument status

Hi Ben,

On Tue, 26 Feb 2002, Ben Mack-Crane wrote:

> Regarding the generalized signaling draft, I submitted
> several comments after the last IETF identifying technical
> issues

WG Last Call for this draft is over.  And over.  And over.  It's
DONE.  Consensus was rather rough.  That's a pity -- it would be
nice to make everyone happy.

Right now, the only issue on the signaling front is the SDH/SONET
label issue.  And that's a _different_ draft.

Kireeti.

Delivery-date: Tue, 26 Feb 2002 21:53:08 -0800
Date: Tue, 26 Feb 2002 21:52:21 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Bernstein, Greg" <[email-masked]>
cc: [email-masked]
Subject: RE: Routing drafts

Hi Greg,

On Mon, 25 Feb 2002, Bernstein, Greg wrote:

> (1) On draft-ietf-ccamp-gmpls-routing-02.txt -- Section 6 is where all the
> new material gets covered and is very important.  Can we pull the examples
> of sections 6.4.9 and 6.4.10 into a separate section (i.e., section 7) since
> they are quite lengthy and optional reading.  This draft contains the
> important concepts of Link protection type, Link Mux capability and SRLGs
> and should move forward.

Good observation.  I'll ping the editor.

> (2) On  draft-ietf-ccamp-ospf-gmpls-extensions-04.txt:
> (a) Why does Cisco get a set of reserved sub-TLVs? 32768-32772 - Reserved
> for Cisco-specific extension.

The draft defines several new sub-TLVs, but includes all the sub-TLVs
from the original TE draft so that there is one place to see all of
them, and to check for conflicts.  This draft *doesn't* define these
sub-TLVs -- where were you when the OSPF TE draft went through Last
Call *twice*? :-)

But to answer your question, I believe the ADs are looking into that.

> (b) Big issue -- The parameters for representing bandwidth on a link are not
> very appropriate for TDM signals or WDM signals.  I've included below some
> more explanation taken from the IPO working group draft. However, this is
> the same thing that led to us breaking out the traffic descriptor stuff in
> GMPLS signaling for the SONET/SDH case.  This is really needed here too.

I don't know that this is _really needed_.  Note that the bandwidth
encoding in signaling is a floating point number.  Perhaps this isn't
the most aesthetic way of carrying TDM signal information, but it works
adequately.  Is it worth carrying the information differently in
signaling and in routing, and differently for each switching type?
What is the tangible gain?

Which is not to say we can't discuss this.

Kireeti.

Delivery-date: Tue, 26 Feb 2002 21:29:05 -0800
Date: Tue, 26 Feb 2002 21:28:17 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Vishal Sharma <[email-masked]>
cc: [email-masked], Greg Bernstein <[email-masked]>, Eric Mannie <[email-masked]>
Subject: RE: WG dcoument status

Hi Vishal,

On Mon, 25 Feb 2002, Vishal Sharma wrote:

> There was one more document:
> "Framework for GMPLS Control of SDH/SONET Networks"

Informational track.  Produce another version (as I hear you are
going to) and then we'll check for consensus for WG Last Call.

Kireeti.

Delivery-date: Tue, 26 Feb 2002 21:02:00 -0800
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "ccamp-wg" <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>, "Mannie, Eric" <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 23:56:24 -0500

Kireeti,

Given what Bert has said, I vote for (4).

Namely, that we use the same set of traffic parameters
and label values where the signals in the two hierarchies
are identical (this overlap depends of course on the specific signals
one is requesting, including the level of transparency).

For those signals that are not identical, we use encodings
appropriate to the relevant (SONET or SDH) hierarchy.

Thanks,
-Vishal 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Wijnen, Bert (Bert)
> Sent: Tuesday, February 26, 2002 7:40 AM
> To: Mannie, Eric; ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> If people want to express their support for this 4th option
> then that is fine with me. WG chair(s) do you agree too
> (don't want to step on your toes or sit in your chair).
> 
> Bert 
> 
> > -----Original Message-----
> > From: Mannie, Eric [mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 11:32 AM
> > To: 'Wijnen, Bert (Bert)'; ccamp-wg
> > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> > 
> > 
> > Hello Bert and all,
> > 
> > One question is missing:
> > 
> > 4) Do you think we should have just a single set of traffic 
> > parameters and
> > label format (values) for both SDH and SONET.
> > 
> > In 1) "none for SONET" assumes that SONET doesn't exist 
> > anymore. Note also
> > that the traffic parameters are already identical, the only 
> > difference is
> > about the label. As editor of these drafts I would like at 
> > least to see the
> > right questions asked on the mailing list.
> > 
> > Kind regards,
> > 
> > Eric
> > 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 10:37 AM
> > To: ccamp-wg
> > Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> > 
> > 
> > CCAMP WG members, 
> > 
> > before we start down another many 100s of emails re-discussing
> > the same topic....
> > 
> > PLEASE express your support for one of the 3 options that Kireeti
> > posed to the WG. Don't elaborate... just help the WG chair(s) to
> > figure out the (rough) consensus of the WG. The choices formulated
> > by Kireeti:
> > 
> > > So, here we are again, arguing over this.  Let's follow the AD's
> > > suggestion and look for consensus in the WG.
> > > 
> > > 1) Do you think we should have just a single set of traffic 
> > parameters
> > >    and label values for SDH, and none for SONET?
> > > or
> > > 2) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one SHOULD
> > >    use the SDH equivalent?
> > > or
> > > 3) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one MUST
> > >    use the SDH equivalent?
> > > 
> > > (in the above, SHOULD and MUST are to be interpreted as in 
> > RFC 2119.)
> > > 
> > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> > 
> > Thanks
> > Bert, speaking as AD who would like to see the WG take 
> >       a decision on this topic.
> > 

Delivery-date: Tue, 26 Feb 2002 17:16:02 -0800
Date: Tue, 26 Feb 2002 19:52:45 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

option 1

Zhi

Wijnen, Bert (Bert) wrote:

> CCAMP WG members, 
> 
> before we start down another many 100s of emails re-discussing
> the same topic....
> 
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
> 
> 
>>So, here we are again, arguing over this.  Let's follow the AD's
>>suggestion and look for consensus in the WG.
>>
>>1) Do you think we should have just a single set of traffic parameters
>>   and label values for SDH, and none for SONET?
>>or
>>2) Do you think we should have one for SONET and one for SDH, with
>>   the proviso that, if an SDH equivalent is available, one SHOULD
>>   use the SDH equivalent?
>>or
>>3) Do you think we should have one for SONET and one for SDH, with
>>   the proviso that, if an SDH equivalent is available, one MUST
>>   use the SDH equivalent?
>>
>>(in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
>>
>>PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>>
> 
> Thanks
> Bert, speaking as AD who would like to see the WG take 
>       a decision on this topic.
> 
> 

Delivery-date: Tue, 26 Feb 2002 16:54:42 -0800
From: Dan Guo <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 16:51:03 -0800

2)
-Dan

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Sunday, February 24, 2002 4:11 PM
To: Wijnen, Bert (Bert)
Cc: Mannie, Eric; [email-masked]'; [email-masked]'; ccamp-wg;
[email-masked]'
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:

> Guys... I have seen to much of this. I have asked Kireeti
> EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> WG mailing list. I do NOT want another 500 emails going back
> and forth on this issue. We need to approach this pragmatically.
> 
> - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the 
>   WG mailing list on what exactly we agreed in SLC. That will
>   help to prepare a response to ITU-T as well

First off, I should apologize for letting this go on unchecked.

Second, I should make it known to the WG as a whole that there was
a discussion of this issue at SLC among several folks directly
involved, the ADs and the chairs.  I thought we had achieved
consensus, but now it seems not.

Here's what I thought we had agreed:

1) There is a document in the ITU that defines a *single* standard that
   encompasses both SONET and SDH -- almost.  There are a few signals
   that are in SONET but not in SDH; it was believed that the only such
   signal was VC-3.  Also, there are "legacy" implementations of SONET
   that do not match the ITU document.

2) Thus, it was agreed (to my recollection) that both the SONET and
   SDH label formats will be retained, with wording that says that
   whenever possible, the SDH equivalent should be used.  This covers
   both the cases of SONET signals that don't have SDH equivalents,
   and legacy equipment.

It is *not* the IETF's intention to promote an artificial separation
between SONET and SDH.  Nor is it the intent to promote as standard
work that is now "pre-standard".

However, it *is* the IETF's goal to be able to set up paths across
SONET and SDH networks, and to be pragmatic about this.  This was
the spirit in which an agreement was forged -- or so I thought.  In
retrospect, it would have been wise to go one step further and
decide the actual words.

So, here we are again, arguing over this.  Let's follow the AD's
suggestion and look for consensus in the WG.

1) Do you think we should have just a single set of traffic parameters
   and label values for SDH, and none for SONET?
or
2) Do you think we should have one for SONET and one for SDH, with
   the proviso that, if an SDH equivalent is available, one SHOULD
   use the SDH equivalent?
or
3) Do you think we should have one for SONET and one for SDH, with
   the proviso that, if an SDH equivalent is available, one MUST
   use the SDH equivalent?

(in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)

PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Feedback is welcome from *all* those interested in the CCAMP WG.
Also, what we are looking for is rough consensus, not votes.

Thanks,
Kireeti.

Delivery-date: Tue, 26 Feb 2002 16:54:40 -0800
Date: Wed, 27 Feb 2002 09:52:39 +0900
To: Kireeti Kompella <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
From: Tomohiro Otani <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Cc: "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>

Dear Kireeti,

We basically support 2), but we may not care it if the operation can be
conducted appropriately.

Regards,

TOMOHIRO OTANI

>So, here we are again, arguing over this.  Let's follow the AD's
>suggestion and look for consensus in the WG.
>
>1) Do you think we should have just a single set of traffic parameters
>   and label values for SDH, and none for SONET?
>or
>2) Do you think we should have one for SONET and one for SDH, with
>   the proviso that, if an SDH equivalent is available, one SHOULD
>   use the SDH equivalent?
>or
>3) Do you think we should have one for SONET and one for SDH, with
>   the proviso that, if an SDH equivalent is available, one MUST
>   use the SDH equivalent?
>
>(in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
>
>PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
>Feedback is welcome from *all* those interested in the CCAMP WG.
>Also, what we are looking for is rough consensus, not votes.
>
>Thanks,
>

------------------------------------
Tomohiro Otani
KDDI R&D Laboratories, Inc.
Optical network lab.
2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan
TEL: +1-49-278-7357
FAX: +1-49-278-7516
E-mail: [email-masked]
------------------------------------

Delivery-date: Tue, 26 Feb 2002 16:26:58 -0800
From: "Cheng, Dean" <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 16:23:10 -0800

2)

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Sunday, February 24, 2002 4:11 PM
> To: Wijnen, Bert (Bert)
> Cc: Mannie, Eric; [email-masked]'; [email-masked]'; ccamp-wg;
> [email-masked]'
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> 
> 
> On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:
> 
> > Guys... I have seen to much of this. I have asked Kireeti
> > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> > WG mailing list. I do NOT want another 500 emails going back
> > and forth on this issue. We need to approach this pragmatically.
> > 
> > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the 
> >   WG mailing list on what exactly we agreed in SLC. That will
> >   help to prepare a response to ITU-T as well
> 
> First off, I should apologize for letting this go on unchecked.
> 
> Second, I should make it known to the WG as a whole that there was
> a discussion of this issue at SLC among several folks directly
> involved, the ADs and the chairs.  I thought we had achieved
> consensus, but now it seems not.
> 
> Here's what I thought we had agreed:
> 
> 1) There is a document in the ITU that defines a *single* 
> standard that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the 
> only such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET
>    that do not match the ITU document.
> 
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
> 
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
> 
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
> 
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
> 
> Thanks,
> Kireeti.
> 
> 

Delivery-date: Tue, 26 Feb 2002 15:31:50 -0800
Date: Tue, 26 Feb 2002 18:30:17 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

 "1"

Yangguang

Ayan Banerjee wrote:
> 
> Vote for 2.
> 
> Ayan
> 
> >  -----Original Message-----
> >From:   Wijnen, Bert (Bert)
> >[<mailto:[email-masked]>mailto:[email-masked]]
> >Sent:   Tuesday, February 26, 2002 4:37 AM
> >To:     ccamp-wg
> >Subject:        RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> >
> >CCAMP WG members,
> >
> >before we start down another many 100s of emails re-discussing
> >the same topic....
> >
> >PLEASE express your support for one of the 3 options that Kireeti
> >posed to the WG. Don't elaborate... just help the WG chair(s) to
> >figure out the (rough) consensus of the WG. The choices formulated
> >by Kireeti:
> >
> > > So, here we are again, arguing over this.  Let's follow the AD's
> > > suggestion and look for consensus in the WG.
> > >
> > > 1) Do you think we should have just a single set of traffic parameters
> > >    and label values for SDH, and none for SONET?
> > > or
> > > 2) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one SHOULD
> > >    use the SDH equivalent?
> > > or
> > > 3) Do you think we should have one for SONET and one for SDH, with
> > >    the proviso that, if an SDH equivalent is available, one MUST
> > >    use the SDH equivalent?
> > >
> > > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> > >
> > > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> >
> >Thanks
> >Bert, speaking as AD who would like to see the WG take
> >       a decision on this topic.

Delivery-date: Tue, 26 Feb 2002 14:08:30 -0800
Date: Tue, 26 Feb 2002 17:06:18 -0500
From: Siva Sankaranarayanan <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Hi Kireeti,
   I vote for (1).

Siva.

>>Kireeti Kompella wrote:
>>snip
>>
>>>
>>> Let's follow the AD's
>>>suggestion and look for consensus in the WG.
>>>
>>>1) Do you think we should have just a single set of traffic parameters
>>>   and label values for SDH, and none for SONET?
>>>or

Delivery-date: Tue, 26 Feb 2002 13:36:25 -0800
Date: Tue, 26 Feb 2002 13:32:34 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

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

I vote for (2)

Kireeti Kompella wrote:

>
>
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
>
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
>
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
>
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
>
> Thanks,
> Kireeti.

--------------3F2935D6FC685171F786E0E6
Content-Type: text/x-vcard; charset=us-ascii;
 name="sudheer.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Sudheer Dharanikota
Content-Disposition: attachment;
 filename="sudheer.vcf"

begin:vcard 
n:Dharanikota;Sudheer
tel;work:408-956-8000 x357
x-mozilla-html:FALSE
url:http://www.cs.odu.edu/~sudheer
org:Nayna Networks Inc.;CTO's office
version:2.1
email;internet:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard

--------------3F2935D6FC685171F786E0E6--

Delivery-date: Tue, 26 Feb 2002 13:28:25 -0800
From: Ayan Banerjee <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 13:27:56 -0800

Vote for 2.

Ayan

>  -----Original Message-----
>From:   Wijnen, Bert (Bert) 
>[<mailto:[email-masked]>mailto:[email-masked]]
>Sent:   Tuesday, February 26, 2002 4:37 AM
>To:     ccamp-wg
>Subject:        RE: SONET/SDH label agreement for IETF, ITU-T and OIF
>
>CCAMP WG members,
>
>before we start down another many 100s of emails re-discussing
>the same topic....
>
>PLEASE express your support for one of the 3 options that Kireeti
>posed to the WG. Don't elaborate... just help the WG chair(s) to
>figure out the (rough) consensus of the WG. The choices formulated
>by Kireeti:
>
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
>Thanks
>Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Tue, 26 Feb 2002 13:20:28 -0800
From: Debanjan Saha <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 16:04:59 -0500

Vote for 2.

Debanjan

>  -----Original Message-----
>From:   Wijnen, Bert (Bert) 
>[<mailto:[email-masked]>mailto:[email-masked]]
>Sent:   Tuesday, February 26, 2002 4:37 AM
>To:     ccamp-wg
>Subject:        RE: SONET/SDH label agreement for IETF, ITU-T and OIF
>
>CCAMP WG members,
>
>before we start down another many 100s of emails re-discussing
>the same topic....
>
>PLEASE express your support for one of the 3 options that Kireeti
>posed to the WG. Don't elaborate... just help the WG chair(s) to
>figure out the (rough) consensus of the WG. The choices formulated
>by Kireeti:
>
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
>Thanks
>Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Tue, 26 Feb 2002 11:11:55 -0800
Date: Tue, 26 Feb 2002 13:11:56 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: WG dcoument status

Bert -

Thanks for the clarification.

Jonathan Sadler

"Wijnen, Bert (Bert)" wrote:
> 
> > A process question:
> >
> > The signaling drafts currently make reference to a lot of
> > Internet-Drafts.  Specifically:
> >   draft-ietf-mpls-generalized-signaling-07.txt has 11 I-D references
> >   draft-ietf-mpls-generalized-rsvp-te-06.txt has 7 I-D references
> >   draft-ietf-mpls-generalized-cr-ldp-05 has 7 I-D references
> >
> > Since these cannot be included in a final RFC, should the signaling
> > drafts drop the reference and incorporate the text from the refered
> > document?  If not, then shouldn't both the signalling and referenced
> > drafts be progressed at one time?
> >
> > To progress the signaling drafts with normative references to
> > something that is still under development seems inappropriate...
> >
> After IESG approval, they will stay "pending for normative references"
> if any of those references are not yet approved.
> It would be WRONG to copy pieces of text from other documents into these
> GMPLS docs just so they can advance. If we have normative references,
> then we better make sure and helpt to get those other I-Ds completed
> and approved as well.
> 
> By the way, the RFC-Editor wants references split in normative and
> informative these days, see :
> 
>   http://www.rfc-editor.org/policy.html
> 
> which talks about this if you scroll down a bit.
> 
> Bert
============================================================
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: Tue, 26 Feb 2002 10:24:32 -0800
Date: Tue, 26 Feb 2002 10:30:06 -0800
To: ccamp-wg <[email-masked]>
From: Suresh Katukam <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

Vote for (2)

>  -----Original Message-----
>From:   Wijnen, Bert (Bert) 
>[<mailto:[email-masked]>mailto:[email-masked]]
>Sent:   Tuesday, February 26, 2002 4:37 AM
>To:     ccamp-wg
>Subject:        RE: SONET/SDH label agreement for IETF, ITU-T and OIF
>
>CCAMP WG members,
>
>before we start down another many 100s of emails re-discussing
>the same topic....
>
>PLEASE express your support for one of the 3 options that Kireeti
>posed to the WG. Don't elaborate... just help the WG chair(s) to
>figure out the (rough) consensus of the WG. The choices formulated
>by Kireeti:
>
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>
>Thanks
>Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

Delivery-date: Tue, 26 Feb 2002 10:24:14 -0800
Date: Tue, 26 Feb 2002 19:21:57 +0100
From: [email-masked]
Organization: Alcatel Bell - IPO NA (Antwerpen)
To: Stephen Trowbridge <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Re: Simple solution to terminate the discussion about SONET versus SDH

Stephen,

imho, i don't think the issue is when interop is there at the 
transport plane level; the issue is when interop is not there 
at the transport plane level and one tries to achieve abstract
uniformity at the control plane level. This generates control
processing changes within the current implementation since you
will imply a negotiation phase prior to the connection setup.
(refer to the example provided by Eric, for instance); so, the 
key issue is to know if the current "profiles" are enough in 
order to avoid this additional signalling message exchange.
That's what i call "pragmatic evolutionary scenario", in brief
put additional implementation efforts where needed at the time
they are needed; here your option would have to be translated 
into additional message implementation and coding, and i am 
not so sure, that compared to adding additional values for an
existing structure (ie the label) you are promoting the most
pragmatic solution.

Hope this clarifies,
- dimitri.

Stephen Trowbridge wrote:
> 
> Dimitri,
> Perhaps we were not precise enough in spoken language in reaching
> our "agreement" in SLC. We discussed that we would use the SDH coding
> in the cases where we had identical multiplex structures between
> SONET and SDH. I came away thinking that this translated to "shall",
> and obviously some others thought it translated to "should". For
> those of us who understood "shall", we then move to the followup
> discussion that SONET is a subset of SDH and therefore there are no
> cases where a SONET multiplex structure exists that is not also
> in SDH, so we use only SDH codings (leaving aside the VT3 case
> which is not real, and if it were, would be added to G.707).
> 
> By "pragmatic evolutionary scenario", it seems that you are proposing
> to leave in place dual codings that impede interworking to preserve
> or protect pre-standard implementations. I believe that the purpose
> of a standard is to allow interworking, not to protect pre-standard
> implementations.
> 
> In an earlier email of Eric's, I see also:
> > If we give you a solution that does what you want to do, plus in addition
> > what some other people want to do, why are you complaining ????
> I am complaining because a document that simply lists all of the different
> things that different people want to do is not a standard - it is just a
> catelogue of everyone's proprietary choices. To have a standard, you
> make a choice and write it down so you can interoperate.
> Regards,
> Steve
> 
> [email-masked] wrote:
> >
> > That's probably the issue here, i see lot of response with respect
> > to the last status that has been achieved over years at bodies like
> > the T1X1/ITU-T (and ETSI) to improve interoperability between Sonet
> > and SDH; the option (2) doesn't at all preclude this, it give us the
> > capability to have a more pragmatic evolutionary scenario. That's
> > also the paradox, i see people coming from the transmission world
> > having an idealistic view on transmission networks (and control plane)
> > while they know it will take years to achieve full interop; this while
> > others have a real pragmatic view on what short/mid-term needs are/
> > will be.
> >
> > The option 2) takes into account current install base (with GMPLS
> > soft update) and future needs - we don't even have to discuss in
> > detail here the specifics btw Sonet and SDH overhead and corr.
> > processing - if the "SHOULD" must have to be clarified then let's
> > go for it.
> >
> > rgds,
> > - dimitri.
> >
> > "Mannie, Eric" wrote:
> > >
> > > Stephen,
> > >
> > > Of course SDH and SONET are interoperable and can be interconnected. You buy
> > > a gateway and it is done.
> > >
> > > I spoke about the fact that in the control plane we should know if a signal
> > > is using the SONET "profile" or the SDH "profile". Otherwise you cannot
> > > achieve automatically what you described hereafter.
> > >
> > > If at one end you generate a J1 on 64 bytes with the SONET profile you need
> > > to interpret it at the other end as specified in the SONET "profile", not
> > > using the SDH "profile" on 16 byte format. You cannot assume that all
> > > existing SONET boxes (speaking GMPLS or not) will know that the other end is
> > > SDH. This is just one example. I think that this is now clear for everybody.
> > >
> > > Also due to a lot of legacy boxes at the network periphery, SS conversion is
> > > still needed somewhere. These legacy boxes will not speak GMPLS, but they
> > > will be the source of paths that will fly over GMPLS clouds and that could
> > > even be terminated on GMPLS nodes. When signaling the LSP (SNC) initiated on
> > > a SONET cloud and terminated in an SDH could you need to go through a SS
> > > conversion. So you need to make a distinction between the SDH and SONET
> > > "profiles".
> > >
> > > Having a the same LSP Encoding Type for SDH/SONET is not general enough and
> > > will not cover the cases where some cloud ignore that the other end is SDH.
> > > Having a different LSP encoding type for SONET and SDH is just identifying
> > > the profile to use. It doesn't prevent you to request an SDH signal from any
> > > box to any box, if supported. It doesn't prevent any interoperability.
> > >
> > > By the way we could may be add to your list other possible differences in
> > > J0, K1/K2, E1 (?), F1 (?), E2, maybe S1 and M1 ?, etc. Just taking a list
> > > from a tutorial without checking in details.
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Tuesday, February 26, 2002 4:22 PM
> > > To: Mannie, Eric
> > > Cc: 'Heiles Juergen'; [email-masked]'; Wijnen, Bert (Bert);
> > > [email-masked]'; ccamp-wg; [email-masked]'; 'Kireeti Kompella'
> > > Subject: Re: Simple solution to terminate the discussion about SONET
> > > versus SDH
> > >
> > > Eric,
> > > I don't think you ask quite the right question.
> > > The right question is:
> > > Can all frame structures which are common to SONET and SDH be
> > > interconnected,
> > > and do they interoperate? This is what we care about from the viewpoint of
> > > establishing switched connections.
> > > The answer to this is YES.
> > >
> > > Are they fully identical from all points of view? As Juergen says, this is
> > > the
> > > tricky question, as the answer of "No" might mislead some into thinking that
> > > these signals cannot be interconnected between SONET and SDH. This is not
> > > the case.
> > >
> > > For those who care, some of the key differences are as follows. Note that
> > > these
> > > do NOT affect the ability to interconnect these signals (although sometimes
> > > there
> > > are rules about HOW to interconnect them).
> > >
> > > SS bits - In the past, this was an issue in the high order pointers. SDH
> > > sent
> > > and expected "10", for SONET these bits were unspecified. This problem was
> > > corrected
> > > a few years ago by requiring that ALL equipment send "10" and ignore the
> > > incoming
> > > bits. Note that even prior to aligning the standards, a great deal of the
> > > older
> > > equipment followed this strategy as VC-4s and STS-3cs were interconnected
> > > long
> > > before the standards alignment.
> > >
> > > Trace identifier - For J1, within SONET, a 64 byte format is normally used.
> > > For SDH,
> > > a 16 byte format is normally used. SONET specifies that in the case that the
> > > far end
> > > is SDH, a 16 byte format should be used to allow interworking. For J2, this
> > > is normally
> > > used in SDH and not normally in SONET. Interworking is acheived by having
> > > the SDH end
> > > ignore the incoming trace identifier (a required capability in the
> > > standards).
> > >
> > > RDI - SONET uses some extra bits that are reserved in SDH to further
> > > classify far end
> > > alarms (called ENHANCED RDI). This provides no obstacle to interworking: The
> > > SONET
> > > side will not be able to provide a more detailed classification of SDH end
> > > alarms (it
> > > does know there is a far end alarm). The SDH end ignores the extra bits. The
> > > Enhanced
> > > RDI feature only operates if both ends are SONET.
> > >
> > > BIP - The coding for BIP is identical. The way degrade is detected is
> > > different.
> > > SONET generally uses a Poisson algorithm to declare degrade and SDH normally
> > > uses
> > > a bursty error detection algorithm. This provides no obstacle to
> > > interconnect - the
> > > criteria for declaring dDEG is just slightly different. Also, SONET provides
> > > an
> > > EXC alarm for BER > 10^-3 which does not appear in SDH. This also does not
> > > prevent
> > > interconnect - you just have an alarm which can be declared at one end and
> > > not the
> > > other.
> > >
> > > These are the major differences (besides the fact that SONET and SDH tend to
> > > have
> > > different names for identical things- This is just a US/Europe language
> > > issue).
> > > Regards,
> > > Steve
> > >
> > > "Mannie, Eric" wrote:
> > > >
> > > > Dear All,
> > > >
> > > > There is an easy way to stop definitively this discussion based on
> > > technical
> > > > facts:
> > > >
> > > > Stephen, Juergen and Maarten, please tell us: today, are the frame
> > > > structures and all the bytes in the SDH and SONET overhead completely
> > > > identical, used and interpreted in the same way, is the monitoring exactly
> > > > the same ? In particular, if I provision and operate an SDH circuit/LSP is
> > > > this fully identical to a SONET circuit/LSP from *all* point of views ?
> > > >
> > > > PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not needed at this
> > > > stage.
> > > >
> > > > If the answer is yes: SONET is totally identical to SDH.
> > > > If the answer is no: SONET is not the same as SDH.
> > > >
> > > > I think that without that answer we cannot take any *technical* decision
> > > on
> > > > this mailing list and at the IETF.
> > > >
> > > > Thanks to answer.
> > > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >
> > > > ps: feel free to forward this e-mail to any ITU-T mailing list if a
> > > > confirmation is needed.
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > Address: Alcatel - Optical NA, Fr. Wellesplein, 1
> >          B-2018 Antwerpen, Belgium
> > Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

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

Delivery-date: Tue, 26 Feb 2002 10:16:59 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked], Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: WG dcoument status
Date: Tue, 26 Feb 2002 19:16:38 +0100

> A process question:
> 
> The signaling drafts currently make reference to a lot of
> Internet-Drafts.  Specifically:
>   draft-ietf-mpls-generalized-signaling-07.txt has 11 I-D references
>   draft-ietf-mpls-generalized-rsvp-te-06.txt has 7 I-D references
>   draft-ietf-mpls-generalized-cr-ldp-05 has 7 I-D references
> 
> Since these cannot be included in a final RFC, should the signaling
> drafts drop the reference and incorporate the text from the refered
> document?  If not, then shouldn't both the signalling and referenced
> drafts be progressed at one time?
> 
> To progress the signaling drafts with normative references to 
> something that is still under development seems inappropriate...
> 
After IESG approval, they will stay "pending for normative references"
if any of those references are not yet approved.
It would be WRONG to copy pieces of text from other documents into these
GMPLS docs just so they can advance. If we have normative references,
then we better make sure and helpt to get those other I-Ds completed
and approved as well.

By the way, the RFC-Editor wants references split in normative and
informative these days, see :

  http://www.rfc-editor.org/policy.html

which talks about this if you scroll down a bit.

Bert

Delivery-date: Tue, 26 Feb 2002 10:16:48 -0800
Date: Tue, 26 Feb 2002 12:11:52 -0600
From: Ben Mack-Crane <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: WG dcoument status

Kireeti,

Regarding the generalized signaling draft, I submitted
several comments after the last IETF identifying technical
issues involving bandwidth encoding, ethernet LSP encoding type,
notify message, protection info, switching type, and waveband support.
(Message IDs: <[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, and <[email-masked]>)

These have not been addressed.  In several cases I think it is not at
all clear which value of a field would be used in a given situation
or whether a field is required or not.

Without some technical feedback, it is impossible for me to determine
whether there are good reasons to keep the drafts as they are or
whether there are good reasons to change it.  In either case, the text
in the draft seems insufficient to clearly describe an interoperable
standard.

I am not convinced the draft is ready for IETF last call.

Regards,
Ben Mack-Crane

Kireeti Kompella wrote:
> 
> Here's a status update.
> 
> The signaling drafts:
>         draft-ietf-mpls-generalized-cr-ldp-05.txt
>         draft-ietf-mpls-generalized-rsvp-te-06.txt
>         draft-ietf-mpls-generalized-signaling-07.txt
>         draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> have finished WG Last Call, and will be sent on to IETF Last Call.
> They are on the track for Proposed Standard.
> 
> Bert Wijnen (AD) has suggested that there should be an implementation
> statement before these move on to IETF Last Call; the WG chairs and
> draft editors agreed.  One note: the SDH/SONET label issue must be put
> to rest before the SDH/SONET draft can move forward.  All other issues
> are now closed.
> 
> The LMP draft:
>         draft-ietf-ccamp-lmp-02.txt
> has gone through one round of WG Last Call comments and, once a
> new version has been produced incorporating these comments, will
> go through a final WG Last Call.  This is also targeted as a
> Proposed Standard.
> 
> The following draft, a companion to the above LMP document, is
> also targeted at Proposed Standard, and is still being worked on:
>         draft-ietf-ccamp-lmp-mib-00.txt
> 
> The routing drafts:
>         draft-ietf-ccamp-gmpls-routing-02.txt
>         draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
> are awaiting WG consensus for going into WG Last Call.  These
> are also targeted for Proposed Standard.  (Note that the ISIS
> draft is owned by the ISIS WG.)
> 
> The following drafts are Informational:
>         draft-ietf-ccamp-gmpls-architecture-01.txt
>         draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> They are awaiting final touches from the editor before they
> progress.
> 
> The following two documents are also being worked on:
>         draft-ietf-ccamp-oli-reqts-00.txt
>         draft-ietf-ccamp-lmp-wdm-00.txt
> The first is an Informational document; the second is aimed
> at Proposed Standard.
> 
> The MIBs are being reworked in response to comments from the AD.
> When the new versions are ready, the WG will then be asked for
> consensus to make them WG docs.
> 
> Kireeti.
============================================================
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: Tue, 26 Feb 2002 10:10:22 -0800
Date: Tue, 26 Feb 2002 12:10:47 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Routing drafts

Kireeti -

I'd like to echo Greg's concerns that the current drafts don't
adiquately provide information on what signals can be supported on a
link, adapated by a port and switched by a system.  Yes, there is a
definition for Min/Max LSP switching capability that attempts to deal
with this, but the information provided isn't precise enough.

One issue is the current switching capability descriptor cannot specify
how equipment deals with the transmux conditions that exist for DS1 (DS1
in VC-11 vs DS1 in DS3 in VC-3), VC-3 (VC-3 in AU-3 vs VC-3 in TU-3),
TUG-2 (TUG-2 in VC-3 vs TUG-2 in TUG-3), and VC-11 (VC-11 in TU-11 vs.
VC-11 in TU-12).  

As specific example, if a system reports a Max LSP of AUG-64, and a Min
LSP of VC-11, how do I know which of the 4 different ways that an VC-11
is encoded into an AUG-1 are specifically supported?  Do I assume all?

Jonathan Sadler

PS. For those not literate in SDH signal names, apply the following
mapping:
  VC-11 = VT-1.5
  VC-12 = VT2
  TUG-2 = VTG
  VC-3 = STS-1
  AUG-64 = STS-192c

Kireeti Kompella wrote:
> 
> The two drafts:
> 
> draft-ietf-ccamp-gmpls-routing-02.txt            and
> draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
> 
> are, according to the authors, ready for WG Last Call.
> 
> I would like to judge WG consensus for this.
> 
> Thanks,
> Kireeti.
============================================================
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: Tue, 26 Feb 2002 09:54:46 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Subject: RE: draft-ietf-ccamp-lmp-02.txt
Date: Tue, 26 Feb 2002 18:54:25 +0100

http://www.ietf.org/internet-drafts/draft-rescorla-sec-cons-04.txt

is a document that gives guidelines on security considerations section

Bert 

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 11:55 AM
> To: [email-masked]
> Subject: draft-ietf-ccamp-lmp-02.txt
> 
> 
> From Kireeti's "wg document status" email
> 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:[email-masked]]
> > Sent: Monday, February 25, 2002 2:52 AM
> > To: [email-masked]
> > Subject: WG dcoument status
> > 
> > 
> > Here's a status update.
> > 
> ... snip ...
> 
> > The LMP draft:
> > 	draft-ietf-ccamp-lmp-02.txt
> > has gone through one round of WG Last Call comments and, once a
> > new version has been produced incorporating these comments, will
> > go through a final WG Last Call.  This is also targeted as a
> > Proposed Standard.
> > 
> I will note that in my view, the security section will need
> serious work. I doubt that the Security ADs will sign off on the
> current text. The security section should address the risks
> and treats. It should then specify how to protect against them.
> A text like "LMP exchanges may be authenticated with MD5" (which
> is basically what you write now) seems not sufficient to me.
> 
> Bert
> 

Delivery-date: Tue, 26 Feb 2002 09:47:36 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>,  [email-masked]
Cc: 'Heiles Juergen' <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, 'Kireeti Kompella' <[email-masked]>
Subject: RE: Simple solution to terminate the discussion about SONET versu s SDH
Date: Tue, 26 Feb 2002 18:45:20 +0100

Stephen,

>> In an earlier email of Eric's, I see also:
>> If we give you a solution that does what you want to do, plus in addition
>> what some other people want to do, why are you complaining ????
>I am complaining because a document that simply lists all of the different
>things that different people want to do is not a standard - it is just a
>catelogue of everyone's proprietary choices.

I understood that proprietary means for you the stuff that *you* don't like
:-)

>To have a standard, you
>make a choice and write it down so you can interoperate.

you are probably not aware of what profiles or implementation agreements are
(you don't have the same for SDH). GMPLS is full of choices (options). Which
signaling are you going to use: RSVP-TE or CR-LDP ? Which routing protocol
are you going to choose ? The IETF RFCs are full of choices (options). You
never want to believe me when I told you that GMPLS is a toolbox. Pick the
tools you need, forget the others. If you disagree with this approach it is
your right, but it is a common approach taken by many standardization
bodies. Your freedom stops where my freedom is starting.

Kind regards,

Eric

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 6:29 PM
To: [email-masked]
Cc: Mannie, Eric; 'Heiles Juergen'; [email-masked]'; Wijnen, Bert
(Bert); [email-masked]'; ccamp-wg; [email-masked]'; 'Kireeti
Kompella'
Subject: Re: Simple solution to terminate the discussion about SONET
versus SDH

Dimitri,
Perhaps we were not precise enough in spoken language in reaching
our "agreement" in SLC. We discussed that we would use the SDH coding
in the cases where we had identical multiplex structures between
SONET and SDH. I came away thinking that this translated to "shall",
and obviously some others thought it translated to "should". For
those of us who understood "shall", we then move to the followup
discussion that SONET is a subset of SDH and therefore there are no
cases where a SONET multiplex structure exists that is not also
in SDH, so we use only SDH codings (leaving aside the VT3 case
which is not real, and if it were, would be added to G.707).

By "pragmatic evolutionary scenario", it seems that you are proposing
to leave in place dual codings that impede interworking to preserve
or protect pre-standard implementations. I believe that the purpose
of a standard is to allow interworking, not to protect pre-standard
implementations.

In an earlier email of Eric's, I see also:
> If we give you a solution that does what you want to do, plus in addition
> what some other people want to do, why are you complaining ????
I am complaining because a document that simply lists all of the different
things that different people want to do is not a standard - it is just a
catelogue of everyone's proprietary choices. To have a standard, you
make a choice and write it down so you can interoperate.
Regards,
Steve

[email-masked] wrote:
> 
> That's probably the issue here, i see lot of response with respect
> to the last status that has been achieved over years at bodies like
> the T1X1/ITU-T (and ETSI) to improve interoperability between Sonet
> and SDH; the option (2) doesn't at all preclude this, it give us the
> capability to have a more pragmatic evolutionary scenario. That's
> also the paradox, i see people coming from the transmission world
> having an idealistic view on transmission networks (and control plane)
> while they know it will take years to achieve full interop; this while
> others have a real pragmatic view on what short/mid-term needs are/
> will be.
> 
> The option 2) takes into account current install base (with GMPLS
> soft update) and future needs - we don't even have to discuss in
> detail here the specifics btw Sonet and SDH overhead and corr.
> processing - if the "SHOULD" must have to be clarified then let's
> go for it.
> 
> rgds,
> - dimitri.
> 
> "Mannie, Eric" wrote:
> >
> > Stephen,
> >
> > Of course SDH and SONET are interoperable and can be interconnected. You
buy
> > a gateway and it is done.
> >
> > I spoke about the fact that in the control plane we should know if a
signal
> > is using the SONET "profile" or the SDH "profile". Otherwise you cannot
> > achieve automatically what you described hereafter.
> >
> > If at one end you generate a J1 on 64 bytes with the SONET profile you
need
> > to interpret it at the other end as specified in the SONET "profile",
not
> > using the SDH "profile" on 16 byte format. You cannot assume that all
> > existing SONET boxes (speaking GMPLS or not) will know that the other
end is
> > SDH. This is just one example. I think that this is now clear for
everybody.
> >
> > Also due to a lot of legacy boxes at the network periphery, SS
conversion is
> > still needed somewhere. These legacy boxes will not speak GMPLS, but
they
> > will be the source of paths that will fly over GMPLS clouds and that
could
> > even be terminated on GMPLS nodes. When signaling the LSP (SNC)
initiated on
> > a SONET cloud and terminated in an SDH could you need to go through a SS
> > conversion. So you need to make a distinction between the SDH and SONET
> > "profiles".
> >
> > Having a the same LSP Encoding Type for SDH/SONET is not general enough
and
> > will not cover the cases where some cloud ignore that the other end is
SDH.
> > Having a different LSP encoding type for SONET and SDH is just
identifying
> > the profile to use. It doesn't prevent you to request an SDH signal from
any
> > box to any box, if supported. It doesn't prevent any interoperability.
> >
> > By the way we could may be add to your list other possible differences
in
> > J0, K1/K2, E1 (?), F1 (?), E2, maybe S1 and M1 ?, etc. Just taking a
list
> > from a tutorial without checking in details.
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 4:22 PM
> > To: Mannie, Eric
> > Cc: 'Heiles Juergen'; [email-masked]'; Wijnen, Bert (Bert);
> > [email-masked]'; ccamp-wg; [email-masked]'; 'Kireeti Kompella'
> > Subject: Re: Simple solution to terminate the discussion about SONET
> > versus SDH
> >
> > Eric,
> > I don't think you ask quite the right question.
> > The right question is:
> > Can all frame structures which are common to SONET and SDH be
> > interconnected,
> > and do they interoperate? This is what we care about from the viewpoint
of
> > establishing switched connections.
> > The answer to this is YES.
> >
> > Are they fully identical from all points of view? As Juergen says, this
is
> > the
> > tricky question, as the answer of "No" might mislead some into thinking
that
> > these signals cannot be interconnected between SONET and SDH. This is
not
> > the case.
> >
> > For those who care, some of the key differences are as follows. Note
that
> > these
> > do NOT affect the ability to interconnect these signals (although
sometimes
> > there
> > are rules about HOW to interconnect them).
> >
> > SS bits - In the past, this was an issue in the high order pointers. SDH
> > sent
> > and expected "10", for SONET these bits were unspecified. This problem
was
> > corrected
> > a few years ago by requiring that ALL equipment send "10" and ignore the
> > incoming
> > bits. Note that even prior to aligning the standards, a great deal of
the
> > older
> > equipment followed this strategy as VC-4s and STS-3cs were
interconnected
> > long
> > before the standards alignment.
> >
> > Trace identifier - For J1, within SONET, a 64 byte format is normally
used.
> > For SDH,
> > a 16 byte format is normally used. SONET specifies that in the case that
the
> > far end
> > is SDH, a 16 byte format should be used to allow interworking. For J2,
this
> > is normally
> > used in SDH and not normally in SONET. Interworking is acheived by
having
> > the SDH end
> > ignore the incoming trace identifier (a required capability in the
> > standards).
> >
> > RDI - SONET uses some extra bits that are reserved in SDH to further
> > classify far end
> > alarms (called ENHANCED RDI). This provides no obstacle to interworking:
The
> > SONET
> > side will not be able to provide a more detailed classification of SDH
end
> > alarms (it
> > does know there is a far end alarm). The SDH end ignores the extra bits.
The
> > Enhanced
> > RDI feature only operates if both ends are SONET.
> >
> > BIP - The coding for BIP is identical. The way degrade is detected is
> > different.
> > SONET generally uses a Poisson algorithm to declare degrade and SDH
normally
> > uses
> > a bursty error detection algorithm. This provides no obstacle to
> > interconnect - the
> > criteria for declaring dDEG is just slightly different. Also, SONET
provides
> > an
> > EXC alarm for BER > 10^-3 which does not appear in SDH. This also does
not
> > prevent
> > interconnect - you just have an alarm which can be declared at one end
and
> > not the
> > other.
> >
> > These are the major differences (besides the fact that SONET and SDH
tend to
> > have
> > different names for identical things- This is just a US/Europe language
> > issue).
> > Regards,
> > Steve
> >
> > "Mannie, Eric" wrote:
> > >
> > > Dear All,
> > >
> > > There is an easy way to stop definitively this discussion based on
> > technical
> > > facts:
> > >
> > > Stephen, Juergen and Maarten, please tell us: today, are the frame
> > > structures and all the bytes in the SDH and SONET overhead completely
> > > identical, used and interpreted in the same way, is the monitoring
exactly
> > > the same ? In particular, if I provision and operate an SDH
circuit/LSP is
> > > this fully identical to a SONET circuit/LSP from *all* point of views
?
> > >
> > > PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not needed at
this
> > > stage.
> > >
> > > If the answer is yes: SONET is totally identical to SDH.
> > > If the answer is no: SONET is not the same as SDH.
> > >
> > > I think that without that answer we cannot take any *technical*
decision
> > on
> > > this mailing list and at the IETF.
> > >
> > > Thanks to answer.
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > ps: feel free to forward this e-mail to any ITU-T mailing list if a
> > > confirmation is needed.
> 
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
> Address: Alcatel - Optical NA, Fr. Wellesplein, 1
>          B-2018 Antwerpen, Belgium
> Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 26 Feb 2002 09:31:15 -0800
Date: Tue, 26 Feb 2002 09:32:46 -0800
From: Ping Pan <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

Kireeti,

The requirement from Ron address the problem that we have been seen in 
the network today. This is an issue that we have to deal with it NOW. I 
vote (a).

- Ping

>>-----Original Message-----
>>From: Kireeti Kompella [mailto:[email-masked]]
>>Sent: Sunday, February 24, 2002 7:47 PM
>>To: David Allan
>>Cc: [email-masked]; [email-masked]; 
>>[email-masked]
>>Subject: RE: draft-bonica-tunneltrace-02
>>
>>
>>
>>Let me say a few words:
>>
>>1) There was good support for this work (the requirements doc) to
>>   be a WG document at a previous IETF.  It is a good thing to
>>   follow up and check what the mailing list thinks, as not everyone
>>   attends IETFs.
>>
>>2) It is interesting that no one brought up the issue of whether this
>>   work (tunnel tracing) is in the charter or not at the meeting.
>>   There are those who think the charter isn't explicit enough.  I'll
>>   talk to the ADs and see (a) if they think that this *is* in the
>>   charter; (b) if not, are they willing to take it to the IESG and
>>   add it to the charter.
>>
>>   My input on this (as WG chair) is that CCAMP is all about tunnels,
>>   and a protocol to debug and test tunnels is well within scope, even
>>   if not called out explicitly.
>>
>>   Note that the charter is *not* subject to WG consensus, nor even
>>   the WG chairs.  The IESG (and IAB?) are solely responsible,
>>   although the WG and chairs can suggest changes.
>>
>>3) A document that is "in the right spirit" can become a WG document,
>>   even if there are disagreements about some details, and even
>>   "fundamental" questions.  Note that "fundamental" is often
>>   subjective.
>>
>>I would like to have the mailing list equivalent of a 'show of hands'
>>regarding this draft.  Do you think:
>>(a) it should be a WG document?
>>(b) it's good stuff, but not ready?
>>(c) we need a new start?
>>
>>Please send in your opinions with one of the above up top.  Any
>>detailed reasoning you have for your opinion may follow.
>>
>>Thanks!
>>Kireeti.
>>
>>
>>
> 

Delivery-date: Tue, 26 Feb 2002 09:29:44 -0800
Date: Tue, 26 Feb 2002 10:29:07 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
CC: "Mannie, Eric" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Re: Simple solution to terminate the discussion about SONET versus SDH

Dimitri,
Perhaps we were not precise enough in spoken language in reaching
our "agreement" in SLC. We discussed that we would use the SDH coding
in the cases where we had identical multiplex structures between
SONET and SDH. I came away thinking that this translated to "shall",
and obviously some others thought it translated to "should". For
those of us who understood "shall", we then move to the followup
discussion that SONET is a subset of SDH and therefore there are no
cases where a SONET multiplex structure exists that is not also
in SDH, so we use only SDH codings (leaving aside the VT3 case
which is not real, and if it were, would be added to G.707).

By "pragmatic evolutionary scenario", it seems that you are proposing
to leave in place dual codings that impede interworking to preserve
or protect pre-standard implementations. I believe that the purpose
of a standard is to allow interworking, not to protect pre-standard
implementations.

In an earlier email of Eric's, I see also:
> If we give you a solution that does what you want to do, plus in addition
> what some other people want to do, why are you complaining ????
I am complaining because a document that simply lists all of the different
things that different people want to do is not a standard - it is just a
catelogue of everyone's proprietary choices. To have a standard, you
make a choice and write it down so you can interoperate.
Regards,
Steve

[email-masked] wrote:
> 
> That's probably the issue here, i see lot of response with respect
> to the last status that has been achieved over years at bodies like
> the T1X1/ITU-T (and ETSI) to improve interoperability between Sonet
> and SDH; the option (2) doesn't at all preclude this, it give us the
> capability to have a more pragmatic evolutionary scenario. That's
> also the paradox, i see people coming from the transmission world
> having an idealistic view on transmission networks (and control plane)
> while they know it will take years to achieve full interop; this while
> others have a real pragmatic view on what short/mid-term needs are/
> will be.
> 
> The option 2) takes into account current install base (with GMPLS
> soft update) and future needs - we don't even have to discuss in
> detail here the specifics btw Sonet and SDH overhead and corr.
> processing - if the "SHOULD" must have to be clarified then let's
> go for it.
> 
> rgds,
> - dimitri.
> 
> "Mannie, Eric" wrote:
> >
> > Stephen,
> >
> > Of course SDH and SONET are interoperable and can be interconnected. You buy
> > a gateway and it is done.
> >
> > I spoke about the fact that in the control plane we should know if a signal
> > is using the SONET "profile" or the SDH "profile". Otherwise you cannot
> > achieve automatically what you described hereafter.
> >
> > If at one end you generate a J1 on 64 bytes with the SONET profile you need
> > to interpret it at the other end as specified in the SONET "profile", not
> > using the SDH "profile" on 16 byte format. You cannot assume that all
> > existing SONET boxes (speaking GMPLS or not) will know that the other end is
> > SDH. This is just one example. I think that this is now clear for everybody.
> >
> > Also due to a lot of legacy boxes at the network periphery, SS conversion is
> > still needed somewhere. These legacy boxes will not speak GMPLS, but they
> > will be the source of paths that will fly over GMPLS clouds and that could
> > even be terminated on GMPLS nodes. When signaling the LSP (SNC) initiated on
> > a SONET cloud and terminated in an SDH could you need to go through a SS
> > conversion. So you need to make a distinction between the SDH and SONET
> > "profiles".
> >
> > Having a the same LSP Encoding Type for SDH/SONET is not general enough and
> > will not cover the cases where some cloud ignore that the other end is SDH.
> > Having a different LSP encoding type for SONET and SDH is just identifying
> > the profile to use. It doesn't prevent you to request an SDH signal from any
> > box to any box, if supported. It doesn't prevent any interoperability.
> >
> > By the way we could may be add to your list other possible differences in
> > J0, K1/K2, E1 (?), F1 (?), E2, maybe S1 and M1 ?, etc. Just taking a list
> > from a tutorial without checking in details.
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Tuesday, February 26, 2002 4:22 PM
> > To: Mannie, Eric
> > Cc: 'Heiles Juergen'; [email-masked]'; Wijnen, Bert (Bert);
> > [email-masked]'; ccamp-wg; [email-masked]'; 'Kireeti Kompella'
> > Subject: Re: Simple solution to terminate the discussion about SONET
> > versus SDH
> >
> > Eric,
> > I don't think you ask quite the right question.
> > The right question is:
> > Can all frame structures which are common to SONET and SDH be
> > interconnected,
> > and do they interoperate? This is what we care about from the viewpoint of
> > establishing switched connections.
> > The answer to this is YES.
> >
> > Are they fully identical from all points of view? As Juergen says, this is
> > the
> > tricky question, as the answer of "No" might mislead some into thinking that
> > these signals cannot be interconnected between SONET and SDH. This is not
> > the case.
> >
> > For those who care, some of the key differences are as follows. Note that
> > these
> > do NOT affect the ability to interconnect these signals (although sometimes
> > there
> > are rules about HOW to interconnect them).
> >
> > SS bits - In the past, this was an issue in the high order pointers. SDH
> > sent
> > and expected "10", for SONET these bits were unspecified. This problem was
> > corrected
> > a few years ago by requiring that ALL equipment send "10" and ignore the
> > incoming
> > bits. Note that even prior to aligning the standards, a great deal of the
> > older
> > equipment followed this strategy as VC-4s and STS-3cs were interconnected
> > long
> > before the standards alignment.
> >
> > Trace identifier - For J1, within SONET, a 64 byte format is normally used.
> > For SDH,
> > a 16 byte format is normally used. SONET specifies that in the case that the
> > far end
> > is SDH, a 16 byte format should be used to allow interworking. For J2, this
> > is normally
> > used in SDH and not normally in SONET. Interworking is acheived by having
> > the SDH end
> > ignore the incoming trace identifier (a required capability in the
> > standards).
> >
> > RDI - SONET uses some extra bits that are reserved in SDH to further
> > classify far end
> > alarms (called ENHANCED RDI). This provides no obstacle to interworking: The
> > SONET
> > side will not be able to provide a more detailed classification of SDH end
> > alarms (it
> > does know there is a far end alarm). The SDH end ignores the extra bits. The
> > Enhanced
> > RDI feature only operates if both ends are SONET.
> >
> > BIP - The coding for BIP is identical. The way degrade is detected is
> > different.
> > SONET generally uses a Poisson algorithm to declare degrade and SDH normally
> > uses
> > a bursty error detection algorithm. This provides no obstacle to
> > interconnect - the
> > criteria for declaring dDEG is just slightly different. Also, SONET provides
> > an
> > EXC alarm for BER > 10^-3 which does not appear in SDH. This also does not
> > prevent
> > interconnect - you just have an alarm which can be declared at one end and
> > not the
> > other.
> >
> > These are the major differences (besides the fact that SONET and SDH tend to
> > have
> > different names for identical things- This is just a US/Europe language
> > issue).
> > Regards,
> > Steve
> >
> > "Mannie, Eric" wrote:
> > >
> > > Dear All,
> > >
> > > There is an easy way to stop definitively this discussion based on
> > technical
> > > facts:
> > >
> > > Stephen, Juergen and Maarten, please tell us: today, are the frame
> > > structures and all the bytes in the SDH and SONET overhead completely
> > > identical, used and interpreted in the same way, is the monitoring exactly
> > > the same ? In particular, if I provision and operate an SDH circuit/LSP is
> > > this fully identical to a SONET circuit/LSP from *all* point of views ?
> > >
> > > PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not needed at this
> > > stage.
> > >
> > > If the answer is yes: SONET is totally identical to SDH.
> > > If the answer is no: SONET is not the same as SDH.
> > >
> > > I think that without that answer we cannot take any *technical* decision
> > on
> > > this mailing list and at the IETF.
> > >
> > > Thanks to answer.
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > ps: feel free to forward this e-mail to any ITU-T mailing list if a
> > > confirmation is needed.
> 
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
> Address: Alcatel - Optical NA, Fr. Wellesplein, 1
>          B-2018 Antwerpen, Belgium
> Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 26 Feb 2002 09:23:52 -0800
Date: Tue, 26 Feb 2002 11:24:18 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: Kireeti Kompella <[email-masked]>
CC: "Wijnen, Bert (Bert)" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

I vote (1).

Jonathan Sadler

Kireeti Kompella wrote:
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
============================================================
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: Tue, 26 Feb 2002 09:23:45 -0800
Date: Tue, 26 Feb 2002 11:24:13 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: WG dcoument status

Kiretti -

A process question:

The signaling drafts currently make reference to a lot of
Internet-Drafts.  Specifically:
  draft-ietf-mpls-generalized-signaling-07.txt has 11 I-D references
  draft-ietf-mpls-generalized-rsvp-te-06.txt has 7 I-D references
  draft-ietf-mpls-generalized-cr-ldp-05 has 7 I-D references

Since these cannot be included in a final RFC, should the signaling
drafts drop the reference and incorporate the text from the refered
document?  If not, then shouldn't both the signalling and referenced
drafts be progressed at one time?

To progress the signaling drafts with normative references to something
that is still under development seems inappropriate...

Jonathan Sadler

Kireeti Kompella wrote:
> 
> Here's a status update.
> 
> The signaling drafts:
>         draft-ietf-mpls-generalized-cr-ldp-05.txt
>         draft-ietf-mpls-generalized-rsvp-te-06.txt
>         draft-ietf-mpls-generalized-signaling-07.txt
>         draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> have finished WG Last Call, and will be sent on to IETF Last Call.
> They are on the track for Proposed Standard.
============================================================
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: Tue, 26 Feb 2002 09:23:28 -0800
From: "Zhang, Zhensheng" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 09:22:28 -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_001_01C1BEEA.2C67774C
Content-Type: text/plain;
	charset="iso-8859-1"

I vote for (2).

Zhensheng

"Wijnen, Bert (Bert)" wrote:
> 
> CCAMP WG members,
> 
> before we start down another many 100s of emails re-discussing
> the same topic....
> 
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
> 
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Thanks
> Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

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

------_=_NextPart_001_01C1BEEA.2C67774C
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: SONET/SDH label agreement for IETF, ITU-T and OIF</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>I vote for (2).</FONT>
</P>

<P><FONT SIZE=3D2>Zhensheng</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&quot;Wijnen, Bert (Bert)&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; CCAMP WG members,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; before we start down another many 100s of =
emails re-discussing</FONT>
<BR><FONT SIZE=3D2>&gt; the same topic....</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; PLEASE express your support for one of the 3 =
options that Kireeti</FONT>
<BR><FONT SIZE=3D2>&gt; posed to the WG. Don't elaborate... just help =
the WG chair(s) to</FONT>
<BR><FONT SIZE=3D2>&gt; figure out the (rough) consensus of the WG. The =
choices formulated</FONT>
<BR><FONT SIZE=3D2>&gt; by Kireeti:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; So, here we are again, arguing over =
this.&nbsp; Let's follow the AD's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; suggestion and look for consensus in the =
WG.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1) Do you think we should have just a =
single set of traffic parameters</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; and label values for =
SDH, and none for SONET?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2) Do you think we should have one for =
SONET and one for SDH, with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; the proviso that, if an =
SDH equivalent is available, one SHOULD</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; use the SDH =
equivalent?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 3) Do you think we should have one for =
SONET and one for SDH, with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; the proviso that, if an =
SDH equivalent is available, one MUST</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; use the SDH =
equivalent?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (in the above, SHOULD and MUST are to be =
interpreted as in RFC 2119.)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; PLEASE respond with just (1), (2) or (3), =
and avoid long diatribes!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks</FONT>
<BR><FONT SIZE=3D2>&gt; Bert, speaking as AD who would like to see the =
WG take</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a decision =
on this topic.</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Papadimitriou Dimitri </FONT>
<BR><FONT SIZE=3D2>E-mail : [email-masked] </FONT>
<BR><FONT SIZE=3D2>Website: <A =
HREF=3D"http://www.rc.bel.alcatel.be/~papadimd/index.html" =
TARGET=3D"_blank">http://www.rc.bel.alcatel.be/~papadimd/index.html</A><=
/FONT>
<BR><FONT SIZE=3D2>Address: Alcatel - Optical NA, Fr. Wellesplein, 1 =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
B-2018 Antwerpen, Belgium</FONT>
<BR><FONT SIZE=3D2>Phone:&nbsp;&nbsp; Work: +32 3 2408491 - Home: +32 2 =
3434361</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BEEA.2C67774C--

Delivery-date: Tue, 26 Feb 2002 09:15:39 -0800
Date: Tue, 26 Feb 2002 18:13:24 +0100
From: [email-masked]
Organization: Alcatel Bell - IPO NA (Antwerpen)
To: "Mannie, Eric" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Re: Simple solution to terminate the discussion about SONET versus SDH

That's probably the issue here, i see lot of response with respect
to the last status that has been achieved over years at bodies like
the T1X1/ITU-T (and ETSI) to improve interoperability between Sonet 
and SDH; the option (2) doesn't at all preclude this, it give us the 
capability to have a more pragmatic evolutionary scenario. That's 
also the paradox, i see people coming from the transmission world 
having an idealistic view on transmission networks (and control plane)
while they know it will take years to achieve full interop; this while
others have a real pragmatic view on what short/mid-term needs are/
will be. 

The option 2) takes into account current install base (with GMPLS 
soft update) and future needs - we don't even have to discuss in 
detail here the specifics btw Sonet and SDH overhead and corr.
processing - if the "SHOULD" must have to be clarified then let's
go for it.

rgds,
- dimitri.

"Mannie, Eric" wrote:
> 
> Stephen,
> 
> Of course SDH and SONET are interoperable and can be interconnected. You buy
> a gateway and it is done.
> 
> I spoke about the fact that in the control plane we should know if a signal
> is using the SONET "profile" or the SDH "profile". Otherwise you cannot
> achieve automatically what you described hereafter.
> 
> If at one end you generate a J1 on 64 bytes with the SONET profile you need
> to interpret it at the other end as specified in the SONET "profile", not
> using the SDH "profile" on 16 byte format. You cannot assume that all
> existing SONET boxes (speaking GMPLS or not) will know that the other end is
> SDH. This is just one example. I think that this is now clear for everybody.
> 
> Also due to a lot of legacy boxes at the network periphery, SS conversion is
> still needed somewhere. These legacy boxes will not speak GMPLS, but they
> will be the source of paths that will fly over GMPLS clouds and that could
> even be terminated on GMPLS nodes. When signaling the LSP (SNC) initiated on
> a SONET cloud and terminated in an SDH could you need to go through a SS
> conversion. So you need to make a distinction between the SDH and SONET
> "profiles".
> 
> Having a the same LSP Encoding Type for SDH/SONET is not general enough and
> will not cover the cases where some cloud ignore that the other end is SDH.
> Having a different LSP encoding type for SONET and SDH is just identifying
> the profile to use. It doesn't prevent you to request an SDH signal from any
> box to any box, if supported. It doesn't prevent any interoperability.
> 
> By the way we could may be add to your list other possible differences in
> J0, K1/K2, E1 (?), F1 (?), E2, maybe S1 and M1 ?, etc. Just taking a list
> from a tutorial without checking in details.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 4:22 PM
> To: Mannie, Eric
> Cc: 'Heiles Juergen'; [email-masked]'; Wijnen, Bert (Bert);
> [email-masked]'; ccamp-wg; [email-masked]'; 'Kireeti Kompella'
> Subject: Re: Simple solution to terminate the discussion about SONET
> versus SDH
> 
> Eric,
> I don't think you ask quite the right question.
> The right question is:
> Can all frame structures which are common to SONET and SDH be
> interconnected,
> and do they interoperate? This is what we care about from the viewpoint of
> establishing switched connections.
> The answer to this is YES.
> 
> Are they fully identical from all points of view? As Juergen says, this is
> the
> tricky question, as the answer of "No" might mislead some into thinking that
> these signals cannot be interconnected between SONET and SDH. This is not
> the case.
> 
> For those who care, some of the key differences are as follows. Note that
> these
> do NOT affect the ability to interconnect these signals (although sometimes
> there
> are rules about HOW to interconnect them).
> 
> SS bits - In the past, this was an issue in the high order pointers. SDH
> sent
> and expected "10", for SONET these bits were unspecified. This problem was
> corrected
> a few years ago by requiring that ALL equipment send "10" and ignore the
> incoming
> bits. Note that even prior to aligning the standards, a great deal of the
> older
> equipment followed this strategy as VC-4s and STS-3cs were interconnected
> long
> before the standards alignment.
> 
> Trace identifier - For J1, within SONET, a 64 byte format is normally used.
> For SDH,
> a 16 byte format is normally used. SONET specifies that in the case that the
> far end
> is SDH, a 16 byte format should be used to allow interworking. For J2, this
> is normally
> used in SDH and not normally in SONET. Interworking is acheived by having
> the SDH end
> ignore the incoming trace identifier (a required capability in the
> standards).
> 
> RDI - SONET uses some extra bits that are reserved in SDH to further
> classify far end
> alarms (called ENHANCED RDI). This provides no obstacle to interworking: The
> SONET
> side will not be able to provide a more detailed classification of SDH end
> alarms (it
> does know there is a far end alarm). The SDH end ignores the extra bits. The
> Enhanced
> RDI feature only operates if both ends are SONET.
> 
> BIP - The coding for BIP is identical. The way degrade is detected is
> different.
> SONET generally uses a Poisson algorithm to declare degrade and SDH normally
> uses
> a bursty error detection algorithm. This provides no obstacle to
> interconnect - the
> criteria for declaring dDEG is just slightly different. Also, SONET provides
> an
> EXC alarm for BER > 10^-3 which does not appear in SDH. This also does not
> prevent
> interconnect - you just have an alarm which can be declared at one end and
> not the
> other.
> 
> These are the major differences (besides the fact that SONET and SDH tend to
> have
> different names for identical things- This is just a US/Europe language
> issue).
> Regards,
> Steve
> 
> "Mannie, Eric" wrote:
> >
> > Dear All,
> >
> > There is an easy way to stop definitively this discussion based on
> technical
> > facts:
> >
> > Stephen, Juergen and Maarten, please tell us: today, are the frame
> > structures and all the bytes in the SDH and SONET overhead completely
> > identical, used and interpreted in the same way, is the monitoring exactly
> > the same ? In particular, if I provision and operate an SDH circuit/LSP is
> > this fully identical to a SONET circuit/LSP from *all* point of views ?
> >
> > PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not needed at this
> > stage.
> >
> > If the answer is yes: SONET is totally identical to SDH.
> > If the answer is no: SONET is not the same as SDH.
> >
> > I think that without that answer we cannot take any *technical* decision
> on
> > this mailing list and at the IETF.
> >
> > Thanks to answer.
> >
> > Kind regards,
> >
> > Eric
> >
> > ps: feel free to forward this e-mail to any ITU-T mailing list if a
> > confirmation is needed.

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

Delivery-date: Tue, 26 Feb 2002 08:46:17 -0800
Date: Tue, 26 Feb 2002 09:44:34 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'Heiles Juergen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Re: Simple solution to terminate the discussion about SONET versus SDH

Eric

"Mannie, Eric" wrote:
> Of course SDH and SONET are interoperable and can be interconnected. You buy
> a gateway and it is done.
No- for the identical frame structures, you can interoperate with mid-span
meet. No gateway is required.

Steve

Delivery-date: Tue, 26 Feb 2002 08:32:29 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: 'Heiles Juergen' <[email-masked]>,  "[email-masked]'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>,  'Kireeti Kompella' <[email-masked]>
Subject: RE: Simple solution to terminate the discussion about SONET versu s SDH
Date: Tue, 26 Feb 2002 17:30:50 +0100

Stephen,

Of course SDH and SONET are interoperable and can be interconnected. You buy
a gateway and it is done. 

I spoke about the fact that in the control plane we should know if a signal
is using the SONET "profile" or the SDH "profile". Otherwise you cannot
achieve automatically what you described hereafter.

If at one end you generate a J1 on 64 bytes with the SONET profile you need
to interpret it at the other end as specified in the SONET "profile", not
using the SDH "profile" on 16 byte format. You cannot assume that all
existing SONET boxes (speaking GMPLS or not) will know that the other end is
SDH. This is just one example. I think that this is now clear for everybody.

Also due to a lot of legacy boxes at the network periphery, SS conversion is
still needed somewhere. These legacy boxes will not speak GMPLS, but they
will be the source of paths that will fly over GMPLS clouds and that could
even be terminated on GMPLS nodes. When signaling the LSP (SNC) initiated on
a SONET cloud and terminated in an SDH could you need to go through a SS
conversion. So you need to make a distinction between the SDH and SONET
"profiles".

Having a the same LSP Encoding Type for SDH/SONET is not general enough and
will not cover the cases where some cloud ignore that the other end is SDH.
Having a different LSP encoding type for SONET and SDH is just identifying
the profile to use. It doesn't prevent you to request an SDH signal from any
box to any box, if supported. It doesn't prevent any interoperability.

By the way we could may be add to your list other possible differences in
J0, K1/K2, E1 (?), F1 (?), E2, maybe S1 and M1 ?, etc. Just taking a list
from a tutorial without checking in details.

Kind regards,

Eric

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 4:22 PM
To: Mannie, Eric
Cc: 'Heiles Juergen'; [email-masked]'; Wijnen, Bert (Bert);
[email-masked]'; ccamp-wg; [email-masked]'; 'Kireeti Kompella'
Subject: Re: Simple solution to terminate the discussion about SONET
versus SDH

Eric,
I don't think you ask quite the right question.
The right question is:
Can all frame structures which are common to SONET and SDH be
interconnected,
and do they interoperate? This is what we care about from the viewpoint of
establishing switched connections.
The answer to this is YES.

Are they fully identical from all points of view? As Juergen says, this is
the
tricky question, as the answer of "No" might mislead some into thinking that
these signals cannot be interconnected between SONET and SDH. This is not
the case.

For those who care, some of the key differences are as follows. Note that
these
do NOT affect the ability to interconnect these signals (although sometimes
there
are rules about HOW to interconnect them).

SS bits - In the past, this was an issue in the high order pointers. SDH
sent
and expected "10", for SONET these bits were unspecified. This problem was
corrected
a few years ago by requiring that ALL equipment send "10" and ignore the
incoming
bits. Note that even prior to aligning the standards, a great deal of the
older
equipment followed this strategy as VC-4s and STS-3cs were interconnected
long
before the standards alignment.

Trace identifier - For J1, within SONET, a 64 byte format is normally used.
For SDH,
a 16 byte format is normally used. SONET specifies that in the case that the
far end
is SDH, a 16 byte format should be used to allow interworking. For J2, this
is normally
used in SDH and not normally in SONET. Interworking is acheived by having
the SDH end
ignore the incoming trace identifier (a required capability in the
standards).

RDI - SONET uses some extra bits that are reserved in SDH to further
classify far end
alarms (called ENHANCED RDI). This provides no obstacle to interworking: The
SONET
side will not be able to provide a more detailed classification of SDH end
alarms (it
does know there is a far end alarm). The SDH end ignores the extra bits. The
Enhanced
RDI feature only operates if both ends are SONET.

BIP - The coding for BIP is identical. The way degrade is detected is
different.
SONET generally uses a Poisson algorithm to declare degrade and SDH normally
uses
a bursty error detection algorithm. This provides no obstacle to
interconnect - the
criteria for declaring dDEG is just slightly different. Also, SONET provides
an
EXC alarm for BER > 10^-3 which does not appear in SDH. This also does not
prevent
interconnect - you just have an alarm which can be declared at one end and
not the
other.

These are the major differences (besides the fact that SONET and SDH tend to
have
different names for identical things- This is just a US/Europe language
issue).
Regards,
Steve

"Mannie, Eric" wrote:
> 
> Dear All,
> 
> There is an easy way to stop definitively this discussion based on
technical
> facts:
> 
> Stephen, Juergen and Maarten, please tell us: today, are the frame
> structures and all the bytes in the SDH and SONET overhead completely
> identical, used and interpreted in the same way, is the monitoring exactly
> the same ? In particular, if I provision and operate an SDH circuit/LSP is
> this fully identical to a SONET circuit/LSP from *all* point of views ?
> 
> PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not needed at this
> stage.
> 
> If the answer is yes: SONET is totally identical to SDH.
> If the answer is no: SONET is not the same as SDH.
> 
> I think that without that answer we cannot take any *technical* decision
on
> this mailing list and at the IETF.
> 
> Thanks to answer.
> 
> Kind regards,
> 
> Eric
> 
> ps: feel free to forward this e-mail to any ITU-T mailing list if a
> confirmation is needed.

Delivery-date: Tue, 26 Feb 2002 08:25:19 -0800
Date: Tue, 26 Feb 2002 10:20:58 -0600
From: Ben Mack-Crane <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: CCAMP Protection/Restoration Design Team

Kireeti,

As I've mentioned before, the design team should also consider
draft-ietf-mpls-recovery-frmwrk-03.txt when generating a terminology
document.

Regards,
Ben

Kireeti Kompella wrote:
> 
> Hi Folks,
> 
> I'd like to thank all of you who volunteered for this work.  To keep
> the team small and effective, not everyone who volunteered could
> participate directly.  Note that you can (and should) participate
> through the CCAMP WG, by giving suggestions/feedback to the DT, and,
> if deemed necessary, by proposing alternate documents.
> 
> Finally, note that the design team is _just another set of authors_.
> The document(s) they produce are subject to WG consensus to progress
> to WG documents and beyond.
> 
> Here's the Protection/Restoration Design Team.  They have been on
> the job for a little over a month now.
> 
> Deborah Brungard
> Sudheer Dharanikota
> Jonathan Lang
> Guangzhi Li
> Eric Mannie
> Dimitri Papadimitriou
> Bala Rajagopalan
> Yakov Rekhter
> 
> Sudheer is the team lead.
> 
> Their charter ("you" in what follows refers to the DT):
> 
> a) read drafts re protection/restoration in CCAMP, IPO and MPLS.
>    These include (but are not limited to :-)):
> 
> ******* draft-ietf-tewg-restore-hierarchy-00.txt *******
> 
>         draft-bala-protection-restoration-signaling-00.txt
>         draft-bala-restoration-signaling-01.txt
>         draft-ietf-ipo-carrier-requirements-00.txt (Section 10)
>         draft-kini-restoration-shared-backup-01.txt
>         draft-li-shared-mesh-restoration-01.txt
>         draft-many-optical-restoration-01.txt
>         draft-suemura-protection-hierarchy-00.txt
>         draft-ylee-protection-occ-00.txt
>         -----------------------------------------------------
>         draft-atlas-rsvp-local-protect-interop-02.txt
>         draft-chang-mpls-path-protection-03.txt
>         draft-chang-mpls-rsvpte-path-protection-ext-02.txt
>         draft-owens-crldp-path-protection-ext-01.txt
> 
>    The first draft is the requirements for Protection & Restoration
>    produced by the TEWG Design Team.  Functionality that you come up
>    with should satisfy these requirements; stuff that you come up
>    with that either goes beyond these requirements or doesn't meet
>    some of them should be called out so that we can re-evaluate.
> 
>    The drafts below the line may be MPLS-specific, so they may or may
>    not apply.
> 
> | AD's comment: For the first round... please refrain as much as possible
> | from going beyond the requirements specified in the first draft.  That
> | document restricted itself (on purpose) to requirements that are felt
> | to be realistic for real operators and in the reasonably short term.
> | So that is the scope you should be working in.
> 
> b) produce a terminology document, preferably using ITU-T terminology,
>    but having a decoder ring to translate to terminology in current
>    drafts as well as the TE WG document
> c) produce an interim analysis document, comparing and contrasting
>    approaches (i.e., the above drafts, published and ongoing work
>    at the ITU/T1-X1/...)
> 
> | AD's comment: And be careful. Leave the ITU and T1X1-... etc work in
> | those organisations if that is where it belongs (and often it does)!
> 
> d) produce a more complete version of (c)
> e) produce a functional spec delineating
>    o 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.
>    o Overall approach
>    o Objects/procedures/... needed in a protocol-independent fashion
> f) produce a document detailing the changes for RSVP-TE and CR-LDP
> g) produce a document detailing the changes for OSFP-TE and IS-IS-TE
> 
> The timeline for (a-c) is before the next IETF (March 1, 2002).
> 
> A first cut of (d) and (e) should be available by end of April, 2002.
> If there is rough consensus in the CCAMP WG for the approach in (e),
> work should then start on (f) and (g).
> 
> Kireeti.
============================================================
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: Tue, 26 Feb 2002 08:21:29 -0800
From: "Bernstein, Greg" <[email-masked]>
To: Don Fedyk <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Routing drafts
Date: Tue, 26 Feb 2002 08:20:46 -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_001_01C1BEE1.8BC929A0
Content-Type: text/plain

Hi Don, for now don't worry about the timeslot maps. I'm sure other folk
will bring this up.  I want an efficient method to send update changes in to
circuit switched bandwidth.  For example my OC-192 has just gone from having
49 STS-1 equivalent bandwidth available to 47 STS-1 bandwidth available.  It
seems like a single byte can convey this.  While at the same time I may also
want to convey the fact that one or more of the already uses STS-1s are
being "sub-multiplexed" and have space for say 36 VT1.5s.  However this
VT1.5 bandwidth isn't equivalent to STS-1 bandwidth.  (Similar issues apply
up and down the multiplex hierarchy).  I don't know why you say integers
aren't "dynamic" enough.  They are very easy to change rapidly and book keep
accurately for TDM purposes.
 
Greg B.
 
-----Original Message-----
From: Don Fedyk [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2002 6:04 AM
To: Bernstein, Greg; Kireeti Kompella; [email-masked]
Subject: RE: Routing drafts
 
Greg 
Yes I recall the discussions on this. The bandwidth summaries are 
the minimal amount of information to make a routing decision. They 
do not cover all of the detail that could be in a timeslot map. 
Integers are definitely not dynamic enough. The issue is that even 
if you have this detailed information you still have to augment 
signaling with the capability to deal with glare conditions. So 
our strategy was not to overburden routing with this information 
but to put the capability in signaling. 
Don 
-----Original Message----- 
>From: Bernstein, Greg [mailto:[email-masked] <mailto:[email-masked]> ] 
>Sent: Monday, February 25, 2002 8:32 PM 
>To: Fedyk, Don [BL60:1A00:EXCH]; Kireeti Kompella; [email-masked] 
>Subject: RE: Routing drafts. 
> 
> 
>Actually floating point is overkill for TDM.  We'd like to use small 
>integers to describe and update them more frequently.  
>The TDM multiplexing is straight forward but unforgiving. 
>We had this same discussion when we decided to breakout the labels 
>for SONET/SDH GMPLS signaling.  I want to know that I've got 14 
>STS-1 of capacity, XX unused VT1.5, etc...  For those SONET/SDH 
>systems that have to deal with timeslot inflexibility (i.e., 
>fragementations issues) more complete information on time slot 
>usage is advantageous.  For example with rings that don't 
>have Time Slot Interchange, a map of the timeslots could 
>be helpful.  Eric and I had a bunch of stuff about this in 
>our earlier routing drafts. 
> 
>Greg B. 
> 
>---------------------------------------------------------------------------
----------- 
>Dr. Greg M. Bernstein, Sr. Director Technology, Ciena Corp. 
  
>-----Original Message----- 
>From: Don Fedyk [mailto:[email-masked]
<mailto:[email-masked]> ] 
>Sent: Monday, February 25, 2002 4:07 PM 
>To: Bernstein, Greg; Kireeti Kompella; [email-masked] 
>Subject: RE: Routing drafts 
> 
>Greg you wrote: 
>> (b) Big issue -- The parameters for representing bandwidth on 
>> a link are not 
>> very appropriate for TDM signals or WDM signals.  I've 
>> included below some 
>> more explanation taken from the IPO working group draft. 
>> However, this is 
>> the same thing that led to us breaking out the traffic 
>> descriptor stuff in 
>> GMPLS signaling for the SONET/SDH case.  This is really 
>> needed here too. 
>> 
>These bandwidths in our draft are exact floating point numbers. 
>Are you saying that the resolution of the floating point is an issue 
>with optical? Or are you implying that bandwidths are percentages ? 
>The text below is implying that statistical multiplexing can use 
>inexact bandwidth but optical can (and should) use exact bandwidths. 
>I did not see problems with the floating point range or our draft. 
>Don 
> 
>> (From IPO working group draft on Inter-domain optical routing) 
>> 2.3   Differences between MPLS and Optical Circuit routing 
>> 
>> The bandwidth accounting needed in optical circuit-switched 
>> networks is also 
>> different than in packet networks. In packet networks using 
>> either ATM QoS 
>> or MPLS-TE, complex statistical measures are used to 
>> characterize the load 
>> on a link, often with varying degrees of accuracy.  The 
>> inexactness of such 
>> measures and the "compressibility" of statistically 
>> multiplexed traffic 
>> imply that a small percentage change in link utilization can 
>> usually be 
>> absorbed by the network. 
>> 
>> By contrast, if an OC-192 link has just one STS-1 path 
>> occupied (less than 
>> 1% of the link bandwidth), it cannot accommodate an STS-192c 
>> path. Due to 
>> the relatively simple finite multiplex structures currently 
>> use in optical 
>> networks tracking bandwidth resources is much easier than 
>> packet switched 
>> networks, however much stricter bandwidth accounting is 
>> required on circuit 
>> switched links. In particular, it is expected that an 
>> individual optical 
>> circuit switched link can be fully utilized, while due to 
>> queuing effects a 
>> packet switched link on average can never be run at full 
>> capacity and is 
>> typically run at less then 80% of capacity.  
>>   
>> Greg B. 
>> 

------_=_NextPart_001_01C1BEE1.8BC929A0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<title>RE: Routing drafts</title>
<!--[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:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-alt:"Device Font 10cpi";
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@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;}
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 link=3Dblue vlink=3Dblue =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Don, for now don't worry about
the timeslot maps. I'm sure other folk will bring this up.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>I want an efficient method to =
send update
changes in to circuit switched bandwidth.<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>For example my OC-192 has just gone from having 49 STS-1 =
equivalent
bandwidth available <span class=3DGramE>to 47 STS-1 bandwidth =
available</span>.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>It seems like a single byte =
can convey
this.<span style=3D'mso-spacerun:yes'>&nbsp; </span>While at the same =
time I may
also want to convey the fact that one or more of the already uses =
STS-1s are
being "sub-multiplexed" and have space for say 36 VT1.5s.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>However this VT1.5 bandwidth =
isn't
equivalent to STS-1 bandwidth.<span style=3D'mso-spacerun:yes'>&nbsp;
</span>(Similar issues apply up and down the multiplex hierarchy).<span
style=3D'mso-spacerun:yes'>&nbsp; </span>I don't know why you say =
integers
aren't "dynamic" enough.<span style=3D'mso-spacerun:yes'>&nbsp;
</span>They are very easy to change rapidly and <span =
class=3DGramE>book keep</span>
accurately for TDM purposes.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Greg =
B.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Don Fedyk
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, February =
26, 2002
6:04 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Bernstein, Greg; =
Kireeti
Kompella; [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Routing =
drafts</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Greg</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Yes I recall the discussions on this. The =
bandwidth
summaries are </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>the minimal amount of =
information
to make a routing decision. They </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>do not cover all of the =
detail that
could be in a timeslot map. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>Integers are definitely =
not dynamic
enough. The issue is that even </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>if you have this =
detailed
information you still have to augment </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>signaling with the =
capability to
deal with glare conditions. So </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>our strategy was not to =
overburden
routing with this information</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>but to put the =
capability in
signaling.</span></font> <o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Don </span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>-----Original Message-----</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;From: Bernstein, =
Greg [<a
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]</span></font=
> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Sent: Monday, =
February 25, 2002
8:32 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;To: Fedyk, Don
[BL60:1A00:EXCH]; Kireeti Kompella; [email-masked]</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Subject: RE: =
Routing drafts.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Actually floating =
point is
overkill for TDM.&nbsp; We'd like to use small </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;integers to =
describe and update
them more frequently.&nbsp; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;The TDM =
multiplexing is
straight forward but unforgiving. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;We had this same =
discussion
when we decided to breakout the labels </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;for SONET/SDH GMPLS
signaling.&nbsp; I want to know that I've got 14 </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;STS-1 of capacity, =
XX unused
VT1.5, etc...&nbsp; For those SONET/SDH </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;systems that have =
to deal with
timeslot inflexibility (i.e., </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;fragementations =
issues) more
complete information on time slot </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;usage is =
advantageous.&nbsp;
For example with rings that don't </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;have Time Slot =
Interchange, a
map of the timeslots could </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;be helpful.&nbsp; =
Eric and I
had a bunch of stuff about this in </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;our earlier routing =
drafts.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Greg =
B.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;-----------------------------------------=
---------------------------------------------</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Dr. Greg M. =
Bernstein, Sr.
Director Technology, Ciena Corp.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp;</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;-----Original =
Message-----</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;From: Don Fedyk [<a
href=3D"mailto:[email-masked]">mailto:dwfedyk@nortelnetworks=
.com</a>]
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Sent: Monday, =
February 25, 2002
4:07 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;To: Bernstein, =
Greg; Kireeti
Kompella; [email-masked]</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Subject: RE: =
Routing drafts</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Greg you wrote: =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; (b) Big issue =
-- The
parameters for representing bandwidth on </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; a link are not =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; very =
appropriate for TDM
signals or WDM signals.&nbsp; I've </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; included below =
some </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; more =
explanation taken
from the IPO working group draft. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; However, this =
is </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; the same thing =
that led to
us breaking out the traffic </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; descriptor =
stuff in </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; GMPLS =
signaling for the
SONET/SDH case.&nbsp; This is really </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; needed here =
too. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;These bandwidths in =
our draft
are exact floating point numbers. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Are you saying that =
the
resolution of the floating point is an issue </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;with optical? Or =
are you
implying that bandwidths are percentages ? </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;The text below is =
implying that
statistical multiplexing can use </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;inexact bandwidth =
but optical
can (and should) use exact bandwidths. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;I did not see =
problems with the
floating point range or our draft. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Don =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; (From IPO =
working group
draft on Inter-domain optical routing) </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; =
2.3&nbsp;&nbsp;
Differences between MPLS and Optical Circuit routing </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; The bandwidth =
accounting
needed in optical circuit-switched </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; networks is =
also </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; different than =
in packet
networks. In packet networks using </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; either ATM QoS =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; or MPLS-TE, =
complex
statistical measures are used to </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; characterize =
the load </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; on a link, =
often with
varying degrees of accuracy.&nbsp; The </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; inexactness of =
such </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; measures and =
the
&quot;compressibility&quot; of statistically </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; multiplexed =
traffic </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; imply that a =
small
percentage change in link utilization can </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; usually be =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; absorbed by =
the network. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; By contrast, =
if an OC-192
link has just one STS-1 path </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; occupied (less =
than </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; 1% of the link =
bandwidth),
it cannot accommodate an STS-192c </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; path. Due to =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; the relatively =
simple
finite multiplex structures currently </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; use in optical =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; networks =
tracking
bandwidth resources is much easier than </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; packet =
switched </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; networks, =
however much
stricter bandwidth accounting is </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; required on =
circuit </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; switched =
links. In
particular, it is expected that an </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; individual =
optical </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; circuit =
switched link can
be fully utilized, while due to </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; queuing =
effects a </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; packet =
switched link on
average can never be run at full </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; capacity and =
is </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; typically run =
at less then
80% of capacity.&nbsp; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt;&nbsp;&nbsp; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; Greg B. =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&gt; =
</span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1BEE1.8BC929A0--

Delivery-date: Tue, 26 Feb 2002 08:13:20 -0800
From: John Drake <[email-masked]>
To: 'Bala Rajagopalan' <[email-masked]>, "'Mannie, Eric '" <[email-masked]>, "''Wijnen, Bert (Bert)' '" <[email-masked]>,  'ccamp-wg ' <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 08:12:46 -0800

2)

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 6:16 AM
To: 'Mannie, Eric '; ''Wijnen, Bert (Bert)' '; 'ccamp-wg '
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

Vote for (2).

Bala

-----Original Message-----
From: Mannie, Eric
To: 'Wijnen, Bert (Bert)'; ccamp-wg
Sent: 2/26/02 6:17 AM
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

(2) for me

Eric

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 10:37 AM
To: ccamp-wg
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

CCAMP WG members, 

before we start down another many 100s of emails re-discussing
the same topic....

PLEASE express your support for one of the 3 options that Kireeti
posed to the WG. Don't elaborate... just help the WG chair(s) to
figure out the (rough) consensus of the WG. The choices formulated
by Kireeti:

> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Thanks
Bert, speaking as AD who would like to see the WG take 
      a decision on this topic.

Delivery-date: Tue, 26 Feb 2002 08:13:17 -0800
Date: Tue, 26 Feb 2002 10:08:14 -0600
From: Ben Mack-Crane <[email-masked]>
To: Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>
CC: ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

I support (1).

Regards,
Ben Mack-Crane

Kireeti Kompella wrote:
> 
snip
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
> 
> Thanks,
> Kireeti.
============================================================
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: Tue, 26 Feb 2002 08:04:52 -0800
From: "Bernstein, Greg" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, "Mannie, Eric" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 08:04:01 -0800

Hi Bert and Eric if this fourth option is saying
(a) One set of values for SONET and SDH where they overlap.  In particular
the payload signals of SONET and SDH are equivalent now thanks to the
efforts of folks at the ITU-T and T1. For example an STS-1 path and VC-3.
(b) Where they differ we use different encodings.  For example if we are
dealing with a SONET section level signal or a SDH regenerator section level
signal there are differences in overhead that do matter and my equipment
does need to be configured appropriately.

Then I agree with this.  I don't need two ways to specify a VC-4 (STS-3c
path).

Greg B.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2002 4:40 AM
To: Mannie, Eric; ccamp-wg
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

If people want to express their support for this 4th option
then that is fine with me. WG chair(s) do you agree too
(don't want to step on your toes or sit in your chair).

Bert 

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 11:32 AM
> To: 'Wijnen, Bert (Bert)'; ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> Hello Bert and all,
> 
> One question is missing:
> 
> 4) Do you think we should have just a single set of traffic 
> parameters and
> label format (values) for both SDH and SONET.
> 
> In 1) "none for SONET" assumes that SONET doesn't exist 
> anymore. Note also
> that the traffic parameters are already identical, the only 
> difference is
> about the label. As editor of these drafts I would like at 
> least to see the
> right questions asked on the mailing list.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 10:37 AM
> To: ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> CCAMP WG members, 
> 
> before we start down another many 100s of emails re-discussing
> the same topic....
> 
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
> 
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> > 
> > 1) Do you think we should have just a single set of traffic 
> parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> > 
> > (in the above, SHOULD and MUST are to be interpreted as in 
> RFC 2119.)
> > 
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Thanks
> Bert, speaking as AD who would like to see the WG take 
>       a decision on this topic.
> 

Delivery-date: Tue, 26 Feb 2002 07:57:05 -0800
From: "Osama Aboul-Magd"<[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 10:56:38 -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_01C1BEDE.2C8C64A0
Content-Type: text/plain;
	charset="iso-8859-1"

I vote for (1).

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

 -----Original Message-----
From: 	Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent:	Tuesday, February 26, 2002 4:37 AM
To:	ccamp-wg
Subject:	RE: SONET/SDH label agreement for IETF, ITU-T and OIF

CCAMP WG members, 

before we start down another many 100s of emails re-discussing
the same topic....

PLEASE express your support for one of the 3 options that Kireeti
posed to the WG. Don't elaborate... just help the WG chair(s) to
figure out the (rough) consensus of the WG. The choices formulated
by Kireeti:

> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Thanks
Bert, speaking as AD who would like to see the WG take 
      a decision on this topic.

------_=_NextPart_001_01C1BEDE.2C8C64A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: SONET/SDH label agreement for IETF, ITU-T and OIF</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I vote for (1).</FONT>
</P>

<P><FONT SIZE=2>Regards;</FONT>
</P>

<P><FONT SIZE=2>Osama Aboul-Magd</FONT>
<BR><FONT SIZE=2>Nortel Networks</FONT>
<BR><FONT SIZE=2>P.O. Box 3511, Station &quot;C&quot;</FONT>
<BR><FONT SIZE=2>Ottawa, ON, Canada</FONT>
<BR><FONT SIZE=2>K1Y - 4H7</FONT>
<BR><FONT SIZE=2>Tel: 613-763-5827</FONT>
<BR><FONT SIZE=2>e.mail: [email-masked]</FONT>
</P>

<P><FONT SIZE=2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: &nbsp; Wijnen, Bert (Bert) [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent:&nbsp;&nbsp; Tuesday, February 26, 2002 4:37 AM</FONT>
<BR><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp;&nbsp; ccamp-wg</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: SONET/SDH label agreement for IETF, ITU-T and OIF</FONT>
</P>

<P><FONT SIZE=2>CCAMP WG members, </FONT>
</P>

<P><FONT SIZE=2>before we start down another many 100s of emails re-discussing</FONT>
<BR><FONT SIZE=2>the same topic....</FONT>
</P>

<P><FONT SIZE=2>PLEASE express your support for one of the 3 options that Kireeti</FONT>
<BR><FONT SIZE=2>posed to the WG. Don't elaborate... just help the WG chair(s) to</FONT>
<BR><FONT SIZE=2>figure out the (rough) consensus of the WG. The choices formulated</FONT>
<BR><FONT SIZE=2>by Kireeti:</FONT>
</P>

<P><FONT SIZE=2>&gt; So, here we are again, arguing over this.&nbsp; Let's follow the AD's</FONT>
<BR><FONT SIZE=2>&gt; suggestion and look for consensus in the WG.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1) Do you think we should have just a single set of traffic parameters</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; and label values for SDH, and none for SONET?</FONT>
<BR><FONT SIZE=2>&gt; or</FONT>
<BR><FONT SIZE=2>&gt; 2) Do you think we should have one for SONET and one for SDH, with</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the proviso that, if an SDH equivalent is available, one SHOULD</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; use the SDH equivalent?</FONT>
<BR><FONT SIZE=2>&gt; or</FONT>
<BR><FONT SIZE=2>&gt; 3) Do you think we should have one for SONET and one for SDH, with</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the proviso that, if an SDH equivalent is available, one MUST</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; use the SDH equivalent?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PLEASE respond with just (1), (2) or (3), and avoid long diatribes!</FONT>
</P>

<P><FONT SIZE=2>Thanks</FONT>
<BR><FONT SIZE=2>Bert, speaking as AD who would like to see the WG take </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a decision on this topic.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BEDE.2C8C64A0--

Delivery-date: Tue, 26 Feb 2002 07:55:46 -0800
From: Heiles Juergen <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 16:54:56 +0100

Eric,

1) and your proposed 4) are basically identical in my view.
SONET is also covered by SDH. So it is just the question do we mention SONET explicitly in the document or not. I prefer that it is mentioned.

Regards

Juergen

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 11:32 AM
> To: 'Wijnen, Bert (Bert)'; ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> Hello Bert and all,
> 
> One question is missing:
> 
> 4) Do you think we should have just a single set of traffic 
> parameters and
> label format (values) for both SDH and SONET.
> 
> In 1) "none for SONET" assumes that SONET doesn't exist 
> anymore. Note also
> that the traffic parameters are already identical, the only 
> difference is
> about the label. As editor of these drafts I would like at 
> least to see the
> right questions asked on the mailing list.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 10:37 AM
> To: ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> CCAMP WG members, 
> 
> before we start down another many 100s of emails re-discussing
> the same topic....
> 
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
> 
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> > 
> > 1) Do you think we should have just a single set of traffic 
> parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> > 
> > (in the above, SHOULD and MUST are to be interpreted as in 
> RFC 2119.)
> > 
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Thanks
> Bert, speaking as AD who would like to see the WG take 
>       a decision on this topic.
> 

Delivery-date: Tue, 26 Feb 2002 07:51:53 -0800
From: Sasha Vainshtein <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF - Not a Vot e!
Date: Tue, 26 Feb 2002 17:45:12 +0200

Eric and all,
My understanding of  - and vote for - (1) are based on the 
presumption that SONET is a strict subset of SDH.
AFAIK this is also the ITU-T position.

As a consequence, it is possible to define a unique 
"SDH translation" for each "SONET term" 
(but not vice versa).

IMHO a "dictionary" mapping SONET terms to their SDH equivalents 
could be incorporated (as an Annex?) in the relevant GMPLS 
document(s) for convenience of the SONET-minded readers. This would not
compromise (1) in any way, as the "core" documents could consistently use 
SDH terms.

Hopefully these notes will be helpful.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 5:06 PM
> To: 'Wijnen, Bert (Bert)'; ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> Hello Bert and Kireeti,
> 
> Please could you clarify what means (1):
> 
> > 1) Do you think we should have just a single set of traffic 
> parameters
> >    and label values for SDH, and none for SONET?
> 
> Do you mean that we will remove the terms SONET, the concepts 
> (VT, STS,
> etc), and the references from all GMPLS drafts and that GMPLS 
> will have a
> reduced scope to SDH only ?
> 
> If yes, why ?
> 
> Thanks,
> 
> Kind regards,
> 
> Eric
> 
> 
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 10:37 AM
> To: ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> CCAMP WG members, 
> 
> before we start down another many 100s of emails re-discussing
> the same topic....
> 
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
> 
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> > 
> > 1) Do you think we should have just a single set of traffic 
> parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> > 
> > (in the above, SHOULD and MUST are to be interpreted as in 
> RFC 2119.)
> > 
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Thanks
> Bert, speaking as AD who would like to see the WG take 
>       a decision on this topic.
> 

Delivery-date: Tue, 26 Feb 2002 07:48:44 -0800
content-class: urn:content-classes:message
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 10:48:05 -0500
From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>, "ccamp-wg" <[email-masked]>

I support (1)

Jerry Ash
=20
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>=20
> Thanks,
> Kireeti.

Delivery-date: Tue, 26 Feb 2002 07:47:35 -0800
From: [email-masked]
Date: Tue, 26 Feb 2002 09:46:56 -0600
Subject: RE: draft-bonica-tunneltrace-02
TO: [email-masked]
CC: [email-masked]

> > (a) it should be a WG document?

Since it is in the "right spirit" :-)

Delivery-date: Tue, 26 Feb 2002 07:47:32 -0800
From: Heiles Juergen <[email-masked]>
To: "'Stephen Trowbridge'" <[email-masked]>, "Mannie, Eric" <[email-masked]>
Cc: Heiles Juergen <[email-masked]>, "[email-masked]'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: RE: Simple solution to terminate the discussion about SONET versu s SDH
Date: Tue, 26 Feb 2002 16:45:55 +0100

I wanted to add some clarifications to my "YES", but Steve did it first.

Both SONET and SDH have Options like the 16 or 64 byte trace for the J1. SDH defines the 16 byte trace as a must when crossing international borders or operator domains, if not mutual agreed otherwise by the involved operators and it allows the 64 byte trace within national networks and operator domains.
Also the "SONET enhanced RDI" is described as an option for SDH in an Appendix of G.707.
 
If you want to have interworking even within a "SDH or SONET network" you have to consider these options. A general selection between SDH and SONET doesn't help at all.

Regards

Juergen

> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 4:22 PM
> To: Mannie, Eric
> Cc: 'Heiles Juergen'; [email-masked]'; Wijnen, Bert (Bert);
> [email-masked]'; ccamp-wg; [email-masked]'; 'Kireeti Kompella'
> Subject: Re: Simple solution to terminate the discussion about SONET
> versus SDH
> 
> 
> Eric,
> I don't think you ask quite the right question.
> The right question is:
> Can all frame structures which are common to SONET and SDH be 
> interconnected,
> and do they interoperate? This is what we care about from the 
> viewpoint of
> establishing switched connections.
> The answer to this is YES.
> 
> Are they fully identical from all points of view? As Juergen 
> says, this is the
> tricky question, as the answer of "No" might mislead some 
> into thinking that
> these signals cannot be interconnected between SONET and SDH. 
> This is not
> the case.
> 
> For those who care, some of the key differences are as 
> follows. Note that these
> do NOT affect the ability to interconnect these signals 
> (although sometimes there
> are rules about HOW to interconnect them).
> 
> SS bits - In the past, this was an issue in the high order 
> pointers. SDH sent
> and expected "10", for SONET these bits were unspecified. 
> This problem was corrected
> a few years ago by requiring that ALL equipment send "10" and 
> ignore the incoming
> bits. Note that even prior to aligning the standards, a great 
> deal of the older
> equipment followed this strategy as VC-4s and STS-3cs were 
> interconnected long
> before the standards alignment.
> 
> Trace identifier - For J1, within SONET, a 64 byte format is 
> normally used. For SDH,
> a 16 byte format is normally used. SONET specifies that in 
> the case that the far end
> is SDH, a 16 byte format should be used to allow 
> interworking. For J2, this is normally
> used in SDH and not normally in SONET. Interworking is 
> acheived by having the SDH end
> ignore the incoming trace identifier (a required capability 
> in the standards).
> 
> RDI - SONET uses some extra bits that are reserved in SDH to 
> further classify far end
> alarms (called ENHANCED RDI). This provides no obstacle to 
> interworking: The SONET
> side will not be able to provide a more detailed 
> classification of SDH end alarms (it
> does know there is a far end alarm). The SDH end ignores the 
> extra bits. The Enhanced
> RDI feature only operates if both ends are SONET.
> 
> BIP - The coding for BIP is identical. The way degrade is 
> detected is different.
> SONET generally uses a Poisson algorithm to declare degrade 
> and SDH normally uses
> a bursty error detection algorithm. This provides no obstacle 
> to interconnect - the
> criteria for declaring dDEG is just slightly different. Also, 
> SONET provides an
> EXC alarm for BER > 10^-3 which does not appear in SDH. This 
> also does not prevent
> interconnect - you just have an alarm which can be declared 
> at one end and not the
> other.
> 
> These are the major differences (besides the fact that SONET 
> and SDH tend to have
> different names for identical things- This is just a 
> US/Europe language issue).
> Regards,
> Steve
> 
> "Mannie, Eric" wrote:
> > 
> > Dear All,
> > 
> > There is an easy way to stop definitively this discussion 
> based on technical
> > facts:
> > 
> > Stephen, Juergen and Maarten, please tell us: today, are the frame
> > structures and all the bytes in the SDH and SONET overhead 
> completely
> > identical, used and interpreted in the same way, is the 
> monitoring exactly
> > the same ? In particular, if I provision and operate an SDH 
> circuit/LSP is
> > this fully identical to a SONET circuit/LSP from *all* 
> point of views ?
> > 
> > PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not 
> needed at this
> > stage.
> > 
> > If the answer is yes: SONET is totally identical to SDH.
> > If the answer is no: SONET is not the same as SDH.
> > 
> > I think that without that answer we cannot take any 
> *technical* decision on
> > this mailing list and at the IETF.
> > 
> > Thanks to answer.
> > 
> > Kind regards,
> > 
> > Eric
> > 
> > ps: feel free to forward this e-mail to any ITU-T mailing list if a
> > confirmation is needed.
> 

Delivery-date: Tue, 26 Feb 2002 07:26:52 -0800
Date: Tue, 26 Feb 2002 08:26:36 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Eric,

"Mannie, Eric" wrote:
snip
> Do you mean that we will remove the terms SONET, the concepts (VT, STS,
> etc), and the references from all GMPLS drafts and that GMPLS will have a
> reduced scope to SDH only ?
Not at all. The document is intended for use in both markets. To be "reader-
friendly" in both markets, it should have dual vocabulary. The objection is
to dual CODING for identical constructs. The dual vocabulary (e.g.,
SDH/SONET, VC-11/VT1.5, VC-12/VT2, VC-4/STS-3c) is useful since we have
readers who speak different "languages".
Regards,
Steve

Delivery-date: Tue, 26 Feb 2002 07:23:13 -0800
Date: Tue, 26 Feb 2002 08:22:26 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'Heiles Juergen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Re: Simple solution to terminate the discussion about SONET versus SDH

Eric,
I don't think you ask quite the right question.
The right question is:
Can all frame structures which are common to SONET and SDH be interconnected,
and do they interoperate? This is what we care about from the viewpoint of
establishing switched connections.
The answer to this is YES.

Are they fully identical from all points of view? As Juergen says, this is the
tricky question, as the answer of "No" might mislead some into thinking that
these signals cannot be interconnected between SONET and SDH. This is not
the case.

For those who care, some of the key differences are as follows. Note that these
do NOT affect the ability to interconnect these signals (although sometimes there
are rules about HOW to interconnect them).

SS bits - In the past, this was an issue in the high order pointers. SDH sent
and expected "10", for SONET these bits were unspecified. This problem was corrected
a few years ago by requiring that ALL equipment send "10" and ignore the incoming
bits. Note that even prior to aligning the standards, a great deal of the older
equipment followed this strategy as VC-4s and STS-3cs were interconnected long
before the standards alignment.

Trace identifier - For J1, within SONET, a 64 byte format is normally used. For SDH,
a 16 byte format is normally used. SONET specifies that in the case that the far end
is SDH, a 16 byte format should be used to allow interworking. For J2, this is normally
used in SDH and not normally in SONET. Interworking is acheived by having the SDH end
ignore the incoming trace identifier (a required capability in the standards).

RDI - SONET uses some extra bits that are reserved in SDH to further classify far end
alarms (called ENHANCED RDI). This provides no obstacle to interworking: The SONET
side will not be able to provide a more detailed classification of SDH end alarms (it
does know there is a far end alarm). The SDH end ignores the extra bits. The Enhanced
RDI feature only operates if both ends are SONET.

BIP - The coding for BIP is identical. The way degrade is detected is different.
SONET generally uses a Poisson algorithm to declare degrade and SDH normally uses
a bursty error detection algorithm. This provides no obstacle to interconnect - the
criteria for declaring dDEG is just slightly different. Also, SONET provides an
EXC alarm for BER > 10^-3 which does not appear in SDH. This also does not prevent
interconnect - you just have an alarm which can be declared at one end and not the
other.

These are the major differences (besides the fact that SONET and SDH tend to have
different names for identical things- This is just a US/Europe language issue).
Regards,
Steve

"Mannie, Eric" wrote:
> 
> Dear All,
> 
> There is an easy way to stop definitively this discussion based on technical
> facts:
> 
> Stephen, Juergen and Maarten, please tell us: today, are the frame
> structures and all the bytes in the SDH and SONET overhead completely
> identical, used and interpreted in the same way, is the monitoring exactly
> the same ? In particular, if I provision and operate an SDH circuit/LSP is
> this fully identical to a SONET circuit/LSP from *all* point of views ?
> 
> PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not needed at this
> stage.
> 
> If the answer is yes: SONET is totally identical to SDH.
> If the answer is no: SONET is not the same as SDH.
> 
> I think that without that answer we cannot take any *technical* decision on
> this mailing list and at the IETF.
> 
> Thanks to answer.
> 
> Kind regards,
> 
> Eric
> 
> ps: feel free to forward this e-mail to any ITU-T mailing list if a
> confirmation is needed.

Delivery-date: Tue, 26 Feb 2002 07:10:15 -0800
From: Heiles Juergen <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 16:09:33 +0100

I vote 1)

Juergen

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Monday, February 25, 2002 1:11 AM
> To: Wijnen, Bert (Bert)
> Cc: Mannie, Eric; [email-masked]'; [email-masked]'; ccamp-wg;
> [email-masked]'
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> 
> 
> On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:
> 
> > Guys... I have seen to much of this. I have asked Kireeti
> > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> > WG mailing list. I do NOT want another 500 emails going back
> > and forth on this issue. We need to approach this pragmatically.
> > 
> > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the 
> >   WG mailing list on what exactly we agreed in SLC. That will
> >   help to prepare a response to ITU-T as well
> 
> First off, I should apologize for letting this go on unchecked.
> 
> Second, I should make it known to the WG as a whole that there was
> a discussion of this issue at SLC among several folks directly
> involved, the ADs and the chairs.  I thought we had achieved
> consensus, but now it seems not.
> 
> Here's what I thought we had agreed:
> 
> 1) There is a document in the ITU that defines a *single* 
> standard that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the 
> only such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET
>    that do not match the ITU document.
> 
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
> 
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
> 
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
> 
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
> 
> Thanks,
> Kireeti.
> 
> 

Delivery-date: Tue, 26 Feb 2002 07:08:27 -0800
From: "Natale, Robert C (Bob)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 10:08:10 -0500

Hi,

Speaking as a non-expert in some of the technicalities
involved but as one who has reviewed the source docs
and the e-mail threads:

I would cast my vote for 1) -- which, based on ITU-T
TD44, I would interpret as meaning having a single
set of traffic parameters and label values for SDH
*which, for all practical purposes, also encompass
SONET*.

I could also support option 4) -- articulated separately
by Eric -- as a generalization of the above.

Option 2) would seem to introduce a degree of
implementation optionality that ought to be avoided.

Thanks,

BobN

> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: Tuesday, February 26, 2002 4:37 AM
> To: ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> CCAMP WG members, 
> 
> before we start down another many 100s of emails re-discussing
> the same topic....
> 
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
> 
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> > 
> > 1) Do you think we should have just a single set of traffic 
> parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> > 
> > (in the above, SHOULD and MUST are to be interpreted as in 
> RFC 2119.)
> > 
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Thanks
> Bert, speaking as AD who would like to see the WG take 
>       a decision on this topic.
> 

Delivery-date: Tue, 26 Feb 2002 07:07:16 -0800
From: "Mannie, Eric" <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 16:05:58 +0100

Hello Bert and Kireeti,

Please could you clarify what means (1):

> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?

Do you mean that we will remove the terms SONET, the concepts (VT, STS,
etc), and the references from all GMPLS drafts and that GMPLS will have a
reduced scope to SDH only ?

If yes, why ?

Thanks,

Kind regards,

Eric

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 10:37 AM
To: ccamp-wg
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

CCAMP WG members, 

before we start down another many 100s of emails re-discussing
the same topic....

PLEASE express your support for one of the 3 options that Kireeti
posed to the WG. Don't elaborate... just help the WG chair(s) to
figure out the (rough) consensus of the WG. The choices formulated
by Kireeti:

> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Thanks
Bert, speaking as AD who would like to see the WG take 
      a decision on this topic.

Delivery-date: Tue, 26 Feb 2002 06:54:11 -0800
Date: Tue, 26 Feb 2002 09:54:34 -0600
From: Eve Varma <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Hi Kireeti,

My feedback is support for (1).

Cheers,
   Eve
> 
> Kireeti Kompella wrote:
> snip
> >
> > 
> >  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> >
> > Feedback is welcome from *all* those interested in the CCAMP WG.
> > Also, what we are looking for is rough consensus, not votes.
> >
> > Thanks,
> > Kireeti.

Delivery-date: Tue, 26 Feb 2002 06:46:48 -0800
From: Shahram Davari <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, David Allan <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Tue, 26 Feb 2002 06:44:41 -0800

Kireeti,

I vote for (b).

-Shahram

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Sunday, February 24, 2002 7:47 PM
> To: David Allan
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> 
> Let me say a few words:
> 
> 1) There was good support for this work (the requirements doc) to
>    be a WG document at a previous IETF.  It is a good thing to
>    follow up and check what the mailing list thinks, as not everyone
>    attends IETFs.
> 
> 2) It is interesting that no one brought up the issue of whether this
>    work (tunnel tracing) is in the charter or not at the meeting.
>    There are those who think the charter isn't explicit enough.  I'll
>    talk to the ADs and see (a) if they think that this *is* in the
>    charter; (b) if not, are they willing to take it to the IESG and
>    add it to the charter.
> 
>    My input on this (as WG chair) is that CCAMP is all about tunnels,
>    and a protocol to debug and test tunnels is well within scope, even
>    if not called out explicitly.
> 
>    Note that the charter is *not* subject to WG consensus, nor even
>    the WG chairs.  The IESG (and IAB?) are solely responsible,
>    although the WG and chairs can suggest changes.
> 
> 3) A document that is "in the right spirit" can become a WG document,
>    even if there are disagreements about some details, and even
>    "fundamental" questions.  Note that "fundamental" is often
>    subjective.
> 
> I would like to have the mailing list equivalent of a 'show of hands'
> regarding this draft.  Do you think:
> (a) it should be a WG document?
> (b) it's good stuff, but not ready?
> (c) we need a new start?
> 
> Please send in your opinions with one of the above up top.  Any
> detailed reasoning you have for your opinion may follow.
> 
> Thanks!
> Kireeti.
> 
> 

Delivery-date: Tue, 26 Feb 2002 06:29:12 -0800
From: Bala Rajagopalan <[email-masked]>
To: "'Mannie, Eric '" <[email-masked]>, "''Wijnen, Bert (Bert)' '" <[email-masked]>, 'ccamp-wg ' <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 09:15:39 -0500

Vote for (2).

Bala

-----Original Message-----
From: Mannie, Eric
To: 'Wijnen, Bert (Bert)'; ccamp-wg
Sent: 2/26/02 6:17 AM
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

(2) for me

Eric

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 10:37 AM
To: ccamp-wg
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

CCAMP WG members, 

before we start down another many 100s of emails re-discussing
the same topic....

PLEASE express your support for one of the 3 options that Kireeti
posed to the WG. Don't elaborate... just help the WG chair(s) to
figure out the (rough) consensus of the WG. The choices formulated
by Kireeti:

> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Thanks
Bert, speaking as AD who would like to see the WG take 
      a decision on this topic.

Delivery-date: Tue, 26 Feb 2002 06:18:28 -0800
Date: Tue, 26 Feb 2002 15:17:36 +0100
From: [email-masked]
Organization: Alcatel Bell - IPO NA (Antwerpen)
To: Eve Varma <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "'Mak, L (Leen)'" <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>
Subject: Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status]

Eve,

the E-NNI interface is an "administrative" partitioning of the control
plane within the same layer, then additional sub-partitioning are 
provided for design and topology issues but always within the same
layer (to be brief, the latter is what g.8080 refers to as I-NNI). I 
refer here to g.8080 "The transport plane is also partitioned to match 
the administrative domains." since it is a partitioning the model lies 
on the same layer. My remark focus on the client-server-client (router-
to-XC-to-router, to be more illustrative) where the call-connection
separation applies, to be even more clear this is recursive, meaning
that for instance (SDH-to-G.709-to-SDH, to be illustrative) also 
requires call-connection separation.

hope this clarifies,
- dimitri.

Eve Varma wrote:
> 
> Hi Dimitri,
>    Just a quick note re information flows per G.807 - it is correct that for the
> UNI reference point, network routing information is not provided; typical info
> flows include policy and endpoint information.  However, for the E-NNI reference
> point expected info flows include reachability/summarization info, and for the
> I-NNI ref. point topology and routing information is expected.
>                                         Cheers,
>                                             Eve
> 
> [email-masked] wrote:
> >
> > Bert,
> >
> > i see many issues, the statement refers to "call" while from the
> > ietf terminology, this term is referred to as "session"; as such
> > it could be appropriate from our side to review the statement
> > made in the "ITU liaison" because the proposed separation plugs
> > a "telephony-oriented" model (or telephony-like model) to a data
> > /circuit switched oriented network - but not with "64kb" - one
> > speak here about connections from 51.84 Mb (more precisely the
> > payload of a C3 is 48384 kbps) to 2.5, 10 or even 40 Gbps !
> > This separation (adapted for public telephony network) is also
> > constructed on an assumption that there is no control plane
> > protocol as we have today with GMPLS protocols but that connection
> > signalling is performed by the transport plane (using embedded
> > signalling) or through management plane. So there is an under-
> > lying fundamental question isn't the G.ASON model only a "public
> > overlay model" and then we have to ask ourself if the scope of
> > GMPLS has to be adapated/restricted to such public networks
> > using an overlay control plane inter-connection: imho, clearly no
> > but what could be considered is a "GMPLS profile" for G.ASON.
> >
> > Moreover this "assumption" resulted to the fact that G.ASON is
> > based on a fundamental assumption: no routing information exchange
> > between the client and server layer. GMPLS does not have such
> > stringent restriction. Consequently, this makes the separation
> > call/connection (while mandatory per requirement in the stringent
> > G.ASON model) not at all mandatory in the IETF scope since the
> > "routing exchanges" fulfill the role played by the call operation:
> > the source knows the status and the availability of the set of
> > destinations it can reach. Since routing is one of the foundation
> > of any data network, i think we should probably also discuss if
> > this separation is adapted for other types of GMPLS networks. In
> > brief, i don't think we have to restrict the ubiquity of the GMPLS
> > protocol suite.
> >
> > Hope this clarifies,
> >
> > regards,
> > - dimitri.
> >
> > "Wijnen, Bert (Bert)" wrote:
> > >
> > > Erik et all, the "official communications from the ITU" are
> > > listed under the Liaison Statements on the IETF Web Page.
> > > The page is at: http://www.ietf.org/IESG/liaison.html
> > >
> > > If you see trouble/issues with any of those, pls let WG chairs and
> > > ADs know, so we can take action.
> > >
> > > Bert
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > Address: Alcatel - Optical NA, Fr. Wellesplein, 1
> >          B-2018 Antwerpen, Belgium
> > Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

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

Delivery-date: Tue, 26 Feb 2002 06:16:12 -0800
Date: Tue, 26 Feb 2002 15:15:04 +0100
From: [email-masked]
Organization: Alcatel Bell - IPO NA (Antwerpen)
To: Osama Aboul-Magd <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "'Mak, L (Leen)'" <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>
Subject: Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status]

Osama,

i am not saying something different than what you say when i 
refer to a "GMPLS profile for G.ASON." the key issue is to
see until which point "extensions" would have to impact the
current efforts. What i don't want is to restrict the ubiquity
of GMPLS protocol suite.

regards,
- dimitri.

> Osama Aboul-Magd wrote:
> 
> Dimitri,
> 
> You can also look at GMPLS as a tool kit that is applicable to
> different models, ASON being one of them.
> 
> Yes, ASON is an overlay model. There is no reason why GMPLS based
> protocols for signaling and routing could not be used for ASON control
> plane implementation. Your statement regarding "restricting" routing
> information between client and server networks only reflects your
> preference to deploy a peer model. This is fine, but do not impose
> artificial requirements that wouldn't allow the application of GMPLS
> protocols to other models. The last time I looked at the IP over
> optical framework, overlay was one of the models discussed.
> 
> I have been saying in a number of presentations to the IPO WG (in the
> context of "draft-ietf-ipo-ason-01.txt") that ASON and GMPLS are
> complementary in the sense that GMPLS protocols could be used for ASON
> control plane realizations. The latest activities at the ITU just
> prove that.
> 
> Regards;
> 
> Osama Aboul-Magd
> Nortel Networks
> P.O. Box 3511, Station "C"
> Ottawa, ON, Canada
> K1Y - 4H7
> Tel: 613-763-5827
> e.mail: [email-masked]
> 
>  -----Original Message-----
> From:   [email-masked]
> [mailto:[email-masked]]
> Sent:   Tuesday, February 26, 2002 8:43 AM
> To:     Wijnen, Bert (Bert)
> Cc:     Mannie, Eric; 'Mak, L (Leen)'; [email-masked]; Kireeti
> Kompella
> Subject:        Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG
> dcoument status]
> 
> Bert,
> 
> i see many issues, the statement refers to "call" while from the
> ietf terminology, this term is referred to as "session"; as such
> it could be appropriate from our side to review the statement
> made in the "ITU liaison" because the proposed separation plugs
> a "telephony-oriented" model (or telephony-like model) to a data
> /circuit switched oriented network - but not with "64kb" - one
> speak here about connections from 51.84 Mb (more precisely the
> payload of a C3 is 48384 kbps) to 2.5, 10 or even 40 Gbps !
> This separation (adapted for public telephony network) is also
> constructed on an assumption that there is no control plane
> protocol as we have today with GMPLS protocols but that connection
> signalling is performed by the transport plane (using embedded
> signalling) or through management plane. So there is an under-
> lying fundamental question isn't the G.ASON model only a "public
> overlay model" and then we have to ask ourself if the scope of
> GMPLS has to be adapated/restricted to such public networks
> using an overlay control plane inter-connection: imho, clearly no
> but what could be considered is a "GMPLS profile" for G.ASON.
> 
> Moreover this "assumption" resulted to the fact that G.ASON is
> based on a fundamental assumption: no routing information exchange
> between the client and server layer. GMPLS does not have such
> stringent restriction. Consequently, this makes the separation
> call/connection (while mandatory per requirement in the stringent
> G.ASON model) not at all mandatory in the IETF scope since the
> "routing exchanges" fulfill the role played by the call operation:
> the source knows the status and the availability of the set of
> destinations it can reach. Since routing is one of the foundation
> of any data network, i think we should probably also discuss if
> this separation is adapted for other types of GMPLS networks. In
> brief, i don't think we have to restrict the ubiquity of the GMPLS
> protocol suite.
> 
> Hope this clarifies,
> 
> regards,
> - dimitri.
> 
> "Wijnen, Bert (Bert)" wrote:
> >
> > Erik et all, the "official communications from the ITU" are
> > listed under the Liaison Statements on the IETF Web Page.
> > The page is at: http://www.ietf.org/IESG/liaison.html
> >
> > If you see trouble/issues with any of those, pls let WG chairs and
> > ADs know, so we can take action.
> >
> > Bert
> 
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
> Address: Alcatel - Optical NA, Fr. Wellesplein, 1
>          B-2018 Antwerpen, Belgium
> Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

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

Delivery-date: Tue, 26 Feb 2002 06:09:21 -0800
From: "Osama Aboul-Magd"<[email-masked]>
To: [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, "'Mak, L (Leen)'" <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>
Subject: RE: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument s tatus]
Date: Tue, 26 Feb 2002 09:08:45 -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_01C1BECF.1AC4D720
Content-Type: text/plain;
	charset="iso-8859-1"

Dimitri,

You can also look at GMPLS as a tool kit that is applicable to different
models, ASON being one of them.

Yes, ASON is an overlay model. There is no reason why GMPLS based protocols
for signaling and routing could not be used for ASON control plane
implementation. Your statement regarding "restricting" routing information
between client and server networks only reflects your preference to deploy a
peer model. This is fine, but do not impose artificial requirements that
wouldn't allow the application of GMPLS protocols to other models. The last
time I looked at the IP over optical framework, overlay was one of the
models discussed.

I have been saying in a number of presentations to the IPO WG (in the
context of "draft-ietf-ipo-ason-01.txt") that ASON and GMPLS are
complementary in the sense that GMPLS protocols could be used for ASON
control plane realizations. The latest activities at the ITU just prove
that. 

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

 -----Original Message-----
From: 	[email-masked]
[mailto:[email-masked]] 
Sent:	Tuesday, February 26, 2002 8:43 AM
To:	Wijnen, Bert (Bert)
Cc:	Mannie, Eric; 'Mak, L (Leen)'; [email-masked]; Kireeti Kompella
Subject:	Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG
dcoument status]

Bert,

i see many issues, the statement refers to "call" while from the 
ietf terminology, this term is referred to as "session"; as such
it could be appropriate from our side to review the statement
made in the "ITU liaison" because the proposed separation plugs 
a "telephony-oriented" model (or telephony-like model) to a data 
/circuit switched oriented network - but not with "64kb" - one 
speak here about connections from 51.84 Mb (more precisely the
payload of a C3 is 48384 kbps) to 2.5, 10 or even 40 Gbps ! 
This separation (adapted for public telephony network) is also 
constructed on an assumption that there is no control plane
protocol as we have today with GMPLS protocols but that connection 
signalling is performed by the transport plane (using embedded 
signalling) or through management plane. So there is an under-
lying fundamental question isn't the G.ASON model only a "public 
overlay model" and then we have to ask ourself if the scope of 
GMPLS has to be adapated/restricted to such public networks 
using an overlay control plane inter-connection: imho, clearly no
but what could be considered is a "GMPLS profile" for G.ASON.

Moreover this "assumption" resulted to the fact that G.ASON is
based on a fundamental assumption: no routing information exchange 
between the client and server layer. GMPLS does not have such 
stringent restriction. Consequently, this makes the separation
call/connection (while mandatory per requirement in the stringent 
G.ASON model) not at all mandatory in the IETF scope since the 
"routing exchanges" fulfill the role played by the call operation: 
the source knows the status and the availability of the set of
destinations it can reach. Since routing is one of the foundation 
of any data network, i think we should probably also discuss if 
this separation is adapted for other types of GMPLS networks. In
brief, i don't think we have to restrict the ubiquity of the GMPLS 
protocol suite.

Hope this clarifies,

regards,
- dimitri.

"Wijnen, Bert (Bert)" wrote:
> 
> Erik et all, the "official communications from the ITU" are
> listed under the Liaison Statements on the IETF Web Page.
> The page is at: http://www.ietf.org/IESG/liaison.html
> 
> If you see trouble/issues with any of those, pls let WG chairs and
> ADs know, so we can take action.
> 
> Bert

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

------_=_NextPart_001_01C1BECF.1AC4D720
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument =
status]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dimitri,</FONT>
</P>

<P><FONT SIZE=3D2>You can also look at GMPLS as a tool kit that is =
applicable to different models, ASON being one of them.</FONT>
</P>

<P><FONT SIZE=3D2>Yes, ASON is an overlay model. There is no reason why =
GMPLS based protocols for signaling and routing could not be used for =
ASON control plane implementation. Your statement regarding =
&quot;restricting&quot; routing information between client and server =
networks only reflects your preference to deploy a peer model. This is =
fine, but do not impose artificial requirements that wouldn't allow the =
application of GMPLS protocols to other models. The last time I looked =
at the IP over optical framework, overlay was one of the models =
discussed.</FONT></P>

<P><FONT SIZE=3D2>I have been saying in a number of presentations to =
the IPO WG (in the context of &quot;draft-ietf-ipo-ason-01.txt&quot;) =
that ASON and GMPLS are complementary in the sense that GMPLS protocols =
could be used for ASON control plane realizations. The latest =
activities at the ITU just prove that. </FONT></P>

<P><FONT SIZE=3D2>Regards;</FONT>
</P>

<P><FONT SIZE=3D2>Osama Aboul-Magd</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>P.O. Box 3511, Station &quot;C&quot;</FONT>
<BR><FONT SIZE=3D2>Ottawa, ON, Canada</FONT>
<BR><FONT SIZE=3D2>K1Y - 4H7</FONT>
<BR><FONT SIZE=3D2>Tel: 613-763-5827</FONT>
<BR><FONT SIZE=3D2>e.mail: [email-masked]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:Dimitri.Papadimi=
[email-masked]</A>] </FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Tuesday, February 26, 2002 8:43 =
AM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Wijnen, Bert =
(Bert)</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; Mannie, Eric; 'Mak, L =
(Leen)'; [email-masked]; Kireeti Kompella</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument =
status]</FONT>
</P>

<P><FONT SIZE=3D2>Bert,</FONT>
</P>

<P><FONT SIZE=3D2>i see many issues, the statement refers to =
&quot;call&quot; while from the </FONT>
<BR><FONT SIZE=3D2>ietf terminology, this term is referred to as =
&quot;session&quot;; as such</FONT>
<BR><FONT SIZE=3D2>it could be appropriate from our side to review the =
statement</FONT>
<BR><FONT SIZE=3D2>made in the &quot;ITU liaison&quot; because the =
proposed separation plugs </FONT>
<BR><FONT SIZE=3D2>a &quot;telephony-oriented&quot; model (or =
telephony-like model) to a data </FONT>
<BR><FONT SIZE=3D2>/circuit switched oriented network - but not with =
&quot;64kb&quot; - one </FONT>
<BR><FONT SIZE=3D2>speak here about connections from 51.84 Mb (more =
precisely the</FONT>
<BR><FONT SIZE=3D2>payload of a C3 is 48384 kbps) to 2.5, 10 or even 40 =
Gbps ! </FONT>
<BR><FONT SIZE=3D2>This separation (adapted for public telephony =
network) is also </FONT>
<BR><FONT SIZE=3D2>constructed on an assumption that there is no =
control plane</FONT>
<BR><FONT SIZE=3D2>protocol as we have today with GMPLS protocols but =
that connection </FONT>
<BR><FONT SIZE=3D2>signalling is performed by the transport plane =
(using embedded </FONT>
<BR><FONT SIZE=3D2>signalling) or through management plane. So there is =
an under-</FONT>
<BR><FONT SIZE=3D2>lying fundamental question isn't the G.ASON model =
only a &quot;public </FONT>
<BR><FONT SIZE=3D2>overlay model&quot; and then we have to ask ourself =
if the scope of </FONT>
<BR><FONT SIZE=3D2>GMPLS has to be adapated/restricted to such public =
networks </FONT>
<BR><FONT SIZE=3D2>using an overlay control plane inter-connection: =
imho, clearly no</FONT>
<BR><FONT SIZE=3D2>but what could be considered is a &quot;GMPLS =
profile&quot; for G.ASON.</FONT>
</P>

<P><FONT SIZE=3D2>Moreover this &quot;assumption&quot; resulted to the =
fact that G.ASON is</FONT>
<BR><FONT SIZE=3D2>based on a fundamental assumption: no routing =
information exchange </FONT>
<BR><FONT SIZE=3D2>between the client and server layer. GMPLS does not =
have such </FONT>
<BR><FONT SIZE=3D2>stringent restriction. Consequently, this makes the =
separation</FONT>
<BR><FONT SIZE=3D2>call/connection (while mandatory per requirement in =
the stringent </FONT>
<BR><FONT SIZE=3D2>G.ASON model) not at all mandatory in the IETF scope =
since the </FONT>
<BR><FONT SIZE=3D2>&quot;routing exchanges&quot; fulfill the role =
played by the call operation: </FONT>
<BR><FONT SIZE=3D2>the source knows the status and the availability of =
the set of</FONT>
<BR><FONT SIZE=3D2>destinations it can reach. Since routing is one of =
the foundation </FONT>
<BR><FONT SIZE=3D2>of any data network, i think we should probably also =
discuss if </FONT>
<BR><FONT SIZE=3D2>this separation is adapted for other types of GMPLS =
networks. In</FONT>
<BR><FONT SIZE=3D2>brief, i don't think we have to restrict the =
ubiquity of the GMPLS </FONT>
<BR><FONT SIZE=3D2>protocol suite.</FONT>
</P>

<P><FONT SIZE=3D2>Hope this clarifies,</FONT>
</P>

<P><FONT SIZE=3D2>regards,</FONT>
<BR><FONT SIZE=3D2>- dimitri.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;Wijnen, Bert (Bert)&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Erik et all, the &quot;official communications =
from the ITU&quot; are</FONT>
<BR><FONT SIZE=3D2>&gt; listed under the Liaison Statements on the IETF =
Web Page.</FONT>
<BR><FONT SIZE=3D2>&gt; The page is at: <A =
HREF=3D"http://www.ietf.org/IESG/liaison.html" =
TARGET=3D"_blank">http://www.ietf.org/IESG/liaison.html</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If you see trouble/issues with any of those, =
pls let WG chairs and</FONT>
<BR><FONT SIZE=3D2>&gt; ADs know, so we can take action.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Bert</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Papadimitriou Dimitri </FONT>
<BR><FONT SIZE=3D2>E-mail : [email-masked] </FONT>
<BR><FONT SIZE=3D2>Website: <A =
HREF=3D"http://www.rc.bel.alcatel.be/~papadimd/index.html" =
TARGET=3D"_blank">http://www.rc.bel.alcatel.be/~papadimd/index.html</A><=
/FONT>
<BR><FONT SIZE=3D2>Address: Alcatel - Optical NA, Fr. Wellesplein, 1 =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
B-2018 Antwerpen, Belgium</FONT>
<BR><FONT SIZE=3D2>Phone:&nbsp;&nbsp; Work: +32 3 2408491 - Home: +32 2 =
3434361</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BECF.1AC4D720--

Delivery-date: Tue, 26 Feb 2002 06:03:52 -0800
From: "Don Fedyk"<[email-masked]>
To: "Bernstein, Greg" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Routing drafts
Date: Tue, 26 Feb 2002 09:03:33 -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_01C1BECE.6058B050
Content-Type: text/plain;
	charset="iso-8859-1"

Greg

Yes I recall the discussions on this. The bandwidth summaries are 
the minimal amount of information to make a routing decision. They 
do not cover all of the detail that could be in a timeslot map. 
Integers are definitely not dynamic enough. The issue is that even 
if you have this detailed information you still have to augment 
signaling with the capability to deal with glare conditions. So 
our strategy was not to overburden routing with this information
but to put the capability in signaling.

Don 

-----Original Message-----
>From: Bernstein, Greg [mailto:[email-masked]]
>Sent: Monday, February 25, 2002 8:32 PM
>To: Fedyk, Don [BL60:1A00:EXCH]; Kireeti Kompella; [email-masked]
>Subject: RE: Routing drafts.
>
>
>Actually floating point is overkill for TDM.  We'd like to use small 
>integers to describe and update them more frequently.  
>The TDM multiplexing is straight forward but unforgiving. 
>We had this same discussion when we decided to breakout the labels 
>for SONET/SDH GMPLS signaling.  I want to know that I've got 14 
>STS-1 of capacity, XX unused VT1.5, etc...  For those SONET/SDH 
>systems that have to deal with timeslot inflexibility (i.e., 
>fragementations issues) more complete information on time slot 
>usage is advantageous.  For example with rings that don't 
>have Time Slot Interchange, a map of the timeslots could 
>be helpful.  Eric and I had a bunch of stuff about this in 
>our earlier routing drafts.
> 
>Greg B.
> 
>---------------------------------------------------------------------------
-----------
>Dr. Greg M. Bernstein, Sr. Director Technology, Ciena Corp.
 
>-----Original Message-----
>From: Don Fedyk [mailto:[email-masked]] 
>Sent: Monday, February 25, 2002 4:07 PM
>To: Bernstein, Greg; Kireeti Kompella; [email-masked]
>Subject: RE: Routing drafts
> 
>Greg you wrote: 
>> (b) Big issue -- The parameters for representing bandwidth on 
>> a link are not 
>> very appropriate for TDM signals or WDM signals.  I've 
>> included below some 
>> more explanation taken from the IPO working group draft. 
>> However, this is 
>> the same thing that led to us breaking out the traffic 
>> descriptor stuff in 
>> GMPLS signaling for the SONET/SDH case.  This is really 
>> needed here too. 
>> 
>These bandwidths in our draft are exact floating point numbers. 
>Are you saying that the resolution of the floating point is an issue 
>with optical? Or are you implying that bandwidths are percentages ? 
>The text below is implying that statistical multiplexing can use 
>inexact bandwidth but optical can (and should) use exact bandwidths. 
>I did not see problems with the floating point range or our draft. 
>Don 
> 
>> (From IPO working group draft on Inter-domain optical routing) 
>> 2.3   Differences between MPLS and Optical Circuit routing 
>> 
>> The bandwidth accounting needed in optical circuit-switched 
>> networks is also 
>> different than in packet networks. In packet networks using 
>> either ATM QoS 
>> or MPLS-TE, complex statistical measures are used to 
>> characterize the load 
>> on a link, often with varying degrees of accuracy.  The 
>> inexactness of such 
>> measures and the "compressibility" of statistically 
>> multiplexed traffic 
>> imply that a small percentage change in link utilization can 
>> usually be 
>> absorbed by the network. 
>> 
>> By contrast, if an OC-192 link has just one STS-1 path 
>> occupied (less than 
>> 1% of the link bandwidth), it cannot accommodate an STS-192c 
>> path. Due to 
>> the relatively simple finite multiplex structures currently 
>> use in optical 
>> networks tracking bandwidth resources is much easier than 
>> packet switched 
>> networks, however much stricter bandwidth accounting is 
>> required on circuit 
>> switched links. In particular, it is expected that an 
>> individual optical 
>> circuit switched link can be fully utilized, while due to 
>> queuing effects a 
>> packet switched link on average can never be run at full 
>> capacity and is 
>> typically run at less then 80% of capacity.  
>>   
>> Greg B. 
>> 

------_=_NextPart_001_01C1BECE.6058B050
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: Routing drafts</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Greg</FONT>
</P>

<P><FONT SIZE=2>Yes I recall the discussions on this. The bandwidth summaries are </FONT>
<BR><FONT SIZE=2>the minimal amount of information to make a routing decision. They </FONT>
<BR><FONT SIZE=2>do not cover all of the detail that could be in a timeslot map. </FONT>
<BR><FONT SIZE=2>Integers are definitely not dynamic enough. The issue is that even </FONT>
<BR><FONT SIZE=2>if you have this detailed information you still have to augment </FONT>
<BR><FONT SIZE=2>signaling with the capability to deal with glare conditions. So </FONT>
<BR><FONT SIZE=2>our strategy was not to overburden routing with this information</FONT>
<BR><FONT SIZE=2>but to put the capability in signaling.</FONT>
</P>

<P><FONT SIZE=2>Don </FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt;From: Bernstein, Greg [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt;Sent: Monday, February 25, 2002 8:32 PM</FONT>
<BR><FONT SIZE=2>&gt;To: Fedyk, Don [BL60:1A00:EXCH]; Kireeti Kompella; [email-masked]</FONT>
<BR><FONT SIZE=2>&gt;Subject: RE: Routing drafts.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Actually floating point is overkill for TDM.&nbsp; We'd like to use small </FONT>
<BR><FONT SIZE=2>&gt;integers to describe and update them more frequently.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;The TDM multiplexing is straight forward but unforgiving. </FONT>
<BR><FONT SIZE=2>&gt;We had this same discussion when we decided to breakout the labels </FONT>
<BR><FONT SIZE=2>&gt;for SONET/SDH GMPLS signaling.&nbsp; I want to know that I've got 14 </FONT>
<BR><FONT SIZE=2>&gt;STS-1 of capacity, XX unused VT1.5, etc...&nbsp; For those SONET/SDH </FONT>
<BR><FONT SIZE=2>&gt;systems that have to deal with timeslot inflexibility (i.e., </FONT>
<BR><FONT SIZE=2>&gt;fragementations issues) more complete information on time slot </FONT>
<BR><FONT SIZE=2>&gt;usage is advantageous.&nbsp; For example with rings that don't </FONT>
<BR><FONT SIZE=2>&gt;have Time Slot Interchange, a map of the timeslots could </FONT>
<BR><FONT SIZE=2>&gt;be helpful.&nbsp; Eric and I had a bunch of stuff about this in </FONT>
<BR><FONT SIZE=2>&gt;our earlier routing drafts.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;Greg B.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;--------------------------------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>&gt;Dr. Greg M. Bernstein, Sr. Director Technology, Ciena Corp.</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt;From: Don Fedyk [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>&gt;Sent: Monday, February 25, 2002 4:07 PM</FONT>
<BR><FONT SIZE=2>&gt;To: Bernstein, Greg; Kireeti Kompella; [email-masked]</FONT>
<BR><FONT SIZE=2>&gt;Subject: RE: Routing drafts</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;Greg you wrote: </FONT>
<BR><FONT SIZE=2>&gt;&gt; (b) Big issue -- The parameters for representing bandwidth on </FONT>
<BR><FONT SIZE=2>&gt;&gt; a link are not </FONT>
<BR><FONT SIZE=2>&gt;&gt; very appropriate for TDM signals or WDM signals.&nbsp; I've </FONT>
<BR><FONT SIZE=2>&gt;&gt; included below some </FONT>
<BR><FONT SIZE=2>&gt;&gt; more explanation taken from the IPO working group draft. </FONT>
<BR><FONT SIZE=2>&gt;&gt; However, this is </FONT>
<BR><FONT SIZE=2>&gt;&gt; the same thing that led to us breaking out the traffic </FONT>
<BR><FONT SIZE=2>&gt;&gt; descriptor stuff in </FONT>
<BR><FONT SIZE=2>&gt;&gt; GMPLS signaling for the SONET/SDH case.&nbsp; This is really </FONT>
<BR><FONT SIZE=2>&gt;&gt; needed here too. </FONT>
<BR><FONT SIZE=2>&gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt;These bandwidths in our draft are exact floating point numbers. </FONT>
<BR><FONT SIZE=2>&gt;Are you saying that the resolution of the floating point is an issue </FONT>
<BR><FONT SIZE=2>&gt;with optical? Or are you implying that bandwidths are percentages ? </FONT>
<BR><FONT SIZE=2>&gt;The text below is implying that statistical multiplexing can use </FONT>
<BR><FONT SIZE=2>&gt;inexact bandwidth but optical can (and should) use exact bandwidths. </FONT>
<BR><FONT SIZE=2>&gt;I did not see problems with the floating point range or our draft. </FONT>
<BR><FONT SIZE=2>&gt;Don </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&gt; (From IPO working group draft on Inter-domain optical routing) </FONT>
<BR><FONT SIZE=2>&gt;&gt; 2.3&nbsp;&nbsp; Differences between MPLS and Optical Circuit routing </FONT>
<BR><FONT SIZE=2>&gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt;&gt; The bandwidth accounting needed in optical circuit-switched </FONT>
<BR><FONT SIZE=2>&gt;&gt; networks is also </FONT>
<BR><FONT SIZE=2>&gt;&gt; different than in packet networks. In packet networks using </FONT>
<BR><FONT SIZE=2>&gt;&gt; either ATM QoS </FONT>
<BR><FONT SIZE=2>&gt;&gt; or MPLS-TE, complex statistical measures are used to </FONT>
<BR><FONT SIZE=2>&gt;&gt; characterize the load </FONT>
<BR><FONT SIZE=2>&gt;&gt; on a link, often with varying degrees of accuracy.&nbsp; The </FONT>
<BR><FONT SIZE=2>&gt;&gt; inexactness of such </FONT>
<BR><FONT SIZE=2>&gt;&gt; measures and the &quot;compressibility&quot; of statistically </FONT>
<BR><FONT SIZE=2>&gt;&gt; multiplexed traffic </FONT>
<BR><FONT SIZE=2>&gt;&gt; imply that a small percentage change in link utilization can </FONT>
<BR><FONT SIZE=2>&gt;&gt; usually be </FONT>
<BR><FONT SIZE=2>&gt;&gt; absorbed by the network. </FONT>
<BR><FONT SIZE=2>&gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt;&gt; By contrast, if an OC-192 link has just one STS-1 path </FONT>
<BR><FONT SIZE=2>&gt;&gt; occupied (less than </FONT>
<BR><FONT SIZE=2>&gt;&gt; 1% of the link bandwidth), it cannot accommodate an STS-192c </FONT>
<BR><FONT SIZE=2>&gt;&gt; path. Due to </FONT>
<BR><FONT SIZE=2>&gt;&gt; the relatively simple finite multiplex structures currently </FONT>
<BR><FONT SIZE=2>&gt;&gt; use in optical </FONT>
<BR><FONT SIZE=2>&gt;&gt; networks tracking bandwidth resources is much easier than </FONT>
<BR><FONT SIZE=2>&gt;&gt; packet switched </FONT>
<BR><FONT SIZE=2>&gt;&gt; networks, however much stricter bandwidth accounting is </FONT>
<BR><FONT SIZE=2>&gt;&gt; required on circuit </FONT>
<BR><FONT SIZE=2>&gt;&gt; switched links. In particular, it is expected that an </FONT>
<BR><FONT SIZE=2>&gt;&gt; individual optical </FONT>
<BR><FONT SIZE=2>&gt;&gt; circuit switched link can be fully utilized, while due to </FONT>
<BR><FONT SIZE=2>&gt;&gt; queuing effects a </FONT>
<BR><FONT SIZE=2>&gt;&gt; packet switched link on average can never be run at full </FONT>
<BR><FONT SIZE=2>&gt;&gt; capacity and is </FONT>
<BR><FONT SIZE=2>&gt;&gt; typically run at less then 80% of capacity.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&gt; Greg B. </FONT>
<BR><FONT SIZE=2>&gt;&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BECE.6058B050--

Delivery-date: Tue, 26 Feb 2002 06:03:50 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Subject: RE: draft-ietf-ccamp-lmp-02.txt
Date: Tue, 26 Feb 2002 15:02:50 +0100

Further comments (I have not checked the whole document,
just reporting as I see thibgs while looking for specific
stuff).

The IANA considerations section is setting aside 4% of the
name space for Message Type and 8% of Object Class name space for
OIF UNI. Is that the proper thing to do?

I understand OIF has already "provisionally claimed" a few
of the "reserved" numbers. We can honor that while we move forward.
But I think it would be better to keep the whole name space assignments
in one place, and under control of IANA.

The OIF (and other organisations) can then request assignments through
the normal process, similar to how 
  http://www.ietf.org/internet-drafts/draft-bala-uni-signaling-extensions-00.txt
is trying to do right now.

By the way, you use these terms:

  - Message Type
  - Msg Type
  - MsgType

Probably better to settle for one "spelling" and be consistent I think

In IANA Considerations section you also talk about
"class and class type name spaces" while you only elaborate on the
control of the "Object Class Name Space". So are there multiple names spaces
for class and class-type or just one. There seem to be two, i.e. Object Class
and Class Type (within a class). Does the Class Type name space not have
IANA considerations?

Bert 

> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: Tuesday, February 26, 2002 11:52 AM
> To: [email-masked]
> Subject: draft-ietf-ccamp-lmp-02.txt
> 
> 
> From Kireeti's "wg document status" email
> 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:[email-masked]]
> > Sent: Monday, February 25, 2002 2:52 AM
> > To: [email-masked]
> > Subject: WG dcoument status
> > 
> > 
> > Here's a status update.
> > 
> ... snip ...
> 
> > The LMP draft:
> > 	draft-ietf-ccamp-lmp-02.txt
> > has gone through one round of WG Last Call comments and, once a
> > new version has been produced incorporating these comments, will
> > go through a final WG Last Call.  This is also targeted as a
> > Proposed Standard.
> > 
> I will note that in my view, the security section will need
> serious work. I doubt that the Security ADs will sign off on the
> current text. The security section should address the risks
> and treats. It should then specify how to protect against them.
> A text like "LMP exchanges may be authenticated with MD5" (which
> is basically what you write now) seems not sufficient to me.
> 
> Bert
> 

Delivery-date: Tue, 26 Feb 2002 05:55:08 -0800
Date: Tue, 26 Feb 2002 08:55:23 -0600
From: Eve Varma <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
CC: "Wijnen, Bert (Bert)" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "'Mak, L (Leen)'" <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>
Subject: Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status]

Hi Dimitri,
   Just a quick note re information flows per G.807 - it is correct that for the
UNI reference point, network routing information is not provided; typical info
flows include policy and endpoint information.  However, for the E-NNI reference
point expected info flows include reachability/summarization info, and for the
I-NNI ref. point topology and routing information is expected.
                                        Cheers,
                                            Eve

[email-masked] wrote:
> 
> Bert,
> 
> i see many issues, the statement refers to "call" while from the
> ietf terminology, this term is referred to as "session"; as such
> it could be appropriate from our side to review the statement
> made in the "ITU liaison" because the proposed separation plugs
> a "telephony-oriented" model (or telephony-like model) to a data
> /circuit switched oriented network - but not with "64kb" - one
> speak here about connections from 51.84 Mb (more precisely the
> payload of a C3 is 48384 kbps) to 2.5, 10 or even 40 Gbps !
> This separation (adapted for public telephony network) is also
> constructed on an assumption that there is no control plane
> protocol as we have today with GMPLS protocols but that connection
> signalling is performed by the transport plane (using embedded
> signalling) or through management plane. So there is an under-
> lying fundamental question isn't the G.ASON model only a "public
> overlay model" and then we have to ask ourself if the scope of
> GMPLS has to be adapated/restricted to such public networks
> using an overlay control plane inter-connection: imho, clearly no
> but what could be considered is a "GMPLS profile" for G.ASON.
> 
> Moreover this "assumption" resulted to the fact that G.ASON is
> based on a fundamental assumption: no routing information exchange
> between the client and server layer. GMPLS does not have such
> stringent restriction. Consequently, this makes the separation
> call/connection (while mandatory per requirement in the stringent
> G.ASON model) not at all mandatory in the IETF scope since the
> "routing exchanges" fulfill the role played by the call operation:
> the source knows the status and the availability of the set of
> destinations it can reach. Since routing is one of the foundation
> of any data network, i think we should probably also discuss if
> this separation is adapted for other types of GMPLS networks. In
> brief, i don't think we have to restrict the ubiquity of the GMPLS
> protocol suite.
> 
> Hope this clarifies,
> 
> regards,
> - dimitri.
> 
> "Wijnen, Bert (Bert)" wrote:
> >
> > Erik et all, the "official communications from the ITU" are
> > listed under the Liaison Statements on the IETF Web Page.
> > The page is at: http://www.ietf.org/IESG/liaison.html
> >
> > If you see trouble/issues with any of those, pls let WG chairs and
> > ADs know, so we can take action.
> >
> > Bert
> 
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
> Address: Alcatel - Optical NA, Fr. Wellesplein, 1
>          B-2018 Antwerpen, Belgium
> Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Tue, 26 Feb 2002 05:45:02 -0800
Date: Tue, 26 Feb 2002 14:43:01 +0100
From: [email-masked]
Organization: Alcatel Bell - IPO NA (Antwerpen)
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, "'Mak, L (Leen)'" <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>
Subject: Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status]

Bert,

i see many issues, the statement refers to "call" while from the 
ietf terminology, this term is referred to as "session"; as such
it could be appropriate from our side to review the statement
made in the "ITU liaison" because the proposed separation plugs 
a "telephony-oriented" model (or telephony-like model) to a data 
/circuit switched oriented network - but not with "64kb" - one 
speak here about connections from 51.84 Mb (more precisely the
payload of a C3 is 48384 kbps) to 2.5, 10 or even 40 Gbps ! 
This separation (adapted for public telephony network) is also 
constructed on an assumption that there is no control plane
protocol as we have today with GMPLS protocols but that connection 
signalling is performed by the transport plane (using embedded 
signalling) or through management plane. So there is an under-
lying fundamental question isn't the G.ASON model only a "public 
overlay model" and then we have to ask ourself if the scope of 
GMPLS has to be adapated/restricted to such public networks 
using an overlay control plane inter-connection: imho, clearly no
but what could be considered is a "GMPLS profile" for G.ASON.

Moreover this "assumption" resulted to the fact that G.ASON is
based on a fundamental assumption: no routing information exchange 
between the client and server layer. GMPLS does not have such 
stringent restriction. Consequently, this makes the separation
call/connection (while mandatory per requirement in the stringent 
G.ASON model) not at all mandatory in the IETF scope since the 
"routing exchanges" fulfill the role played by the call operation: 
the source knows the status and the availability of the set of
destinations it can reach. Since routing is one of the foundation 
of any data network, i think we should probably also discuss if 
this separation is adapted for other types of GMPLS networks. In
brief, i don't think we have to restrict the ubiquity of the GMPLS 
protocol suite.

Hope this clarifies,

regards,
- dimitri.

"Wijnen, Bert (Bert)" wrote:
> 
> Erik et all, the "official communications from the ITU" are
> listed under the Liaison Statements on the IETF Web Page.
> The page is at: http://www.ietf.org/IESG/liaison.html
> 
> If you see trouble/issues with any of those, pls let WG chairs and
> ADs know, so we can take action.
> 
> Bert

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

Delivery-date: Tue, 26 Feb 2002 05:36:48 -0800
From: Heiles Juergen <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: RE: Simple solution to terminate the discussion about SONET versu s SD H
Date: Tue, 26 Feb 2002 14:35:23 +0100

Eric,

tricky question.-)

I say YES (except for the VT-3 as already explained by Deborah)

and will face the complains.

Regards

Juergen

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 11:17 AM
> To: Stephen Trowbridge; 'Heiles Juergen'; [email-masked]'
> Cc: Wijnen, Bert (Bert); [email-masked]'; ccamp-wg; 
> [email-masked]';
> 'Kireeti Kompella'
> Subject: Simple solution to terminate the discussion about 
> SONET versus
> SD H
> Importance: High
> 
> 
> Dear All,
> 
> There is an easy way to stop definitively this discussion 
> based on technical
> facts:
> 
> Stephen, Juergen and Maarten, please tell us: today, are the frame
> structures and all the bytes in the SDH and SONET overhead completely
> identical, used and interpreted in the same way, is the 
> monitoring exactly
> the same ? In particular, if I provision and operate an SDH 
> circuit/LSP is
> this fully identical to a SONET circuit/LSP from *all* point 
> of views ?
> 
> PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not 
> needed at this
> stage.
> 
> If the answer is yes: SONET is totally identical to SDH.
> If the answer is no: SONET is not the same as SDH.
> 
> I think that without that answer we cannot take any 
> *technical* decision on
> this mailing list and at the IETF.
> 
> Thanks to answer. 
> 
> Kind regards,
> 
> Eric
> 
> ps: feel free to forward this e-mail to any ITU-T mailing list if a
> confirmation is needed.
> 

Delivery-date: Tue, 26 Feb 2002 04:40:20 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Mannie, Eric" <[email-masked]>, "'Mak, L (Leen)'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument statu s]
Date: Tue, 26 Feb 2002 13:39:54 +0100

Erik et all, the "official communications from the ITU" are
listed under the Liaison Statements on the IETF Web Page.
The page is at: http://www.ietf.org/IESG/liaison.html

If you see trouble/issues with any of those, pls let WG chairs and
ADs know, so we can take action.

Bert 

Delivery-date: Tue, 26 Feb 2002 04:40:16 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Mannie, Eric" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 13:39:55 +0100

If people want to express their support for this 4th option
then that is fine with me. WG chair(s) do you agree too
(don't want to step on your toes or sit in your chair).

Bert 

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 11:32 AM
> To: 'Wijnen, Bert (Bert)'; ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> Hello Bert and all,
> 
> One question is missing:
> 
> 4) Do you think we should have just a single set of traffic 
> parameters and
> label format (values) for both SDH and SONET.
> 
> In 1) "none for SONET" assumes that SONET doesn't exist 
> anymore. Note also
> that the traffic parameters are already identical, the only 
> difference is
> about the label. As editor of these drafts I would like at 
> least to see the
> right questions asked on the mailing list.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 10:37 AM
> To: ccamp-wg
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> CCAMP WG members, 
> 
> before we start down another many 100s of emails re-discussing
> the same topic....
> 
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
> 
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> > 
> > 1) Do you think we should have just a single set of traffic 
> parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> > 
> > (in the above, SHOULD and MUST are to be interpreted as in 
> RFC 2119.)
> > 
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Thanks
> Bert, speaking as AD who would like to see the WG take 
>       a decision on this topic.
> 

Delivery-date: Tue, 26 Feb 2002 04:38:14 -0800
From: "Osama Aboul-Magd"<[email-masked]>
To: Stephen Trowbridge <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: WG dcoument status
Date: Tue, 26 Feb 2002 07:37:00 -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_01C1BEC2.4951B930
Content-Type: text/plain;
	charset="iso-8859-1"

I am aware of the ITU communication statement. In response to it I submitted
"draft-aboulmagd-ccamp-call-conn-separation-00.txt" which shows a way for
achieving call and connection separation (as required by G.8080 and G.7713)
using CR-LDP. 

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: [email-masked]

 -----Original Message-----
From: 	Stephen Trowbridge [mailto:[email-masked]] 
Sent:	Monday, February 25, 2002 4:40 PM
To:	Kireeti Kompella
Cc:	[email-masked]
Subject:	Re: WG dcoument status

Kireeti,
Regarding the WG last call on the documents:
        draft-ietf-mpls-generalized-cr-ldp-05.txt
        draft-ietf-mpls-generalized-rsvp-te-06.txt
Please note that there is a communication statement from ITU-T Q.14/15
which can be found at: http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
which is relevant to these drafts. In particular, this statement gives
four examples of requirements from ITU-T Recommendations G.807/Y.1302,
G.8080/Y.1304 and G.7713/Y.1704 which are not met by the current versions
of the drafts.

I am aware that it may not be the goal of everyone that these drafts
meet all of these requirements in the first version. But I think it is
our long term goal that these protocols and the ITU-T requirements
converge to the same solution.

In light of the communication statement, can we have some discussion
about the way forward toward this goal? Some possible approaches are:
- It seems for the moment, WG last call has not completed on another
  of 4 drafts that are proposed to advance as a set. While we are
  working to resolve the issues with:
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt,
  is it possible to also address the requirements gaps in these other
  two drafts?
- If these two drafts are advanced as is to a proposed standard RFC, can
  the requirement gaps be addressed with one or more new documents which
  provide only additions, without obsoleting the original RFC?
- If not, I presume we look forward to some new documents on ASON compliant
  GMPLS which, when advanced, would obsolete the original RFCs.

Regards,
Steve

Kireeti Kompella wrote:
> 
> Here's a status update.
> 
> The signaling drafts:
>         draft-ietf-mpls-generalized-cr-ldp-05.txt
>         draft-ietf-mpls-generalized-rsvp-te-06.txt
>         draft-ietf-mpls-generalized-signaling-07.txt
>         draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> have finished WG Last Call, and will be sent on to IETF Last Call.
> They are on the track for Proposed Standard.
> 
> Bert Wijnen (AD) has suggested that there should be an implementation
> statement before these move on to IETF Last Call; the WG chairs and
> draft editors agreed.  One note: the SDH/SONET label issue must be put
> to rest before the SDH/SONET draft can move forward.  All other issues
> are now closed.
> 
> The LMP draft:
>         draft-ietf-ccamp-lmp-02.txt
> has gone through one round of WG Last Call comments and, once a
> new version has been produced incorporating these comments, will
> go through a final WG Last Call.  This is also targeted as a
> Proposed Standard.
> 
> The following draft, a companion to the above LMP document, is
> also targeted at Proposed Standard, and is still being worked on:
>         draft-ietf-ccamp-lmp-mib-00.txt
> 
> The routing drafts:
>         draft-ietf-ccamp-gmpls-routing-02.txt
>         draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
> are awaiting WG consensus for going into WG Last Call.  These
> are also targeted for Proposed Standard.  (Note that the ISIS
> draft is owned by the ISIS WG.)
> 
> The following drafts are Informational:
>         draft-ietf-ccamp-gmpls-architecture-01.txt
>         draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> They are awaiting final touches from the editor before they
> progress.
> 
> The following two documents are also being worked on:
>         draft-ietf-ccamp-oli-reqts-00.txt
>         draft-ietf-ccamp-lmp-wdm-00.txt
> The first is an Informational document; the second is aimed
> at Proposed Standard.
> 
> The MIBs are being reworked in response to comments from the AD.
> When the new versions are ready, the WG will then be asked for
> consensus to make them WG docs.
> 
> Kireeti.

------_=_NextPart_001_01C1BEC2.4951B930
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: WG dcoument status</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I am aware of the ITU communication statement. In =
response to it I submitted =
&quot;draft-aboulmagd-ccamp-call-conn-separation-00.txt&quot; which =
shows a way for achieving call and connection separation (as required =
by G.8080 and G.7713) using CR-LDP. </FONT></P>

<P><FONT SIZE=3D2>Regards;</FONT>
</P>

<P><FONT SIZE=3D2>Osama Aboul-Magd</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>P.O. Box 3511, Station &quot;C&quot;</FONT>
<BR><FONT SIZE=3D2>Ottawa, ON, Canada</FONT>
<BR><FONT SIZE=3D2>K1Y - 4H7</FONT>
<BR><FONT SIZE=3D2>Tel: 613-763-5827</FONT>
<BR><FONT SIZE=3D2>e.mail: [email-masked]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Stephen Trowbridge [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>] </FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Monday, February 25, 2002 4:40 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Kireeti Kompella</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Re: WG dcoument status</FONT>
</P>

<P><FONT SIZE=3D2>Kireeti,</FONT>
<BR><FONT SIZE=3D2>Regarding the WG last call on the documents:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-mpls-generalized-cr-ldp-05.txt</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-mpls-generalized-rsvp-te-06.txt</FONT>
<BR><FONT SIZE=3D2>Please note that there is a communication statement =
from ITU-T Q.14/15</FONT>
<BR><FONT SIZE=3D2>which can be found at: <A =
HREF=3D"http://www.ietf.org/IESG/LIAISON/ITU-OIF.html" =
TARGET=3D"_blank">http://www.ietf.org/IESG/LIAISON/ITU-OIF.html</A></FON=
T>
<BR><FONT SIZE=3D2>which is relevant to these drafts. In particular, =
this statement gives</FONT>
<BR><FONT SIZE=3D2>four examples of requirements from ITU-T =
Recommendations G.807/Y.1302,</FONT>
<BR><FONT SIZE=3D2>G.8080/Y.1304 and G.7713/Y.1704 which are not met by =
the current versions</FONT>
<BR><FONT SIZE=3D2>of the drafts.</FONT>
</P>

<P><FONT SIZE=3D2>I am aware that it may not be the goal of everyone =
that these drafts</FONT>
<BR><FONT SIZE=3D2>meet all of these requirements in the first version. =
But I think it is</FONT>
<BR><FONT SIZE=3D2>our long term goal that these protocols and the =
ITU-T requirements</FONT>
<BR><FONT SIZE=3D2>converge to the same solution.</FONT>
</P>

<P><FONT SIZE=3D2>In light of the communication statement, can we have =
some discussion</FONT>
<BR><FONT SIZE=3D2>about the way forward toward this goal? Some =
possible approaches are:</FONT>
<BR><FONT SIZE=3D2>- It seems for the moment, WG last call has not =
completed on another</FONT>
<BR><FONT SIZE=3D2>&nbsp; of 4 drafts that are proposed to advance as a =
set. While we are</FONT>
<BR><FONT SIZE=3D2>&nbsp; working to resolve the issues with: =
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt,</FONT>
<BR><FONT SIZE=3D2>&nbsp; is it possible to also address the =
requirements gaps in these other</FONT>
<BR><FONT SIZE=3D2>&nbsp; two drafts?</FONT>
<BR><FONT SIZE=3D2>- If these two drafts are advanced as is to a =
proposed standard RFC, can</FONT>
<BR><FONT SIZE=3D2>&nbsp; the requirement gaps be addressed with one or =
more new documents which</FONT>
<BR><FONT SIZE=3D2>&nbsp; provide only additions, without obsoleting =
the original RFC?</FONT>
<BR><FONT SIZE=3D2>- If not, I presume we look forward to some new =
documents on ASON compliant</FONT>
<BR><FONT SIZE=3D2>&nbsp; GMPLS which, when advanced, would obsolete =
the original RFCs.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Steve</FONT>
</P>

<P><FONT SIZE=3D2>Kireeti Kompella wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Here's a status update.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The signaling drafts:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-mpls-generalized-cr-ldp-05.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-mpls-generalized-rsvp-te-06.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-mpls-generalized-signaling-07.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt</FONT>
<BR><FONT SIZE=3D2>&gt; have finished WG Last Call, and will be sent on =
to IETF Last Call.</FONT>
<BR><FONT SIZE=3D2>&gt; They are on the track for Proposed =
Standard.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Bert Wijnen (AD) has suggested that there =
should be an implementation</FONT>
<BR><FONT SIZE=3D2>&gt; statement before these move on to IETF Last =
Call; the WG chairs and</FONT>
<BR><FONT SIZE=3D2>&gt; draft editors agreed.&nbsp; One note: the =
SDH/SONET label issue must be put</FONT>
<BR><FONT SIZE=3D2>&gt; to rest before the SDH/SONET draft can move =
forward.&nbsp; All other issues</FONT>
<BR><FONT SIZE=3D2>&gt; are now closed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The LMP draft:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-ccamp-lmp-02.txt</FONT>
<BR><FONT SIZE=3D2>&gt; has gone through one round of WG Last Call =
comments and, once a</FONT>
<BR><FONT SIZE=3D2>&gt; new version has been produced incorporating =
these comments, will</FONT>
<BR><FONT SIZE=3D2>&gt; go through a final WG Last Call.&nbsp; This is =
also targeted as a</FONT>
<BR><FONT SIZE=3D2>&gt; Proposed Standard.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The following draft, a companion to the above =
LMP document, is</FONT>
<BR><FONT SIZE=3D2>&gt; also targeted at Proposed Standard, and is =
still being worked on:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-ccamp-lmp-mib-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The routing drafts:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-ccamp-gmpls-routing-02.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-ccamp-ospf-gmpls-extensions-04.txt</FONT>
<BR><FONT SIZE=3D2>&gt; are awaiting WG consensus for going into WG =
Last Call.&nbsp; These</FONT>
<BR><FONT SIZE=3D2>&gt; are also targeted for Proposed Standard.&nbsp; =
(Note that the ISIS</FONT>
<BR><FONT SIZE=3D2>&gt; draft is owned by the ISIS WG.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The following drafts are Informational:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-ccamp-gmpls-architecture-01.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; They are awaiting final touches from the editor =
before they</FONT>
<BR><FONT SIZE=3D2>&gt; progress.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The following two documents are also being =
worked on:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-ccamp-oli-reqts-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-ccamp-lmp-wdm-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; The first is an Informational document; the =
second is aimed</FONT>
<BR><FONT SIZE=3D2>&gt; at Proposed Standard.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The MIBs are being reworked in response to =
comments from the AD.</FONT>
<BR><FONT SIZE=3D2>&gt; When the new versions are ready, the WG will =
then be asked for</FONT>
<BR><FONT SIZE=3D2>&gt; consensus to make them WG docs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Kireeti.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BEC2.4951B930--

Delivery-date: Tue, 26 Feb 2002 04:02:57 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shiomoto-ccamp-multiarea-te-00.txt
Date: Tue, 26 Feb 2002 07:02:37 -0500

--NextPart

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

	Title		: Multi-area multi-layer traffic engineering using
                          hierarchical LSPs in GMPLS networks
	Author(s)	: K. Shiomoto et al.
	Filename	: draft-shiomoto-ccamp-multiarea-te-00.txt
	Pages		: 8
	Date		: 25-Feb-02
	
This draft proposes a multi-area multi-layer traffic engineering
method using hierarchical LSPs in GMPLS networks. Lower-layer LSPs
are set up between ABRs over the backbone area and higher-layer LSPs
are set up between LSRs over the lower-layer LSPs. The proposed
method is applied to optical backbone area. OSPF and BGP-4 are
extended to carry traffic demand from ingress area to egress area so
that each border node can compile the traffic demand matrix whose
(i,j)-element corresponds to the traffic demand from area-i to area-
j. Appropriate light path topology can be calculated using the
traffic demand matrix.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-shiomoto-ccamp-multiarea-te-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 26 Feb 2002 04:02:56 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-imajuku-ml-routing-00.txt
Date: Tue, 26 Feb 2002 07:02:42 -0500

--NextPart

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

	Title		: Multi-layer routing using multiple-layer switch 
                          capable LSRs
	Author(s)	: W. Imajuku et al.
	Filename	: draft-imajuku-ml-routing-00.txt
	Pages		: 9
	Date		: 25-Feb-02
	
The integration of multi-layer switching capabilities within one 
box, such as the packet-switch capability (PSC) and the lambda-
switch capability (LSC) under MPLS/Generalized-MPLS control mecanism,
paves the way for realizing the network resouce optimization 
with multi-layer routing consideration. This document clarifies 
the model of the GMPLS-controlled integrated PSC/LSC label switch 
router (LSR) and discuss the requirement of routing extensions 
which enable to realize the optimized multi-layer traffic 
engineering

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-imajuku-ml-routing-00.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-imajuku-ml-routing-00.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-imajuku-ml-routing-00.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-imajuku-ml-routing-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-imajuku-ml-routing-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 26 Feb 2002 04:02:54 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-papadimitriou-ccamp-lmp-initiation-00.txt
Date: Tue, 26 Feb 2002 07:02:28 -0500

--NextPart

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

	Title		: LSP Initiation using Link Management Protocol (LMP)
	Author(s)	: D. Papadimitriou, J. Jones
	Filename	: draft-papadimitriou-ccamp-lmp-initiation-00.txt
	Pages		: 18
	Date		: 25-Feb-02
	
This memo is a companion document to Link Management Protocol [LMP],
for which it details the LSP Initiation process when using. This
protocol is being developed as part of the GMPLS protocol suite to
control and manage traffic engineering (TE) links. The current
document extends the LMP capabilities to LSP enabling among other to
dynamically configure a TE-link (in particular the LSP it can serve)
between non-adjacent LSR.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-lmp-initiation-00.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-papadimitriou-ccamp-lmp-initiation-00.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-papadimitriou-ccamp-lmp-initiation-00.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-papadimitriou-ccamp-lmp-initiation-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-papadimitriou-ccamp-lmp-initiation-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 26 Feb 2002 03:52:49 -0800
Date: Tue, 26 Feb 2002 13:03:09 +0100
From: Marcus Brunner <[email-masked]>
Reply-To: [email-masked]
To: Kireeti Kompella <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Thomas D. Nadeau" <[email-masked]>, Cheenu Srinivasan <[email-masked]>, Joan Cucchiara <[email-masked]>, [email-masked], Vijay Gill <[email-masked]>, [email-masked]
Subject: RE: GMPLS MIB I-D updates

--On Tuesday, January 29, 2002 2:39 PM -0800 Kireeti Kompella 
<[email-masked]> wrote:

>
>
> On Sat, 26 Jan 2002, Wijnen, Bert (Bert) wrote:
>
>> >          I don't see the new MIBs as obsoleting the v1 MIBs.
>> > The existing MPLS MIBs will continue to be perfectly
>> > valid for existing implementations, as well as future ones that do not
>> > want to have anything to do with GMPLS.
>
> Speaking as an implementor, I would prefer that these MIBs *do*
> obsolete the v1 MIBs.  That doesn't mean that the v1 MIBs should
> be thrown away, just that (perhaps) they could be experimental instead
> of PS (repeat: the above comment is *not* as a WG chair).
>

I agree with Kireeti here. And what I have seen so far from the GMPLS MIBs 
there is really not much of a difference, and everything should still work 
for plain old MPLS anyway.

Marcus

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

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

Delivery-date: Tue, 26 Feb 2002 03:18:11 -0800
From: "Mannie, Eric" <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 12:17:31 +0100

(2) for me

Eric

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 10:37 AM
To: ccamp-wg
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

CCAMP WG members, 

before we start down another many 100s of emails re-discussing
the same topic....

PLEASE express your support for one of the 3 options that Kireeti
posed to the WG. Don't elaborate... just help the WG chair(s) to
figure out the (rough) consensus of the WG. The choices formulated
by Kireeti:

> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Thanks
Bert, speaking as AD who would like to see the WG take 
      a decision on this topic.

Delivery-date: Tue, 26 Feb 2002 03:11:01 -0800
From: "Mannie, Eric" <[email-masked]>
To: "'Mak, L (Leen)'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: WG dcoument status
Date: Tue, 26 Feb 2002 12:10:19 +0100

Mark,

E-mails exchanged by people on this mailing list are not formal
communications. In ITU-T, a formal communication has to be voted (i.e. not
only done by a few colleagues), in IETF this has to be agreed by the WG.

> BTW The special case is not for "ITU people" but for "ITU T Study 
Group, Working Party or Rapporteur".

I am sorry, but people speaking on this mailing list don't represent in any
way the ITU-T point of view, but their own *personal* point of view. Stephen
has no more rights than Dimitri or I have. We are also member of ITU-T, and
in that case we could also speak as ITU-T members. Once again the only ITU-T
point of view that we have to consider here is the one received through
liaison statements.

To stay politically correct (not say something else), each one should avoid
to use his/her membership to some organization to impose his/her own ideas.

Rgds,

Eric

-----Original Message-----
From: Mak, L (Leen) [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 11:44 AM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: WG dcoument status

Dimitri,

> 
> So "Why should we have "special cases" for ITU people, requirements
> or models, why aren't they proposing contributions as any other 
> IETFer does?"
> 

Para 3.2.4 of
http://www.ietf.org/internet-drafts/draft-fishman-2436bis-01.txt
says
"Formal communication is intended to allow the
   sharing of positions between the IETF and the ITU-T outside of actual
   documents (as described in 3.3). "

BTW The special case is not for "ITU people" but for "ITU T Study 
Group, Working Party or Rapporteur".

Leen Mak.

Delivery-date: Tue, 26 Feb 2002 03:02:53 -0800
Date: Tue, 26 Feb 2002 12:01:53 +0100
From: [email-masked]
Organization: Alcatel Bell - IPO NA (Antwerpen)
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: ccamp-wg <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Bert, all,

my preference goes toward alternative (2).

cheers,
- dimitri.

"Wijnen, Bert (Bert)" wrote:
> 
> CCAMP WG members,
> 
> before we start down another many 100s of emails re-discussing
> the same topic....
> 
> PLEASE express your support for one of the 3 options that Kireeti
> posed to the WG. Don't elaborate... just help the WG chair(s) to
> figure out the (rough) consensus of the WG. The choices formulated
> by Kireeti:
> 
> > So, here we are again, arguing over this.  Let's follow the AD's
> > suggestion and look for consensus in the WG.
> >
> > 1) Do you think we should have just a single set of traffic parameters
> >    and label values for SDH, and none for SONET?
> > or
> > 2) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one SHOULD
> >    use the SDH equivalent?
> > or
> > 3) Do you think we should have one for SONET and one for SDH, with
> >    the proviso that, if an SDH equivalent is available, one MUST
> >    use the SDH equivalent?
> >
> > (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> >
> > PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Thanks
> Bert, speaking as AD who would like to see the WG take
>       a decision on this topic.

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

Delivery-date: Tue, 26 Feb 2002 02:55:06 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Subject: draft-ietf-ccamp-lmp-02.txt
Date: Tue, 26 Feb 2002 11:54:32 +0100

>From Kireeti's "wg document status" email

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Monday, February 25, 2002 2:52 AM
> To: [email-masked]
> Subject: WG dcoument status
> 
> 
> Here's a status update.
> 
... snip ...

> The LMP draft:
> 	draft-ietf-ccamp-lmp-02.txt
> has gone through one round of WG Last Call comments and, once a
> new version has been produced incorporating these comments, will
> go through a final WG Last Call.  This is also targeted as a
> Proposed Standard.
> 
I will note that in my view, the security section will need
serious work. I doubt that the Security ADs will sign off on the
current text. The security section should address the risks
and treats. It should then specify how to protect against them.
A text like "LMP exchanges may be authenticated with MD5" (which
is basically what you write now) seems not sufficient to me.

Bert

Delivery-date: Tue, 26 Feb 2002 02:44:12 -0800
From: "Mak, L (Leen)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: WG dcoument status
Date: Tue, 26 Feb 2002 11:43:38 +0100

Dimitri,

> 
> So "Why should we have "special cases" for ITU people, requirements
> or models, why aren't they proposing contributions as any other 
> IETFer does?"
> 

Para 3.2.4 of
http://www.ietf.org/internet-drafts/draft-fishman-2436bis-01.txt
says
"Formal communication is intended to allow the
   sharing of positions between the IETF and the ITU-T outside of actual
   documents (as described in 3.3). "

BTW The special case is not for "ITU people" but for "ITU T Study 
Group, Working Party or Rapporteur".

Leen Mak.

Delivery-date: Tue, 26 Feb 2002 02:32:58 -0800
From: "Mannie, Eric" <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 11:32:20 +0100

Hello Bert and all,

One question is missing:

4) Do you think we should have just a single set of traffic parameters and
label format (values) for both SDH and SONET.

In 1) "none for SONET" assumes that SONET doesn't exist anymore. Note also
that the traffic parameters are already identical, the only difference is
about the label. As editor of these drafts I would like at least to see the
right questions asked on the mailing list.

Kind regards,

Eric

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 10:37 AM
To: ccamp-wg
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

CCAMP WG members, 

before we start down another many 100s of emails re-discussing
the same topic....

PLEASE express your support for one of the 3 options that Kireeti
posed to the WG. Don't elaborate... just help the WG chair(s) to
figure out the (rough) consensus of the WG. The choices formulated
by Kireeti:

> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Thanks
Bert, speaking as AD who would like to see the WG take 
      a decision on this topic.

Delivery-date: Tue, 26 Feb 2002 02:18:38 -0800
From: "Mannie, Eric" <[email-masked]>
To: Stephen Trowbridge <[email-masked]>, 'Heiles Juergen' <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, 'Kireeti Kompella' <[email-masked]>
Subject: Simple solution to terminate the discussion about SONET versus SD H
Date: Tue, 26 Feb 2002 11:17:02 +0100

Dear All,

There is an easy way to stop definitively this discussion based on technical
facts:

Stephen, Juergen and Maarten, please tell us: today, are the frame
structures and all the bytes in the SDH and SONET overhead completely
identical, used and interpreted in the same way, is the monitoring exactly
the same ? In particular, if I provision and operate an SDH circuit/LSP is
this fully identical to a SONET circuit/LSP from *all* point of views ?

PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not needed at this
stage.

If the answer is yes: SONET is totally identical to SDH.
If the answer is no: SONET is not the same as SDH.

I think that without that answer we cannot take any *technical* decision on
this mailing list and at the IETF.

Thanks to answer. 

Kind regards,

Eric

ps: feel free to forward this e-mail to any ITU-T mailing list if a
confirmation is needed.

Delivery-date: Tue, 26 Feb 2002 01:37:44 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 10:37:07 +0100

CCAMP WG members, 

before we start down another many 100s of emails re-discussing
the same topic....

PLEASE express your support for one of the 3 options that Kireeti
posed to the WG. Don't elaborate... just help the WG chair(s) to
figure out the (rough) consensus of the WG. The choices formulated
by Kireeti:

> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Thanks
Bert, speaking as AD who would like to see the WG take 
      a decision on this topic.

Delivery-date: Tue, 26 Feb 2002 01:19:59 -0800
From: Heiles Juergen <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: RE: SDH/SONET extensions
Date: Tue, 26 Feb 2002 10:19:30 +0100

Vote (b)

as some clarifications and alignment with the final draft-ietf-ccamp-gmpls-sonet-sdh-xx.txt is needed.
Work is going on for both documents.

Regards

Juergen

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Monday, February 25, 2002 5:22 PM
> To: [email-masked]
> Subject: SDH/SONET extensions
> 
> 
> The draft:
> 	draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> 
> specifies signaling for non-standard aspects of SONET and SDH.
> It is to be processed as an Informational RFC.
> 
> I seek WG opinion on
> (a) is this draft ready for publication?
> (b) is more work needed *for the topics in the draft* -- i.e.,
>     clarifications, corrections, etc., NOT new functionality?
> 
> BTW, these questions on consensus are among the most important
> contributions you can make to the WG, so your participation is
> not just encouraged, but vital.
> 
> Thanks,
> Kireeti.
> 
> 

Delivery-date: Tue, 26 Feb 2002 01:15:09 -0800
Date: Tue, 26 Feb 2002 01:13:14 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: CCAMP 53 agenga

Hi All,

It's agenda time.  Please send me your requests for time slots at
the CCAMP meeting, IETF 53 -- with the subject line of "CCAMP 53".

Please note that these time slots are NOT for presentations.  They
are for discussions -- issues, updates, controversies and resolutions.
To get a time slot, there must be an ID *in the ID repository* on
that subject that folks can read before listening to the discussion.

The only exceptions to the ID rule are: Steve Trowbridge, giving an
update on the ITU-IETF interaction; and the Protection Restoration
Design Team, introducing themselves and their work.

Those who have already asked for time slots, please resend your
requests with "CCAMP 53" in the subject line if you want to be sure
your request gets processed.  Also, include (just) the name of your
ID.

Thanks,
Kireeti.

Delivery-date: Tue, 26 Feb 2002 00:55:04 -0800
Date: Tue, 26 Feb 2002 00:54:51 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Stephen Trowbridge <[email-masked]>
cc: [email-masked]
Subject: Re: WG document status

Hi Steve,

On Mon, 25 Feb 2002, Stephen Trowbridge wrote:

> Regarding the WG last call on the documents:
>         draft-ietf-mpls-generalized-cr-ldp-05.txt
>         draft-ietf-mpls-generalized-rsvp-te-06.txt
> Please note that there is a communication statement from ITU-T Q.14/15
> which can be found at: http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
> which is relevant to these drafts. In particular, this statement gives
> four examples of requirements from ITU-T Recommendations G.807/Y.1302,
> G.8080/Y.1304 and G.7713/Y.1704 which are not met by the current versions
> of the drafts.

I had read the statement, but haven't had time to read G.7713.{1,2,3}.
In particular, I haven't read G.7713 (protocol neutral specification),
or the requirements document (or is that just G.7713?)  Is there a
complete list of the requirements that are not met by GMPLS?

> I am aware that it may not be the goal of everyone that these drafts
> meet all of these requirements in the first version. But I think it is
> our long term goal that these protocols and the ITU-T requirements
> converge to the same solution.

Agreed.  Can we meet you halfway? :-)  For example, can we comment
on some of the requirements?  Or are they sacrosanct?

> In light of the communication statement, can we have some discussion
> about the way forward toward this goal? Some possible approaches are:
> - It seems for the moment, WG last call has not completed on another
>   of 4 drafts that are proposed to advance as a set. While we are
>   working to resolve the issues with: draft-ietf-ccamp-gmpls-sonet-sdh-02.txt,
>   is it possible to also address the requirements gaps in these other
>   two drafts?

I'm hoping that the issues with the sonet-sdh draft will be resolved
over the next two-three weeks.  At that point, the set will be ready
for IETF Last Call.

> - If these two drafts are advanced as is to a proposed standard RFC, can
>   the requirement gaps be addressed with one or more new documents which
>   provide only additions, without obsoleting the original RFC?

As far as the given examples go, additions seem sufficient to satisfy
the requirements.  If it turns out that some aspects need to be
reworked, this won't be the first time that RFCs have been superseded
by newer versions.

Kireeti.

Delivery-date: Tue, 26 Feb 2002 00:50:56 -0800
From: Sasha Vainshtein <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Tue, 26 Feb 2002 10:44:38 +0200

Hi Kireeti,
My two cents  is (1).

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Monday, February 25, 2002 2:11 AM
> To: Wijnen, Bert (Bert)
> Cc: Mannie, Eric; [email-masked]'; [email-masked]'; 
> ccamp-wg; [email-masked]'
> Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
> 
> 
> 
> 
> On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:
> 
> > Guys... I have seen to much of this. I have asked Kireeti
> > EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> > WG mailing list. I do NOT want another 500 emails going back
> > and forth on this issue. We need to approach this pragmatically.
> > 
> > - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the 
> >   WG mailing list on what exactly we agreed in SLC. That will
> >   help to prepare a response to ITU-T as well
> 
> First off, I should apologize for letting this go on unchecked.
> 
> Second, I should make it known to the WG as a whole that there was
> a discussion of this issue at SLC among several folks directly
> involved, the ADs and the chairs.  I thought we had achieved
> consensus, but now it seems not.
> 
> Here's what I thought we had agreed:
> 
> 1) There is a document in the ITU that defines a *single* 
> standard that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the 
> only such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET
>    that do not match the ITU document.
> 
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
> 
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
> 
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
> 
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
> 
> Thanks,
> Kireeti.
> 
> 

Delivery-date: Mon, 25 Feb 2002 23:58:15 -0800
Date: Mon, 25 Feb 2002 23:54:30 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Stephen Trowbridge <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Hi Steve,

On Mon, 25 Feb 2002, Stephen Trowbridge wrote:

> I start with the simple answer and follow with the diatribe - those
> who don't want to read the diatribe can stop after the answer:
> My answer: (1)

Noted.  For you, I'll make an exception and read the diatribe :-)

> Background: I clarified this in an email to you and the list last Dec. 18.
> I am surprised and disappointed that you did not take note of the
> answer.

Sorry!  I did read that, but was confused by a more recent exchange
between Maarten and Eric (irrelevant to this discussion).

> > Deborah Brungard wrote:
> > > The VT3 (3M) structure was defined - but no services (mappings) were ever defined for it. So there are no services/equip
> > > with it. My take was if in the future it was ever defined (doubtful), we would be adding it to g707 also. So then it
> > > would just be part of g707 too.

So, one issue is put to rest: there is no need to define separate
signalling for SONET signals on the basis that SDH doesn't fully
include SONET, as there are no (useful) non-SDH signals.

(An aside, for my own edification: are the overhead bytes for SDH and
SONET defined identically?  Or are they not defined sufficiently for
this to be an issue?)

> To do other than (1) introduces the case that there are two standardized
> codings for the same multiplex structure based on whether one thinks it
> is SONET or SDH. The result is that you are not interoperable in the
> control plane for something that IS interoperable in the transport plane.
> This is NOT the objective of standards.

I agree with you that to do other than (1) introduces 'confusion'.
However, the control plane is *software*.  It is relatively easy to
ensure interoperability in the control plane -- be prepared to
accept both mappings.  It is not so easy to dismiss hardware.

> Further, I am opposed to keeping pre-standard codings in a standards
> track document just because someone has built to the draft. Every
> ID includes the statement: "It is inappropriate to use Internet- Drafts
> as reference material or to cite them other than as "work in progress.""
> Certainly we all do early implementations, but any implementation done
> against an ID must ALWAYS be done with the understanding that this is
> subject to change, and may need revision once the ID is advanced to a
> proposed standard.

I can't fault you here.  This is why I agree with Bert that we leave
this to the WG at large.  If the sense of the WG is that having two
encodings for the same signal is bad (for whatever reason), we'll
have just one.  If the WG thinks that having dual encodings is more
pragmatic with respect to existing hardware, we'll have two.

If there isn't consensus in either direction, we'll go with one
encoding -- that's the right thing to do in principle.

Kireeti.

Delivery-date: Mon, 25 Feb 2002 17:34:17 -0800
From: "Bernstein, Greg" <[email-masked]>
To: Don Fedyk <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Routing drafts
Date: Mon, 25 Feb 2002 17:31:35 -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_001_01C1BE65.54595700
Content-Type: text/plain

Actually floating point is overkill for TDM.  We'd like to use small
integers to describe and update them more frequently.  The TDM multiplexing
is straight forward but unforgiving. We had this same discussion when we
decided to breakout the labels for SONET/SDH GMPLS signaling.  I want to
know that I've got 14 STS-1 of capacity, XX unused VT1.5, etc...  For those
SONET/SDH systems that have to deal with timeslot inflexibility (i.e.,
fragementations issues) more complete information on time slot usage is
advantageous.  For example with rings that don't have Time Slot Interchange,
a map of the timeslots could be helpful.  Eric and I had a bunch of stuff
about this in our earlier routing drafts.
 
Greg B.
 
----------------------------------------------------------------------------
----------
Dr. Greg M. Bernstein, Sr. Director Technology, Ciena Corp.
 
-----Original Message-----
From: Don Fedyk [mailto:[email-masked]] 
Sent: Monday, February 25, 2002 4:07 PM
To: Bernstein, Greg; Kireeti Kompella; [email-masked]
Subject: RE: Routing drafts
 
Greg you wrote: 
> (b) Big issue -- The parameters for representing bandwidth on 
> a link are not 
> very appropriate for TDM signals or WDM signals.  I've 
> included below some 
> more explanation taken from the IPO working group draft. 
> However, this is 
> the same thing that led to us breaking out the traffic 
> descriptor stuff in 
> GMPLS signaling for the SONET/SDH case.  This is really 
> needed here too. 
> 
These bandwidths in our draft are exact floating point numbers. 
Are you saying that the resolution of the floating point is an issue 
with optical? Or are you implying that bandwidths are percentages ? 
The text below is implying that statistical multiplexing can use 
inexact bandwidth but optical can (and should) use exact bandwidths. 
I did not see problems with the floating point range or our draft. 
Don 
 
> (From IPO working group draft on Inter-domain optical routing) 
> 2.3   Differences between MPLS and Optical Circuit routing 
> 
> The bandwidth accounting needed in optical circuit-switched 
> networks is also 
> different than in packet networks. In packet networks using 
> either ATM QoS 
> or MPLS-TE, complex statistical measures are used to 
> characterize the load 
> on a link, often with varying degrees of accuracy.  The 
> inexactness of such 
> measures and the "compressibility" of statistically 
> multiplexed traffic 
> imply that a small percentage change in link utilization can 
> usually be 
> absorbed by the network. 
> 
> By contrast, if an OC-192 link has just one STS-1 path 
> occupied (less than 
> 1% of the link bandwidth), it cannot accommodate an STS-192c 
> path. Due to 
> the relatively simple finite multiplex structures currently 
> use in optical 
> networks tracking bandwidth resources is much easier than 
> packet switched 
> networks, however much stricter bandwidth accounting is 
> required on circuit 
> switched links. In particular, it is expected that an 
> individual optical 
> circuit switched link can be fully utilized, while due to 
> queuing effects a 
> packet switched link on average can never be run at full 
> capacity and is 
> typically run at less then 80% of capacity.  
>   
> Greg B. 
> 
> 
> 

------_=_NextPart_001_01C1BE65.54595700
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<title>RE: Routing drafts</title>
<!--[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:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-alt:"Device Font 10cpi";
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@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;}
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 link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Actually floating point is =
overkill for
TDM.<span style=3D'mso-spacerun:yes'>&nbsp; </span>We'd like to use =
small
integers to describe and update them more frequently.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>The TDM multiplexing is =
straight forward
but unforgiving. We had this same discussion when we decided to =
breakout the
labels for SONET/SDH GMPLS signaling.<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>I want to know that I've got 14 STS-1 of capacity, XX unused
VT1.5, etc...<span style=3D'mso-spacerun:yes'>&nbsp; </span>For those
SONET/SDH systems that have to deal with timeslot inflexibility (i.e., =
<span
class=3DSpellE>fragementations</span> issues) more complete information =
on time
slot usage is advantageous.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>For
example with rings that don't have Time Slot Interchange, a map of the
timeslots could be helpful.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>Eric
and I had a bunch of stuff about this in our earlier routing =
drafts.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Greg =
B.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>-----------------------------------=
---------------------------------------------------<o:p></o:p></span></f=
ont></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Dr. Greg M. Bernstein, Sr. =
Director
Technology, Ciena Corp.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Don Fedyk
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, February =
25, 2002
4:07 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Bernstein, Greg; =
Kireeti
Kompella; [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Routing =
drafts</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Greg you wrote:</span></font> =
<o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt; (b) Big issue -- The parameters for =
representing
bandwidth on </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; a link are =
not</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; very appropriate =
for TDM
signals or WDM signals.&nbsp; I've </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; included below =
some</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; more explanation =
taken from
the IPO working group draft. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; However, this =
is</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the same thing =
that led to us
breaking out the traffic </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; descriptor stuff =
in</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; GMPLS signaling =
for the
SONET/SDH case.&nbsp; This is really </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; needed here =
too.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>These bandwidths in our =
draft are
exact floating point numbers. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>Are you saying that the =
resolution
of the floating point is an issue </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>with optical? Or are =
you implying
that bandwidths are percentages ?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>The text below is =
implying that
statistical multiplexing can use </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>inexact bandwidth but =
optical can
(and should) use exact bandwidths. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>I did not see problems =
with the
floating point range or our draft. </span></font><o:p></o:p></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Don </span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt; (From IPO working group draft on =
Inter-domain
optical routing)</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 2.3&nbsp;&nbsp; =
Differences
between MPLS and Optical Circuit routing</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; The bandwidth =
accounting needed
in optical circuit-switched </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; networks is =
also</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; different than in =
packet
networks. In packet networks using </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; either ATM =
QoS</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; or MPLS-TE, =
complex
statistical measures are used to </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; characterize the =
load</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; on a link, often =
with varying
degrees of accuracy.&nbsp; The </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; inexactness of =
such</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; measures and the
&quot;compressibility&quot; of statistically </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; multiplexed =
traffic</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; imply that a small =
percentage
change in link utilization can </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; usually =
be</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; absorbed by the =
network. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; By contrast, if an =
OC-192 link
has just one STS-1 path </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; occupied (less =
than</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 1% of the link =
bandwidth), it
cannot accommodate an STS-192c </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; path. Due =
to</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the relatively =
simple finite
multiplex structures currently </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; use in =
optical</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; networks tracking =
bandwidth
resources is much easier than </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; packet =
switched</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; networks, however =
much
stricter bandwidth accounting is </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; required on =
circuit</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; switched links. In =
particular,
it is expected that an </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; individual =
optical</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; circuit switched =
link can be
fully utilized, while due to </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; queuing effects =
a</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; packet switched =
link on
average can never be run at full </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; capacity and =
is</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; typically run at =
less then 80%
of capacity.&nbsp; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp; =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Greg =
B.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
</span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1BE65.54595700--

Delivery-date: Mon, 25 Feb 2002 16:07:42 -0800
From: "Don Fedyk"<[email-masked]>
To: "Bernstein, Greg" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Routing drafts
Date: Mon, 25 Feb 2002 19:07:06 -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_01C1BE59.86DC8410
Content-Type: text/plain;
	charset="iso-8859-1"

Greg you wrote:

> (b) Big issue -- The parameters for representing bandwidth on 
> a link are not
> very appropriate for TDM signals or WDM signals.  I've 
> included below some
> more explanation taken from the IPO working group draft. 
> However, this is
> the same thing that led to us breaking out the traffic 
> descriptor stuff in
> GMPLS signaling for the SONET/SDH case.  This is really 
> needed here too.
> 
These bandwidths in our draft are exact floating point numbers. 
Are you saying that the resolution of the floating point is an issue 
with optical? Or are you implying that bandwidths are percentages ?
The text below is implying that statistical multiplexing can use 
inexact bandwidth but optical can (and should) use exact bandwidths. 
I did not see problems with the floating point range or our draft. 

Don 

> (From IPO working group draft on Inter-domain optical routing)
> 2.3	Differences between MPLS and Optical Circuit routing
> 
> The bandwidth accounting needed in optical circuit-switched 
> networks is also
> different than in packet networks. In packet networks using 
> either ATM QoS
> or MPLS-TE, complex statistical measures are used to 
> characterize the load
> on a link, often with varying degrees of accuracy.  The 
> inexactness of such
> measures and the "compressibility" of statistically 
> multiplexed traffic
> imply that a small percentage change in link utilization can 
> usually be
> absorbed by the network. 
> 
> By contrast, if an OC-192 link has just one STS-1 path 
> occupied (less than
> 1% of the link bandwidth), it cannot accommodate an STS-192c 
> path. Due to
> the relatively simple finite multiplex structures currently 
> use in optical
> networks tracking bandwidth resources is much easier than 
> packet switched
> networks, however much stricter bandwidth accounting is 
> required on circuit
> switched links. In particular, it is expected that an 
> individual optical
> circuit switched link can be fully utilized, while due to 
> queuing effects a
> packet switched link on average can never be run at full 
> capacity and is
> typically run at less then 80% of capacity.  
>   
> Greg B.
> 
> 
> 

------_=_NextPart_001_01C1BE59.86DC8410
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: Routing drafts</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Greg you wrote:</FONT>
</P>

<P><FONT SIZE=2>&gt; (b) Big issue -- The parameters for representing bandwidth on </FONT>
<BR><FONT SIZE=2>&gt; a link are not</FONT>
<BR><FONT SIZE=2>&gt; very appropriate for TDM signals or WDM signals.&nbsp; I've </FONT>
<BR><FONT SIZE=2>&gt; included below some</FONT>
<BR><FONT SIZE=2>&gt; more explanation taken from the IPO working group draft. </FONT>
<BR><FONT SIZE=2>&gt; However, this is</FONT>
<BR><FONT SIZE=2>&gt; the same thing that led to us breaking out the traffic </FONT>
<BR><FONT SIZE=2>&gt; descriptor stuff in</FONT>
<BR><FONT SIZE=2>&gt; GMPLS signaling for the SONET/SDH case.&nbsp; This is really </FONT>
<BR><FONT SIZE=2>&gt; needed here too.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>These bandwidths in our draft are exact floating point numbers. </FONT>
<BR><FONT SIZE=2>Are you saying that the resolution of the floating point is an issue </FONT>
<BR><FONT SIZE=2>with optical? Or are you implying that bandwidths are percentages ?</FONT>
<BR><FONT SIZE=2>The text below is implying that statistical multiplexing can use </FONT>
<BR><FONT SIZE=2>inexact bandwidth but optical can (and should) use exact bandwidths. </FONT>
<BR><FONT SIZE=2>I did not see problems with the floating point range or our draft. </FONT>
</P>

<P><FONT SIZE=2>Don </FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; (From IPO working group draft on Inter-domain optical routing)</FONT>
<BR><FONT SIZE=2>&gt; 2.3&nbsp;&nbsp; Differences between MPLS and Optical Circuit routing</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The bandwidth accounting needed in optical circuit-switched </FONT>
<BR><FONT SIZE=2>&gt; networks is also</FONT>
<BR><FONT SIZE=2>&gt; different than in packet networks. In packet networks using </FONT>
<BR><FONT SIZE=2>&gt; either ATM QoS</FONT>
<BR><FONT SIZE=2>&gt; or MPLS-TE, complex statistical measures are used to </FONT>
<BR><FONT SIZE=2>&gt; characterize the load</FONT>
<BR><FONT SIZE=2>&gt; on a link, often with varying degrees of accuracy.&nbsp; The </FONT>
<BR><FONT SIZE=2>&gt; inexactness of such</FONT>
<BR><FONT SIZE=2>&gt; measures and the &quot;compressibility&quot; of statistically </FONT>
<BR><FONT SIZE=2>&gt; multiplexed traffic</FONT>
<BR><FONT SIZE=2>&gt; imply that a small percentage change in link utilization can </FONT>
<BR><FONT SIZE=2>&gt; usually be</FONT>
<BR><FONT SIZE=2>&gt; absorbed by the network. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; By contrast, if an OC-192 link has just one STS-1 path </FONT>
<BR><FONT SIZE=2>&gt; occupied (less than</FONT>
<BR><FONT SIZE=2>&gt; 1% of the link bandwidth), it cannot accommodate an STS-192c </FONT>
<BR><FONT SIZE=2>&gt; path. Due to</FONT>
<BR><FONT SIZE=2>&gt; the relatively simple finite multiplex structures currently </FONT>
<BR><FONT SIZE=2>&gt; use in optical</FONT>
<BR><FONT SIZE=2>&gt; networks tracking bandwidth resources is much easier than </FONT>
<BR><FONT SIZE=2>&gt; packet switched</FONT>
<BR><FONT SIZE=2>&gt; networks, however much stricter bandwidth accounting is </FONT>
<BR><FONT SIZE=2>&gt; required on circuit</FONT>
<BR><FONT SIZE=2>&gt; switched links. In particular, it is expected that an </FONT>
<BR><FONT SIZE=2>&gt; individual optical</FONT>
<BR><FONT SIZE=2>&gt; circuit switched link can be fully utilized, while due to </FONT>
<BR><FONT SIZE=2>&gt; queuing effects a</FONT>
<BR><FONT SIZE=2>&gt; packet switched link on average can never be run at full </FONT>
<BR><FONT SIZE=2>&gt; capacity and is</FONT>
<BR><FONT SIZE=2>&gt; typically run at less then 80% of capacity.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Greg B.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BE59.86DC8410--

Delivery-date: Mon, 25 Feb 2002 15:45:16 -0800
Date: Tue, 26 Feb 2002 00:44:04 +0100
From: [email-masked]
Organization: Alcatel Bell - IPO NA (Antwerpen)
To: Stephen Trowbridge <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: WG dcoument status

Stephen,

IMHO, your e-mail raises two issues 1) Procedural 2) Technical

Procedural:

The first question to ask yourself is "WHY does the CCAMP community 
has to consider this abstract control plane model as a "de facto" 
architecture that has to be integrated into GMPLS?"

So "Why should we have "special cases" for ITU people, requirements
or models, why aren't they proposing contributions as any other 
IETFer does?"

Technical:

AFAIK, G.ASON is based on a fundamental assumption: no routing 
information exchange between the client and server layer. GMPLS 
does not have such stringent restriction. Consequently, this makes 
the call/connection separation (while mandatory per requirement in 
the stringent G.ASON model) not at all necessary in the IETF scope 
since the "routing exchange" fulfills the role played by the call 
operation. Moreover since you ask for clear separation, any impact 
on the "connection" part (ie the referenced WG docs) is precluded  
by your own definition. So no impact on "existing" WG docs by adding 
your optional processing for call purposes i.e. there shouldn't be 
any backward compatibility issue with these WG docs.

Also in light with your "liaison" document: the restart capability 
issues have been addressed on this mailing list - at least 3 times - 
The conclusion (let's refresh people mind) was that what you are 
additionally asking here is more than clearly (i would say luminous)
outside of the scope of a "standard" since strictly related to an 
internal system processing, implying that just rough guidelines have 
to be added (but nothing more). No backward compatibility issue here. 
Btw, CCAMP should probably sent as liaison a summary of the mailing 
list discussions to the ITU SG15. This would help to achieve faster
results.

Considering that "crankback" is a broader scope than just the abstract
G.ASON model, i don't think we have to worry too much about your 
announced obsolescence of GMPLS I-Ds ;-)

Conclusion: 

GMPLS scope being much more larger than ITU-T G.ASON overlay model, 
while optional G.ASON related addition MUST NOT impact the existing 
content of the WG documents, i strongly suggest to consider here 
your SECOND option only as we did by the way for OIF extensions. 
This makes your optional extensions still feasible while keeping 
the existing document ongoing... and so the original document won't 
be obsolete AT ALL (as they will never be btw). More important from
an IETF perspective, i don't see any valuable reason to delay the 
two documents under discussion here (or at least not due to this 
liaison statement).

PS: 

when you say
"I am aware that it may not be the goal of everyone that these drafts
meet all of these requirements in the first version. But I think it is
our long term goal that these protocols and the ITU-T requirements
converge to the same solution."

You should probably rephrase it as "I am aware that it may not be the 
goal of everyone that these drafts meet all of these requirements in 
the first version. But I think it is MY (AS INDIVIDUAL ???) long term 
goal that these protocols and the ITU-T requirements converge to the 
same solution." 

When will you understand that NOBODY anymore knows who speaks: Steve
Trowbridge (as individual), ITU-T SG15 Vice Chair (as representative), 
"Sub-IP directorate" delegate ???

So thanks to sign your e-mails with the appropriate "name".
- dimitri.

Stephen Trowbridge wrote:
> 
> Kireeti,
> Regarding the WG last call on the documents:
>         draft-ietf-mpls-generalized-cr-ldp-05.txt
>         draft-ietf-mpls-generalized-rsvp-te-06.txt
> Please note that there is a communication statement from ITU-T Q.14/15
> which can be found at: http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
> which is relevant to these drafts. In particular, this statement gives
> four examples of requirements from ITU-T Recommendations G.807/Y.1302,
> G.8080/Y.1304 and G.7713/Y.1704 which are not met by the current versions
> of the drafts.
> 
> I am aware that it may not be the goal of everyone that these drafts
> meet all of these requirements in the first version. But I think it is
> our long term goal that these protocols and the ITU-T requirements
> converge to the same solution.
> 
> In light of the communication statement, can we have some discussion
> about the way forward toward this goal? Some possible approaches are:
> - It seems for the moment, WG last call has not completed on another
>   of 4 drafts that are proposed to advance as a set. While we are
>   working to resolve the issues with: draft-ietf-ccamp-gmpls-sonet-sdh-02.txt,
>   is it possible to also address the requirements gaps in these other
>   two drafts?
> - If these two drafts are advanced as is to a proposed standard RFC, can
>   the requirement gaps be addressed with one or more new documents which
>   provide only additions, without obsoleting the original RFC?
> - If not, I presume we look forward to some new documents on ASON compliant
>   GMPLS which, when advanced, would obsolete the original RFCs.
> 
> Regards,
> Steve
> 
> Kireeti Kompella wrote:
> >
> > Here's a status update.
> >
> > The signaling drafts:
> >         draft-ietf-mpls-generalized-cr-ldp-05.txt
> >         draft-ietf-mpls-generalized-rsvp-te-06.txt
> >         draft-ietf-mpls-generalized-signaling-07.txt
> >         draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > have finished WG Last Call, and will be sent on to IETF Last Call.
> > They are on the track for Proposed Standard.
> >
> > Bert Wijnen (AD) has suggested that there should be an implementation
> > statement before these move on to IETF Last Call; the WG chairs and
> > draft editors agreed.  One note: the SDH/SONET label issue must be put
> > to rest before the SDH/SONET draft can move forward.  All other issues
> > are now closed.
> >
> > The LMP draft:
> >         draft-ietf-ccamp-lmp-02.txt
> > has gone through one round of WG Last Call comments and, once a
> > new version has been produced incorporating these comments, will
> > go through a final WG Last Call.  This is also targeted as a
> > Proposed Standard.
> >
> > The following draft, a companion to the above LMP document, is
> > also targeted at Proposed Standard, and is still being worked on:
> >         draft-ietf-ccamp-lmp-mib-00.txt
> >
> > The routing drafts:
> >         draft-ietf-ccamp-gmpls-routing-02.txt
> >         draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
> > are awaiting WG consensus for going into WG Last Call.  These
> > are also targeted for Proposed Standard.  (Note that the ISIS
> > draft is owned by the ISIS WG.)
> >
> > The following drafts are Informational:
> >         draft-ietf-ccamp-gmpls-architecture-01.txt
> >         draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > They are awaiting final touches from the editor before they
> > progress.
> >
> > The following two documents are also being worked on:
> >         draft-ietf-ccamp-oli-reqts-00.txt
> >         draft-ietf-ccamp-lmp-wdm-00.txt
> > The first is an Informational document; the second is aimed
> > at Proposed Standard.
> >
> > The MIBs are being reworked in response to comments from the AD.
> > When the new versions are ready, the WG will then be asked for
> > consensus to make them WG docs.
> >
> > Kireeti.

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

Delivery-date: Mon, 25 Feb 2002 15:40:29 -0800
content-class: urn:content-classes:message
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Mon, 25 Feb 2002 18:39:39 -0500
From: "Brungard, Deborah A, ALASO" <[email-masked]>
To: "Mannie, Eric" <[email-masked]>, "Stephen Trowbridge" <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>, <[email-masked]>, "ccamp-wg" <[email-masked]>, <[email-masked]>

Hi Kireeti,

My answer is (1).

A reminder - this outcome also impacts gen-signaling draft where the sdh =
and sonet labels are defined. I think it would help with a lot of the =
misunderstanding if choice (1) was clarified to say ITU-T SDH. We are =
not discussing ETSI SDH, as was used for the comparison in the Framework =
for GMPLS control draft. Which is my take for choosing (1).

And one other reminder - my comment on the pdh labels always got lost in =
the sdh-sonet mail explosion. I would like a response. My comment was =
simply to say that if one has different labels for ANSI PDH and ETSI =
PDH, we will need another label for ITU-T PDH. Or we could simply have =
one label, ITU-T PDH, as it includes both sets and does not require a =
third label plus a gateway function.

The remaining part of this mail contains a response to Eric's mail =
below:

Hi Eric-
My understanding was that the labels were an indication of structure. In =
all the gmpls documents, the label indicates switching structure. On =
structure, the ITU-T is a superset of ANSI SONET-specific, ETSI =
SDH-specific, and an overlapping set of common structures. Are you =
saying there are interoperability problems with the structures of the =
overlapping set? As ITU-T G.707 and ANSI T1.105 are identical for the =
overlapping set, are these problems with non-standard equipment? =
Wouldn't these be in the draft on non-standard aspects?

As all the gmpls documents have referred to the label as indicating =
structure, I think it will mis-represent if we now try to say they also =
provide other interworking functions e.g. monitoring. We know the use of =
two labels for sdh and sonet will not provide interoperability of byte =
use (e.g. monitoring). As you also are aware of the many variations, I'm =
sure you agree with me - we can only wish it was so simple.

The OIF UNI was another incompatibility cited with using the ITU-T SDH =
labels instead of distinct SDH and SONET labels. The OIF UNI is a UNI. =
It is not a network interface (internal or between networks). The UNI =
only addresses the link connection to the network (which in the =
framework for control draft is referred to as a virtual label, only =
addressing the local link). The requirements of a network - especially =
global network(s) - are very different. I would hope we are not =
pre-locked into an implementation which has a very different defined =
scope. Otherwise why are we having this discussion?

Deborah

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Monday, February 25, 2002 2:54 PM
To: 'Stephen Trowbridge'; Kireeti Kompella
Cc: Wijnen, Bert (Bert); [email-masked]'; [email-masked]';
ccamp-wg; [email-masked]'
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

Hello Stephen,

It is not because two things are not totally the same that they cannot
interoperate:

- there is one unique way to request an SDH signal.
- there is one unique way to request a SONET signal.
- the two are interoperable while keeping the distinction.

You are claiming that SONET is totally a subset of SDH from all point of
views. In that case why do you care of SONET ? Let's completely forget =
SONET
and let's use only SDH. Is this correct ? Could you clarify the =
distinction
between SONET and SDH for the monitoring, etc ?

Implementations of SONET and SDH are not identical today and they will =
stay
different for a while. We need a solution that takes this into
consideration. The current GMPLS draft takes into consideration the two
point of views:

a. SONET is totally included in SDH: great ! Just request an SDH signal. =
It
works and there is no issue.
b. one still has a SONET version which is not fully in SDH: just request =
a
SONET signal if not able to request an SDH signal.

Why do you want absolutely to make case b impossible ?

If we give you a solution that does what you want to do, plus in =
addition
what some other people want to do, why are you complaining ???? I don't
understand that you cannot accept other point of views if there are not
preventing you to do what you want.

Kind regards,

Eric

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Monday, February 25, 2002 7:52 PM
To: Kireeti Kompella
Cc: Wijnen, Bert (Bert); Mannie, Eric; [email-masked]';
[email-masked]'; ccamp-wg; [email-masked]'
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Kireeti:
I start with the simple answer and follow with the diatribe - those
who don't want to read the diatribe can stop after the answer:
My answer: (1)

Background: I clarified this in an email to you and the list last Dec. =
18.
I am surprised and disappointed that you did not take note of the
answer. There are not a few signals in SONET which are not in SDH.
There is ONE, and it is one with no defined mappings. It is VT3, NOT
VC-3. I repeat my earlier email since you seem to have missed it
the first time. You even asked that someone should correct you if
you were wrong. Please read also the additional remarks and conclusions
below the included email.
Steve Trowbridge wrote:
> Kireeti,
> The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> (T1X1.5 chair) on this one and I take the liberty of sharing her =
response:
>=20
> Deborah Brungard wrote:
> > The VT3 (3M) structure was defined - but no services (mappings) were
ever defined for it. So there are no services/equip
> > with it. My take was if in the future it was ever defined =
(doubtful), we
would be adding it to g707 also. So then it
> > would just be part of g707 too.
>=20
> So basically, there are no mappings or equipment functions for this =
rate,
> and as far as we know no network equipment or networks supporting it.
> Deborah suggests that if we were ever to define such mappings, that =
this
> would be proposed for addition to G.707 and hence be part of SDH.
>=20
> I think our agreement had been to use the SDH label for all signals =
that
> had the same multiplex structure in SONET and SDH. In Salt Lake City, =
we
thought
> that this was everything except VT3. Given that VT3 seems not to be a
"real"
> signal at this point and will likely be added to SDH if it ever =
becomes
> real, does our agreement then become that we use SDH labels for
everything?
>=20
> Regards,
> Steve
>=20
> Kireeti Kompella wrote:
> >=20
> > Hi Deborah,
> >=20
> > > I previously made the
> > > comments to merge the (1) SDH and SONET values as one value
> >=20
> > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > several issues, among them this one.  The upshot was that whenever
> > possible, the SDH label should be used, with the encoding type
> > set to SDH (i.e., G.707); however, there are signals that have
> > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > me!), so we will keep SONET labels and encoding types around
> > for that case and for legacy equipment.
> >=20
> > The revised SONET/SDH document will contain the exact wording.
> > I will also be sending a reply to the ITU communication stating
> > the agreement we came to.
> >=20
> > Kireeti.

To do other than (1) introduces the case that there are two standardized
codings for the same multiplex structure based on whether one thinks it
is SONET or SDH. The result is that you are not interoperable in the
control plane for something that IS interoperable in the transport =
plane.
This is NOT the objective of standards.

Further, I am opposed to keeping pre-standard codings in a standards
track document just because someone has built to the draft. Every
ID includes the statement: "It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in progress.""
Certainly we all do early implementations, but any implementation done
against an ID must ALWAYS be done with the understanding that this is
subject to change, and may need revision once the ID is advanced to a
proposed standard.
Regards,
Steve

Kireeti Kompella wrote:
snip
>=20
> Here's what I thought we had agreed:
>=20
> 1) There is a document in the ITU that defines a *single* standard =
that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the only =
such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET
>    that do not match the ITU document.
>=20
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
>=20
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
>=20
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
>=20
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
>=20
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
>=20
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
>=20
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
>=20
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
>=20
> Thanks,
> Kireeti.

Delivery-date: Mon, 25 Feb 2002 15:12:33 -0800
From: "Bernstein, Greg" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: Routing drafts
Date: Mon, 25 Feb 2002 15:11:08 -0800

Hi Kireeti and the CCAMP mailing list a couple of comments:

(1) On draft-ietf-ccamp-gmpls-routing-02.txt -- Section 6 is where all the
new material gets covered and is very important.  Can we pull the examples
of sections 6.4.9 and 6.4.10 into a separate section (i.e., section 7) since
they are quite lengthy and optional reading.  This draft contains the
important concepts of Link protection type, Link Mux capability and SRLGs
and should move forward.

(2) On  draft-ietf-ccamp-ospf-gmpls-extensions-04.txt:
(a) Why does Cisco get a set of reserved sub-TLVs? 32768-32772 - Reserved
for Cisco-specific extension.
(b) Big issue -- The parameters for representing bandwidth on a link are not
very appropriate for TDM signals or WDM signals.  I've included below some
more explanation taken from the IPO working group draft. However, this is
the same thing that led to us breaking out the traffic descriptor stuff in
GMPLS signaling for the SONET/SDH case.  This is really needed here too.

(From IPO working group draft on Inter-domain optical routing)
2.3	Differences between MPLS and Optical Circuit routing

The bandwidth accounting needed in optical circuit-switched networks is also
different than in packet networks. In packet networks using either ATM QoS
or MPLS-TE, complex statistical measures are used to characterize the load
on a link, often with varying degrees of accuracy.  The inexactness of such
measures and the "compressibility" of statistically multiplexed traffic
imply that a small percentage change in link utilization can usually be
absorbed by the network. 

By contrast, if an OC-192 link has just one STS-1 path occupied (less than
1% of the link bandwidth), it cannot accommodate an STS-192c path. Due to
the relatively simple finite multiplex structures currently use in optical
networks tracking bandwidth resources is much easier than packet switched
networks, however much stricter bandwidth accounting is required on circuit
switched links. In particular, it is expected that an individual optical
circuit switched link can be fully utilized, while due to queuing effects a
packet switched link on average can never be run at full capacity and is
typically run at less then 80% of capacity.  
  
Greg B.

----------------------------------------------------------
Dr. Greg M. Bernstein, Sr. Technology Director, Ciena Corp.        

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]] 
Sent: Sunday, February 24, 2002 4:55 PM
To: [email-masked]
Subject: Routing drafts

The two drafts:
draft-ietf-ccamp-gmpls-routing-02.txt
and
draft-ietf-ccamp-ospf-gmpls-extensions-04.txt

are, according to the authors, ready for WG Last Call.

I would like to judge WG consensus for this.

Thanks,
Kireeti.

Delivery-date: Mon, 25 Feb 2002 13:41:45 -0800
Date: Mon, 25 Feb 2002 14:40:07 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: WG dcoument status

Kireeti,
Regarding the WG last call on the documents:
        draft-ietf-mpls-generalized-cr-ldp-05.txt
        draft-ietf-mpls-generalized-rsvp-te-06.txt
Please note that there is a communication statement from ITU-T Q.14/15
which can be found at: http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
which is relevant to these drafts. In particular, this statement gives
four examples of requirements from ITU-T Recommendations G.807/Y.1302,
G.8080/Y.1304 and G.7713/Y.1704 which are not met by the current versions
of the drafts.

I am aware that it may not be the goal of everyone that these drafts
meet all of these requirements in the first version. But I think it is
our long term goal that these protocols and the ITU-T requirements
converge to the same solution.

In light of the communication statement, can we have some discussion
about the way forward toward this goal? Some possible approaches are:
- It seems for the moment, WG last call has not completed on another
  of 4 drafts that are proposed to advance as a set. While we are
  working to resolve the issues with: draft-ietf-ccamp-gmpls-sonet-sdh-02.txt,
  is it possible to also address the requirements gaps in these other
  two drafts?
- If these two drafts are advanced as is to a proposed standard RFC, can
  the requirement gaps be addressed with one or more new documents which
  provide only additions, without obsoleting the original RFC?
- If not, I presume we look forward to some new documents on ASON compliant
  GMPLS which, when advanced, would obsolete the original RFCs.

Regards,
Steve

Kireeti Kompella wrote:
> 
> Here's a status update.
> 
> The signaling drafts:
>         draft-ietf-mpls-generalized-cr-ldp-05.txt
>         draft-ietf-mpls-generalized-rsvp-te-06.txt
>         draft-ietf-mpls-generalized-signaling-07.txt
>         draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> have finished WG Last Call, and will be sent on to IETF Last Call.
> They are on the track for Proposed Standard.
> 
> Bert Wijnen (AD) has suggested that there should be an implementation
> statement before these move on to IETF Last Call; the WG chairs and
> draft editors agreed.  One note: the SDH/SONET label issue must be put
> to rest before the SDH/SONET draft can move forward.  All other issues
> are now closed.
> 
> The LMP draft:
>         draft-ietf-ccamp-lmp-02.txt
> has gone through one round of WG Last Call comments and, once a
> new version has been produced incorporating these comments, will
> go through a final WG Last Call.  This is also targeted as a
> Proposed Standard.
> 
> The following draft, a companion to the above LMP document, is
> also targeted at Proposed Standard, and is still being worked on:
>         draft-ietf-ccamp-lmp-mib-00.txt
> 
> The routing drafts:
>         draft-ietf-ccamp-gmpls-routing-02.txt
>         draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
> are awaiting WG consensus for going into WG Last Call.  These
> are also targeted for Proposed Standard.  (Note that the ISIS
> draft is owned by the ISIS WG.)
> 
> The following drafts are Informational:
>         draft-ietf-ccamp-gmpls-architecture-01.txt
>         draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> They are awaiting final touches from the editor before they
> progress.
> 
> The following two documents are also being worked on:
>         draft-ietf-ccamp-oli-reqts-00.txt
>         draft-ietf-ccamp-lmp-wdm-00.txt
> The first is an Informational document; the second is aimed
> at Proposed Standard.
> 
> The MIBs are being reworked in response to comments from the AD.
> When the new versions are ready, the WG will then be asked for
> consensus to make them WG docs.
> 
> Kireeti.

Delivery-date: Mon, 25 Feb 2002 11:56:24 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Mon, 25 Feb 2002 20:53:54 +0100

Hello Stephen,

It is not because two things are not totally the same that they cannot
interoperate:

- there is one unique way to request an SDH signal.
- there is one unique way to request a SONET signal.
- the two are interoperable while keeping the distinction.

You are claiming that SONET is totally a subset of SDH from all point of
views. In that case why do you care of SONET ? Let's completely forget SONET
and let's use only SDH. Is this correct ? Could you clarify the distinction
between SONET and SDH for the monitoring, etc ?

Implementations of SONET and SDH are not identical today and they will stay
different for a while. We need a solution that takes this into
consideration. The current GMPLS draft takes into consideration the two
point of views:

a. SONET is totally included in SDH: great ! Just request an SDH signal. It
works and there is no issue.
b. one still has a SONET version which is not fully in SDH: just request a
SONET signal if not able to request an SDH signal.

Why do you want absolutely to make case b impossible ?

If we give you a solution that does what you want to do, plus in addition
what some other people want to do, why are you complaining ???? I don't
understand that you cannot accept other point of views if there are not
preventing you to do what you want.

Kind regards,

Eric

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Monday, February 25, 2002 7:52 PM
To: Kireeti Kompella
Cc: Wijnen, Bert (Bert); Mannie, Eric; [email-masked]';
[email-masked]'; ccamp-wg; [email-masked]'
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Kireeti:
I start with the simple answer and follow with the diatribe - those
who don't want to read the diatribe can stop after the answer:
My answer: (1)

Background: I clarified this in an email to you and the list last Dec. 18.
I am surprised and disappointed that you did not take note of the
answer. There are not a few signals in SONET which are not in SDH.
There is ONE, and it is one with no defined mappings. It is VT3, NOT
VC-3. I repeat my earlier email since you seem to have missed it
the first time. You even asked that someone should correct you if
you were wrong. Please read also the additional remarks and conclusions
below the included email.
Steve Trowbridge wrote:
> Kireeti,
> The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> (T1X1.5 chair) on this one and I take the liberty of sharing her response:
> 
> Deborah Brungard wrote:
> > The VT3 (3M) structure was defined - but no services (mappings) were
ever defined for it. So there are no services/equip
> > with it. My take was if in the future it was ever defined (doubtful), we
would be adding it to g707 also. So then it
> > would just be part of g707 too.
> 
> So basically, there are no mappings or equipment functions for this rate,
> and as far as we know no network equipment or networks supporting it.
> Deborah suggests that if we were ever to define such mappings, that this
> would be proposed for addition to G.707 and hence be part of SDH.
> 
> I think our agreement had been to use the SDH label for all signals that
> had the same multiplex structure in SONET and SDH. In Salt Lake City, we
thought
> that this was everything except VT3. Given that VT3 seems not to be a
"real"
> signal at this point and will likely be added to SDH if it ever becomes
> real, does our agreement then become that we use SDH labels for
everything?
> 
> Regards,
> Steve
> 
> Kireeti Kompella wrote:
> > 
> > Hi Deborah,
> > 
> > > I previously made the
> > > comments to merge the (1) SDH and SONET values as one value
> > 
> > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > several issues, among them this one.  The upshot was that whenever
> > possible, the SDH label should be used, with the encoding type
> > set to SDH (i.e., G.707); however, there are signals that have
> > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > me!), so we will keep SONET labels and encoding types around
> > for that case and for legacy equipment.
> > 
> > The revised SONET/SDH document will contain the exact wording.
> > I will also be sending a reply to the ITU communication stating
> > the agreement we came to.
> > 
> > Kireeti.

To do other than (1) introduces the case that there are two standardized
codings for the same multiplex structure based on whether one thinks it
is SONET or SDH. The result is that you are not interoperable in the
control plane for something that IS interoperable in the transport plane.
This is NOT the objective of standards.

Further, I am opposed to keeping pre-standard codings in a standards
track document just because someone has built to the draft. Every
ID includes the statement: "It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in progress.""
Certainly we all do early implementations, but any implementation done
against an ID must ALWAYS be done with the understanding that this is
subject to change, and may need revision once the ID is advanced to a
proposed standard.
Regards,
Steve

Kireeti Kompella wrote:
snip
> 
> Here's what I thought we had agreed:
> 
> 1) There is a document in the ITU that defines a *single* standard that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the only such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET
>    that do not match the ITU document.
> 
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
> 
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
> 
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
> 
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
> 
> Thanks,
> Kireeti.

Delivery-date: Mon, 25 Feb 2002 10:53:05 -0800
Date: Mon, 25 Feb 2002 11:51:47 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: "Wijnen, Bert (Bert)" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF

Kireeti:
I start with the simple answer and follow with the diatribe - those
who don't want to read the diatribe can stop after the answer:
My answer: (1)

Background: I clarified this in an email to you and the list last Dec. 18.
I am surprised and disappointed that you did not take note of the
answer. There are not a few signals in SONET which are not in SDH.
There is ONE, and it is one with no defined mappings. It is VT3, NOT
VC-3. I repeat my earlier email since you seem to have missed it
the first time. You even asked that someone should correct you if
you were wrong. Please read also the additional remarks and conclusions
below the included email.
Steve Trowbridge wrote:
> Kireeti,
> The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> (T1X1.5 chair) on this one and I take the liberty of sharing her response:
> 
> Deborah Brungard wrote:
> > The VT3 (3M) structure was defined - but no services (mappings) were ever defined for it. So there are no services/equip
> > with it. My take was if in the future it was ever defined (doubtful), we would be adding it to g707 also. So then it
> > would just be part of g707 too.
> 
> So basically, there are no mappings or equipment functions for this rate,
> and as far as we know no network equipment or networks supporting it.
> Deborah suggests that if we were ever to define such mappings, that this
> would be proposed for addition to G.707 and hence be part of SDH.
> 
> I think our agreement had been to use the SDH label for all signals that
> had the same multiplex structure in SONET and SDH. In Salt Lake City, we thought
> that this was everything except VT3. Given that VT3 seems not to be a "real"
> signal at this point and will likely be added to SDH if it ever becomes
> real, does our agreement then become that we use SDH labels for everything?
> 
> Regards,
> Steve
> 
> Kireeti Kompella wrote:
> > 
> > Hi Deborah,
> > 
> > > I previously made the
> > > comments to merge the (1) SDH and SONET values as one value
> > 
> > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > several issues, among them this one.  The upshot was that whenever
> > possible, the SDH label should be used, with the encoding type
> > set to SDH (i.e., G.707); however, there are signals that have
> > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > me!), so we will keep SONET labels and encoding types around
> > for that case and for legacy equipment.
> > 
> > The revised SONET/SDH document will contain the exact wording.
> > I will also be sending a reply to the ITU communication stating
> > the agreement we came to.
> > 
> > Kireeti.

To do other than (1) introduces the case that there are two standardized
codings for the same multiplex structure based on whether one thinks it
is SONET or SDH. The result is that you are not interoperable in the
control plane for something that IS interoperable in the transport plane.
This is NOT the objective of standards.

Further, I am opposed to keeping pre-standard codings in a standards
track document just because someone has built to the draft. Every
ID includes the statement: "It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in progress.""
Certainly we all do early implementations, but any implementation done
against an ID must ALWAYS be done with the understanding that this is
subject to change, and may need revision once the ID is advanced to a
proposed standard.
Regards,
Steve

Kireeti Kompella wrote:
snip
> 
> Here's what I thought we had agreed:
> 
> 1) There is a document in the ITU that defines a *single* standard that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the only such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET
>    that do not match the ITU document.
> 
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
> 
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
> 
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
> 
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
> 
> Thanks,
> Kireeti.

Delivery-date: Mon, 25 Feb 2002 09:41:05 -0800
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Cc: Greg Bernstein <[email-masked]>
Subject: RE: WG dcoument status
Date: Mon, 25 Feb 2002 18:39:26 +0100

... if I remember correctly, this was accepted as a WG document already.

Kind regards,

Eric

-----Original Message-----
From: Vishal Sharma [mailto:[email-masked]]
Sent: Monday, February 25, 2002 6:28 PM
To: Kireeti Kompella; [email-masked]
Cc: Greg Bernstein; Mannie, Eric
Subject: RE: WG dcoument status

Hi Kireeti,

There was one more document:
"Framework for GMPLS Control of SDH/SONET Networks"

that explains the issues to be kept in mind when using GMPLS for SDH/SONET
networks.
This was to become a WG document and progress along the Informational
track (per London presentation, and subsequent comments and meeting
minutes).

We had already trimmed the document in response to WG feedback
before the London meeting, and Greg presented the changes in
London.

This was one of the initial documents on the subject, geared towards
addressing the request by many people to explain what are the problems with
SONET using GMPLS.

It doesn't seem to be mentioned in the list below. We're looking for
guidance on what the Chairs and ADs would like us to do with this
document. We'd like to update it to reflect its WG status,
and move forward on it.

Please let us know how to proceed.

Thanks,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Sunday, February 24, 2002 8:52 PM
> To: [email-masked]
> Subject: WG dcoument status
>
>
> Here's a status update.
>
> The signaling drafts:
> 	draft-ietf-mpls-generalized-cr-ldp-05.txt
> 	draft-ietf-mpls-generalized-rsvp-te-06.txt
> 	draft-ietf-mpls-generalized-signaling-07.txt
> 	draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> have finished WG Last Call, and will be sent on to IETF Last Call.
> They are on the track for Proposed Standard.
>
> Bert Wijnen (AD) has suggested that there should be an implementation
> statement before these move on to IETF Last Call; the WG chairs and
> draft editors agreed.  One note: the SDH/SONET label issue must be put
> to rest before the SDH/SONET draft can move forward.  All other issues
> are now closed.
>
> The LMP draft:
> 	draft-ietf-ccamp-lmp-02.txt
> has gone through one round of WG Last Call comments and, once a
> new version has been produced incorporating these comments, will
> go through a final WG Last Call.  This is also targeted as a
> Proposed Standard.
>
> The following draft, a companion to the above LMP document, is
> also targeted at Proposed Standard, and is still being worked on:
> 	draft-ietf-ccamp-lmp-mib-00.txt
>
> The routing drafts:
> 	draft-ietf-ccamp-gmpls-routing-02.txt
> 	draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
> are awaiting WG consensus for going into WG Last Call.  These
> are also targeted for Proposed Standard.  (Note that the ISIS
> draft is owned by the ISIS WG.)
>
> The following drafts are Informational:
> 	draft-ietf-ccamp-gmpls-architecture-01.txt
> 	draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> They are awaiting final touches from the editor before they
> progress.
>
> The following two documents are also being worked on:
> 	draft-ietf-ccamp-oli-reqts-00.txt
> 	draft-ietf-ccamp-lmp-wdm-00.txt
> The first is an Informational document; the second is aimed
> at Proposed Standard.
>
> The MIBs are being reworked in response to comments from the AD.
> When the new versions are ready, the WG will then be asked for
> consensus to make them WG docs.
>
> Kireeti.
>

Delivery-date: Mon, 25 Feb 2002 09:31:17 -0800
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Cc: "Greg Bernstein" <[email-masked]>, "Eric Mannie" <[email-masked]>
Subject: RE: WG dcoument status
Date: Mon, 25 Feb 2002 12:28:08 -0500

Hi Kireeti,

There was one more document:
"Framework for GMPLS Control of SDH/SONET Networks"

that explains the issues to be kept in mind when using GMPLS for SDH/SONET
networks.
This was to become a WG document and progress along the Informational
track (per London presentation, and subsequent comments and meeting
minutes).

We had already trimmed the document in response to WG feedback
before the London meeting, and Greg presented the changes in
London.

This was one of the initial documents on the subject, geared towards
addressing the request by many people to explain what are the problems with
SONET using GMPLS.

It doesn't seem to be mentioned in the list below. We're looking for
guidance on what the Chairs and ADs would like us to do with this
document. We'd like to update it to reflect its WG status,
and move forward on it.

Please let us know how to proceed.

Thanks,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Sunday, February 24, 2002 8:52 PM
> To: [email-masked]
> Subject: WG dcoument status
>
>
> Here's a status update.
>
> The signaling drafts:
> 	draft-ietf-mpls-generalized-cr-ldp-05.txt
> 	draft-ietf-mpls-generalized-rsvp-te-06.txt
> 	draft-ietf-mpls-generalized-signaling-07.txt
> 	draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> have finished WG Last Call, and will be sent on to IETF Last Call.
> They are on the track for Proposed Standard.
>
> Bert Wijnen (AD) has suggested that there should be an implementation
> statement before these move on to IETF Last Call; the WG chairs and
> draft editors agreed.  One note: the SDH/SONET label issue must be put
> to rest before the SDH/SONET draft can move forward.  All other issues
> are now closed.
>
> The LMP draft:
> 	draft-ietf-ccamp-lmp-02.txt
> has gone through one round of WG Last Call comments and, once a
> new version has been produced incorporating these comments, will
> go through a final WG Last Call.  This is also targeted as a
> Proposed Standard.
>
> The following draft, a companion to the above LMP document, is
> also targeted at Proposed Standard, and is still being worked on:
> 	draft-ietf-ccamp-lmp-mib-00.txt
>
> The routing drafts:
> 	draft-ietf-ccamp-gmpls-routing-02.txt
> 	draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
> are awaiting WG consensus for going into WG Last Call.  These
> are also targeted for Proposed Standard.  (Note that the ISIS
> draft is owned by the ISIS WG.)
>
> The following drafts are Informational:
> 	draft-ietf-ccamp-gmpls-architecture-01.txt
> 	draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> They are awaiting final touches from the editor before they
> progress.
>
> The following two documents are also being worked on:
> 	draft-ietf-ccamp-oli-reqts-00.txt
> 	draft-ietf-ccamp-lmp-wdm-00.txt
> The first is an Informational document; the second is aimed
> at Proposed Standard.
>
> The MIBs are being reworked in response to comments from the AD.
> When the new versions are ready, the WG will then be asked for
> consensus to make them WG docs.
>
> Kireeti.
>

Delivery-date: Mon, 25 Feb 2002 08:37:56 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked]
Subject: GMPLS implementation report
Date: Mon, 25 Feb 2002 17:35:57 +0100

Hi All,

>> This report is to be prepared by the WG (chairs). And it needs to be sent
>> to iesg-secretary who will put it online on the IETF webpages, so that
>> during IETF Last Call people can actually look at the reports.
>
>Okay.  I'll get to work on it.

My humble two pennies on this one:

a. there was last year in May a (quite large) private interoperability event
organized by the OIF (before the Supercomm demo). GMPLS was tested there. I
guess that the IETF could ask the help of the OIF for such an implementation
report. Some feedback from this interop event was included in current GMPLS
drafts.

b. there will be in April a GMPLS interop event based on the latest GMPLS
drafts (at the UNH I think). We could suggest them to give us the feedback
that we need in the form of an ID.

Of course this doesn't prevent any manufacturers to test together in private
(already done by many) and to report about the results.

Kind regards,

Eric

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, February 25, 2002 5:09 PM
To: Wijnen, Bert (Bert)
Cc: [email-masked]
Subject: RE: WG dcoument status

On Mon, 25 Feb 2002, Wijnen, Bert (Bert) wrote:

> To be precise, the WG chairs will ask AD to consider the docs for PS
> (Proposed Standard). AD then reviews and if happy asks iesg-secretary
> to issue a 2 week IETF Last Call. After that IETF wide Last Call 
> finishes, then, depending on comments if any, AD can put the documents
> on the IESG agenda for final discussion/approval. 

Thanks for the clarification and summary of the process.

> This report is to be prepared by the WG (chairs). And it needs to be sent
> to iesg-secretary who will put it online on the IETF webpages, so that
> during IETF Last Call people can actually look at the reports.

Okay.  I'll get to work on it.

> Please also not that some people worred (back at SLC meeting) that this
> might delay the docs too much. I would like to remind you that it is now
> 2.5 months later, and I have still not seen any signs of such a report.

Mea culpa.  However, I am waiting for implementations based on the
latest versions.

> So... this means that WG Last Call is NOT finished on that one document.
> And I assume you want to process the whole set of 4 documents from above
> as one set. Is that a correct assumption?

Yes, that is preferred.

> There is also the one informational document that got split off in from
> this set. Is that ready and does it have WG consensus to be published
> as Informational RFC?

That is correct.  I'll send out a call for consensus on that.

> Will you pass that along with the set above too?

I'll ask the authors/editor.  It would be ready for publication
much sooner, but may not make sense to publish it independently.
However, it would be good to get the WG sense on this now.

Kireeti.

Delivery-date: Mon, 25 Feb 2002 08:22:37 -0800
Date: Mon, 25 Feb 2002 08:22:15 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: SDH/SONET extensions

The draft:
	draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt

specifies signaling for non-standard aspects of SONET and SDH.
It is to be processed as an Informational RFC.

I seek WG opinion on
(a) is this draft ready for publication?
(b) is more work needed *for the topics in the draft* -- i.e.,
    clarifications, corrections, etc., NOT new functionality?

BTW, these questions on consensus are among the most important
contributions you can make to the WG, so your participation is
not just encouraged, but vital.

Thanks,
Kireeti.

Delivery-date: Mon, 25 Feb 2002 08:10:01 -0800
Date: Mon, 25 Feb 2002 08:09:14 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: [email-masked]
Subject: RE: WG dcoument status

On Mon, 25 Feb 2002, Wijnen, Bert (Bert) wrote:

> To be precise, the WG chairs will ask AD to consider the docs for PS
> (Proposed Standard). AD then reviews and if happy asks iesg-secretary
> to issue a 2 week IETF Last Call. After that IETF wide Last Call 
> finishes, then, depending on comments if any, AD can put the documents
> on the IESG agenda for final discussion/approval. 

Thanks for the clarification and summary of the process.

> This report is to be prepared by the WG (chairs). And it needs to be sent
> to iesg-secretary who will put it online on the IETF webpages, so that
> during IETF Last Call people can actually look at the reports.

Okay.  I'll get to work on it.

> Please also not that some people worred (back at SLC meeting) that this
> might delay the docs too much. I would like to remind you that it is now
> 2.5 months later, and I have still not seen any signs of such a report.

Mea culpa.  However, I am waiting for implementations based on the
latest versions.

> So... this means that WG Last Call is NOT finished on that one document.
> And I assume you want to process the whole set of 4 documents from above
> as one set. Is that a correct assumption?

Yes, that is preferred.

> There is also the one informational document that got split off in from
> this set. Is that ready and does it have WG consensus to be published
> as Informational RFC?

That is correct.  I'll send out a call for consensus on that.

> Will you pass that along with the set above too?

I'll ask the authors/editor.  It would be ready for publication
much sooner, but may not make sense to publish it independently.
However, it would be good to get the WG sense on this now.

Kireeti.

Delivery-date: Mon, 25 Feb 2002 06:09:34 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: WG dcoument status
Date: Mon, 25 Feb 2002 15:09:03 +0100

Thanks Kireeti for posting the status.
I have some comments inline asd well.

Bert 

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Monday, February 25, 2002 2:52 AM
> To: [email-masked]
> Subject: WG dcoument status
> 
> 
> Here's a status update.
> 
> The signaling drafts:
> 	draft-ietf-mpls-generalized-cr-ldp-05.txt
> 	draft-ietf-mpls-generalized-rsvp-te-06.txt
> 	draft-ietf-mpls-generalized-signaling-07.txt
> 	draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> have finished WG Last Call, and will be sent on to IETF Last Call.
> They are on the track for Proposed Standard.
> 
To be precise, the WG chairs will ask AD to consider the docs for PS
(Proposed Standard). AD then reviews and if happy asks iesg-secretary
to issue a 2 week IETF Last Call. After that IETF wide Last Call 
finishes, then, depending on comments if any, AD can put the documents
on the IESG agenda for final discussion/approval. 

> Bert Wijnen (AD) has suggested that there should be an implementation
> statement before these move on to IETF Last Call; the WG chairs and
> draft editors agreed.

Pls note that we discussed this in the SUB-IP Directorate and that a
wider set of people agreed. The reason why we do this is based on earlier
practice in the RTG area in that a protocol that touches the core of the
network, that we do want to see implementation/interoperability reports
at the PS stage as opposed to at the DS stage.

This report is to be prepared by the WG (chairs). And it needs to be sent
to iesg-secretary who will put it online on the IETF webpages, so that
during IETF Last Call people can actually look at the reports.

Please also not that some people worred (back at SLC meeting) that this
might delay the docs too much. I would like to remind you that it is now
2.5 months later, and I have still not seen any signs of such a report.
So don't blame the process if things get delayed because of a report not
showing up.... In other words... it might be good if people start to
report implementation and interoperability test reults.

> One note: the SDH/SONET label issue must be put to rest before the 
> SDH/SONET draft can move forward.  All other issues are now closed.
> 
So... this means that WG Last Call is NOT finished on that one document.
And I assume you want to process the whole set of 4 documents from above
as one set. Is that a correct assumption?

There is also the one informational document that got split off in from
this set. Is that ready and does it have WG consensus to be published
as Informational RFC? Will you pass that along with the set above too?

Bert

Delivery-date: Mon, 25 Feb 2002 05:45:00 -0800
Date: Mon, 25 Feb 2002 08:42:02 -0500
To: Kireeti Kompella <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
Cc: [email-masked]

At 04:46 PM 2/24/2002 -0800, Kireeti Kompella wrote:

>Let me say a few words:
>
>1) There was good support for this work (the requirements doc) to
>    be a WG document at a previous IETF.  It is a good thing to
>    follow up and check what the mailing list thinks, as not everyone
>    attends IETFs.
>
>2) It is interesting that no one brought up the issue of whether this
>    work (tunnel tracing) is in the charter or not at the meeting.
>    There are those who think the charter isn't explicit enough.  I'll
>    talk to the ADs and see (a) if they think that this *is* in the
>    charter; (b) if not, are they willing to take it to the IESG and
>    add it to the charter.
>
>    My input on this (as WG chair) is that CCAMP is all about tunnels,
>    and a protocol to debug and test tunnels is well within scope, even
>    if not called out explicitly.

         Agreed.

>    Note that the charter is *not* subject to WG consensus, nor even
>    the WG chairs.  The IESG (and IAB?) are solely responsible,
>    although the WG and chairs can suggest changes.
>
>3) A document that is "in the right spirit" can become a WG document,
>    even if there are disagreements about some details, and even
>    "fundamental" questions.  Note that "fundamental" is often
>    subjective.
>
>I would like to have the mailing list equivalent of a 'show of hands'
>regarding this draft.  Do you think:
>(a) it should be a WG document?

         Yes.

>(b) it's good stuff, but not ready?

         The draft has some things to work out, but that
can be done through WG input after it becomes a
WG draft.

         --Tom

>(c) we need a new start?
>
>Please send in your opinions with one of the above up top.  Any
>detailed reasoning you have for your opinion may follow.
>
>Thanks!
>Kireeti.

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Sun, 24 Feb 2002 18:26:35 -0800
Date: Sun, 24 Feb 2002 18:25:17 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: CCAMP Protection/Restoration Design Team

Hi Folks,

I'd like to thank all of you who volunteered for this work.  To keep
the team small and effective, not everyone who volunteered could
participate directly.  Note that you can (and should) participate
through the CCAMP WG, by giving suggestions/feedback to the DT, and,
if deemed necessary, by proposing alternate documents.

Finally, note that the design team is _just another set of authors_.
The document(s) they produce are subject to WG consensus to progress
to WG documents and beyond.

Here's the Protection/Restoration Design Team.  They have been on
the job for a little over a month now.

Deborah Brungard
Sudheer Dharanikota
Jonathan Lang
Guangzhi Li
Eric Mannie
Dimitri Papadimitriou
Bala Rajagopalan
Yakov Rekhter

Sudheer is the team lead.

Their charter ("you" in what follows refers to the DT):

a) read drafts re protection/restoration in CCAMP, IPO and MPLS.
   These include (but are not limited to :-)):

*******	draft-ietf-tewg-restore-hierarchy-00.txt *******

	draft-bala-protection-restoration-signaling-00.txt
	draft-bala-restoration-signaling-01.txt
	draft-ietf-ipo-carrier-requirements-00.txt (Section 10)
	draft-kini-restoration-shared-backup-01.txt
	draft-li-shared-mesh-restoration-01.txt
	draft-many-optical-restoration-01.txt
	draft-suemura-protection-hierarchy-00.txt
	draft-ylee-protection-occ-00.txt
	-----------------------------------------------------
	draft-atlas-rsvp-local-protect-interop-02.txt
	draft-chang-mpls-path-protection-03.txt
	draft-chang-mpls-rsvpte-path-protection-ext-02.txt
	draft-owens-crldp-path-protection-ext-01.txt

   The first draft is the requirements for Protection & Restoration
   produced by the TEWG Design Team.  Functionality that you come up
   with should satisfy these requirements; stuff that you come up
   with that either goes beyond these requirements or doesn't meet
   some of them should be called out so that we can re-evaluate.

   The drafts below the line may be MPLS-specific, so they may or may
   not apply.

| AD's comment: For the first round... please refrain as much as possible
| from going beyond the requirements specified in the first draft.  That
| document restricted itself (on purpose) to requirements that are felt
| to be realistic for real operators and in the reasonably short term.
| So that is the scope you should be working in.

b) produce a terminology document, preferably using ITU-T terminology,
   but having a decoder ring to translate to terminology in current
   drafts as well as the TE WG document
c) produce an interim analysis document, comparing and contrasting
   approaches (i.e., the above drafts, published and ongoing work
   at the ITU/T1-X1/...)

| AD's comment: And be careful. Leave the ITU and T1X1-... etc work in
| those organisations if that is where it belongs (and often it does)!

d) produce a more complete version of (c)
e) produce a functional spec delineating
   o 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.
   o Overall approach
   o Objects/procedures/... needed in a protocol-independent fashion
f) produce a document detailing the changes for RSVP-TE and CR-LDP
g) produce a document detailing the changes for OSFP-TE and IS-IS-TE

The timeline for (a-c) is before the next IETF (March 1, 2002).

A first cut of (d) and (e) should be available by end of April, 2002.
If there is rough consensus in the CCAMP WG for the approach in (e),
work should then start on (f) and (g).

Kireeti.

Delivery-date: Sun, 24 Feb 2002 17:52:52 -0800
Date: Sun, 24 Feb 2002 17:52:08 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: WG dcoument status

Here's a status update.

The signaling drafts:
	draft-ietf-mpls-generalized-cr-ldp-05.txt
	draft-ietf-mpls-generalized-rsvp-te-06.txt
	draft-ietf-mpls-generalized-signaling-07.txt
	draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
have finished WG Last Call, and will be sent on to IETF Last Call.
They are on the track for Proposed Standard.

Bert Wijnen (AD) has suggested that there should be an implementation
statement before these move on to IETF Last Call; the WG chairs and
draft editors agreed.  One note: the SDH/SONET label issue must be put
to rest before the SDH/SONET draft can move forward.  All other issues
are now closed.

The LMP draft:
	draft-ietf-ccamp-lmp-02.txt
has gone through one round of WG Last Call comments and, once a
new version has been produced incorporating these comments, will
go through a final WG Last Call.  This is also targeted as a
Proposed Standard.

The following draft, a companion to the above LMP document, is
also targeted at Proposed Standard, and is still being worked on:
	draft-ietf-ccamp-lmp-mib-00.txt

The routing drafts:
	draft-ietf-ccamp-gmpls-routing-02.txt
	draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
are awaiting WG consensus for going into WG Last Call.  These
are also targeted for Proposed Standard.  (Note that the ISIS
draft is owned by the ISIS WG.)

The following drafts are Informational:
	draft-ietf-ccamp-gmpls-architecture-01.txt
	draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
They are awaiting final touches from the editor before they
progress.

The following two documents are also being worked on:
	draft-ietf-ccamp-oli-reqts-00.txt
	draft-ietf-ccamp-lmp-wdm-00.txt
The first is an Informational document; the second is aimed
at Proposed Standard.

The MIBs are being reworked in response to comments from the AD.
When the new versions are ready, the WG will then be asked for
consensus to make them WG docs.

Kireeti.

Delivery-date: Sun, 24 Feb 2002 16:55:42 -0800
Date: Sun, 24 Feb 2002 16:55:27 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Routing drafts

The two drafts:

draft-ietf-ccamp-gmpls-routing-02.txt            and
draft-ietf-ccamp-ospf-gmpls-extensions-04.txt

are, according to the authors, ready for WG Last Call.

I would like to judge WG consensus for this.

Thanks,
Kireeti.

Delivery-date: Sun, 24 Feb 2002 16:47:17 -0800
Date: Sun, 24 Feb 2002 16:46:38 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: David Allan <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02

Let me say a few words:

1) There was good support for this work (the requirements doc) to
   be a WG document at a previous IETF.  It is a good thing to
   follow up and check what the mailing list thinks, as not everyone
   attends IETFs.

2) It is interesting that no one brought up the issue of whether this
   work (tunnel tracing) is in the charter or not at the meeting.
   There are those who think the charter isn't explicit enough.  I'll
   talk to the ADs and see (a) if they think that this *is* in the
   charter; (b) if not, are they willing to take it to the IESG and
   add it to the charter.

   My input on this (as WG chair) is that CCAMP is all about tunnels,
   and a protocol to debug and test tunnels is well within scope, even
   if not called out explicitly.

   Note that the charter is *not* subject to WG consensus, nor even
   the WG chairs.  The IESG (and IAB?) are solely responsible,
   although the WG and chairs can suggest changes.

3) A document that is "in the right spirit" can become a WG document,
   even if there are disagreements about some details, and even
   "fundamental" questions.  Note that "fundamental" is often
   subjective.

I would like to have the mailing list equivalent of a 'show of hands'
regarding this draft.  Do you think:
(a) it should be a WG document?
(b) it's good stuff, but not ready?
(c) we need a new start?

Please send in your opinions with one of the above up top.  Any
detailed reasoning you have for your opinion may follow.

Thanks!
Kireeti.

Delivery-date: Sun, 24 Feb 2002 16:31:28 -0800
Date: Sun, 24 Feb 2002 16:10:36 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF

On Fri, 22 Feb 2002, Wijnen, Bert (Bert) wrote:

> Guys... I have seen to much of this. I have asked Kireeti
> EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
> WG mailing list. I do NOT want another 500 emails going back
> and forth on this issue. We need to approach this pragmatically.
> 
> - WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the 
>   WG mailing list on what exactly we agreed in SLC. That will
>   help to prepare a response to ITU-T as well

First off, I should apologize for letting this go on unchecked.

Second, I should make it known to the WG as a whole that there was
a discussion of this issue at SLC among several folks directly
involved, the ADs and the chairs.  I thought we had achieved
consensus, but now it seems not.

Here's what I thought we had agreed:

1) There is a document in the ITU that defines a *single* standard that
   encompasses both SONET and SDH -- almost.  There are a few signals
   that are in SONET but not in SDH; it was believed that the only such
   signal was VC-3.  Also, there are "legacy" implementations of SONET
   that do not match the ITU document.

2) Thus, it was agreed (to my recollection) that both the SONET and
   SDH label formats will be retained, with wording that says that
   whenever possible, the SDH equivalent should be used.  This covers
   both the cases of SONET signals that don't have SDH equivalents,
   and legacy equipment.

It is *not* the IETF's intention to promote an artificial separation
between SONET and SDH.  Nor is it the intent to promote as standard
work that is now "pre-standard".

However, it *is* the IETF's goal to be able to set up paths across
SONET and SDH networks, and to be pragmatic about this.  This was
the spirit in which an agreement was forged -- or so I thought.  In
retrospect, it would have been wise to go one step further and
decide the actual words.

So, here we are again, arguing over this.  Let's follow the AD's
suggestion and look for consensus in the WG.

1) Do you think we should have just a single set of traffic parameters
   and label values for SDH, and none for SONET?
or
2) Do you think we should have one for SONET and one for SDH, with
   the proviso that, if an SDH equivalent is available, one SHOULD
   use the SDH equivalent?
or
3) Do you think we should have one for SONET and one for SDH, with
   the proviso that, if an SDH equivalent is available, one MUST
   use the SDH equivalent?

(in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)

PLEASE respond with just (1), (2) or (3), and avoid long diatribes!

Feedback is welcome from *all* those interested in the CCAMP WG.
Also, what we are looking for is rough consensus, not votes.

Thanks,
Kireeti.

Delivery-date: Sun, 24 Feb 2002 16:31:25 -0800
Date: Sun, 24 Feb 2002 16:12:42 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: Zhi-Wei Lin <[email-masked]>, ccamp <[email-masked]>
Subject: Re: question about LDP restart...

On Sat, 23 Feb 2002, Adrian Farrel wrote:

> This was discussed at the last IETF and we are revising drafts accordingly.
> There three drafts on the table...

Thanks, Zhi-Wei, for your question, and Adrian, for your reply.
If you would now take this discussion to the MPLS WG, I'll thank
you doubly :-)

Kireeti.

Envelope-to: [email-masked]
Delivery-date: Sat, 23 Feb 2002 07:37:46 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Zhi-Wei Lin" <[email-masked]>, "ccamp" <[email-masked]>
Subject: Re: question about LDP restart...
Date: Sat, 23 Feb 2002 10:34:40 -0500

This was discussed at the last IETF and we are revising drafts accordingly.
There three drafts on the table...

1) draft-ietf-mpls-ldp-ft-02.txt
   Had already passed WG last call
   Fully scoped extensions to LDP for complete survivability
   of the protocol over software and hardware failure/swapping.

2) draft-ietf-mpls-ldp-restart-00.txt
   Assumes that it is acceptable to 're-learn' control state
   from neighboring nodes.  In this it is considerably simpler
   to implement, but may not be acceptable if rapid re-learning
   of large numbers of LSPs is required, or if seamless survival
   of traumatic events (such as software upload) is needed.

3) draft-smith-ldp-restart-00.txt
    A light-weight approach to check-pointing state applicable
    only to targeted LDP sessions where state transitions are
    rare and can acceptably be lost.  Particularly applicable to
    VPNs.

At the last IETF it was decided that 1) and 3) had some common ground because
they both preserve state, but that 2) is distinct because it re-learns state.
Thus 1) and 3) will be merged and 2) will continue as distinct.

There will be one piece of overlap: the merged 1) and 3) will include a method
of identifying whether or not the procedures used in 2) are supported.

The merging work has been done and is currently being reviewed prior to
publication.

Regards,
Adrian

----- Original Message -----
From: "Zhi-Wei Lin" <[email-masked]>
To: "ccamp" <[email-masked]>
Sent: Friday, February 22, 2002 9:33 AM
Subject: question about LDP restart...

> Hi all,
>
> I was just browsing some files, and came across two similar WG documents
> covering what I think are very similar areas:
>
> draft-ietf-mpls-ldp-restart-00.txt (published Jan '02)
> draft-ietf-mpls-ldp-ft-02.txt (published Oct '01)
>
> My question is: since the ldp-ft already provides a solution, is
> referenced in GMPLS CR-LDP as the way to go, what was the reason for
> making the ldp-restart also a WG document?
>
> Thanks for any clarification...
>
> Zhi
>
>

Delivery-date: Fri, 22 Feb 2002 09:15:17 -0800
From: "David Allan"<[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Fri, 22 Feb 2002 12:11:16 -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_01C1BBC3.F04030C0
Content-Type: text/plain;
	charset="iso-8859-1"

Neil:
 
My comment on the stuff turning up anywhere was more specific to IP. Given
that the network implements the service, a packet (that deliberately TTL
exhausts prematurely while on it's way between two points) ending up just
about anywhere could be a legitimate network response to a fault or
combination of faults, this is in addition to genuine misdirection
(forwarding table problems or similar). 
 
This behaviour is common to a set of identified technologies (in particular
forwarding driven by IP routing, with TTL on the forwarding plane) and
drives some of the requirements esp w.r.t. authorization/policy etc. Other
solutions for specific tunnel applications may have different
attributes/requirements (e.g. optical, ER-LSPs etc., concatenated L2TP
tunnels) where the traced entity is a closed system. 
 
Dave
 
 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 21, 2002 3:08 PM
To: [email-masked]; Allan, David [CAR:NS00:EXCH]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02

Hi Ron....nice to us getting back on to the real discussion here.  Few small
observations below.
Regards, Neil

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]]
Sent: 21 February 2002 19:32
To: David Allan
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02

Hi David,
 
Comments inline......

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 10:59 AM
To: Ron Bonica
Cc: [email-masked]
Subject: re: draft-bonica-tunneltrace-02

Ron: 

I have a number of comments on the draft. 

Clarifications: 

The discussion of traceroute in section 5, 2nd para. Are you really saying
that 
traceroute only reveals the current layer/level and reveals no knowledge of
nesting of 
lower layer/level tunnels or the relationship of the current level to higher
levels? 
It doesn't clearly come out.  

This is the case for some tunnel types, but not others. The next two
paragraphs provide examples. 

NH=> I am really glad you pointed this out Ron and its something I have
tried to explain to randy in an earlier mail.  That is, whilst the
*function* we are trying to use here (ie trail-trace) is common (wrt
objectives to be met) one has to accept/understand the nuances/limitations
of the technology of the layer network trail in question.  In other words,
it can't be strictly *common* in functional behaviour as the server layer
technologies are different.   Quite obvious IMO.

Comments on application requirements (numbers correspond to the
requirement): 

1) I think a broader discussion of some of the security issues needs to be
raised. First by 
whatever means a trace request needs to be able to be instantiated at a
tunnel end 
point. Second, as a result of initiating a trace, any node in the network
may be required to 
generate a response to the tracing application. Therefore the tracing
application is required 
to promiscuously accept responses. A mechanism is required to
authoritatively associate 
responses with requests and discard spurious messages. Further such a
mechanism should not be 
able to be leveraged for denial of service attacks (e.g. spurious trace
responses forcing lots 
of cryptography, defense against replay attacks etc.).  

Hmm.... good point! I thought about the probed device authenticating
traceProbes, but never considered the possibility that the probing device
might need to authenticate responses. I will add this to the next draft
version.  

NH=> This is also related to the point in my earlier mail about usually
having to assume a network to be defect free so that any such
'request/response' pairs work in an expected manner.  I suspect Dave is
alluding to the case where the 'request' pkt ends up at unexpected nodes (eg
due to swapped or mismerged LSPs say) and so (i) there has to be a viable
return path from anywhere and (ii) the nodes getting the requests must be
able to respond.....and if you expect to use this under such defect
conditions, then by inference the whole network must be 'GTTP aware' and
constantly looking for request occurences.

------_=_NextPart_001_01C1BBC3.F04030C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>re: draft-bonica-tunneltrace-02</TITLE>

<META content="MSHTML 5.00.3314.2100" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=370264016-22022002>Neil:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=370264016-22022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=370264016-22022002>My 
comment on the stuff turning up anywhere was more specific to IP. Given that the 
network implements the service, a packet (that deliberately TTL exhausts 
prematurely while on it's way between two points) ending up just about anywhere 
could be a legitimate network response to a fault or combination of faults, this 
is in addition to genuine misdirection (forwarding table problems or similar). 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=370264016-22022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=370264016-22022002>This 
behaviour is common to a set of identified technologies (in particular 
forwarding driven by IP routing,&nbsp;with TTL on the forwarding plane) and 
drives some of the requirements esp w.r.t. authorization/policy etc. Other 
solutions for specific tunnel applications may have different 
attributes/requirements (e.g. optical, ER-LSPs etc., concatenated L2TP tunnels) 
where the traced entity is a closed system. </SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=370264016-22022002>Dave</SPAN></FONT></DIV>
<DIV><SPAN class=370264016-22022002></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=370264016-22022002><FONT color=#0000ff 
face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=370264016-22022002>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
[email-masked] [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, 
February 21, 2002 3:08 PM<BR><B>To:</B> [email-masked]; Allan, David 
[CAR:NS00:EXCH]<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: 
draft-bonica-tunneltrace-02<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT>
  <DIV><FONT color=#0000ff face="Comic Sans MS" size=2><SPAN 
  class=760564419-21022002>Hi Ron....nice to us getting back on to the real 
  discussion here.&nbsp; Few small observations below.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face="Comic Sans MS" size=2><SPAN 
  class=760564419-21022002>Regards, Neil</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=ltr 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Ron Bonica 
    [mailto:[email-masked]]<BR><B>Sent:</B> 21 February 2002 
    19:32<BR><B>To:</B> David Allan<BR><B>Cc:</B> 
    [email-masked]<BR><B>Subject:</B> RE: 
    draft-bonica-tunneltrace-02<BR><BR></DIV></FONT>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=899431818-21022002>Hi 
    David,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=899431818-21022002></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=899431818-21022002>Comments inline......</SPAN></FONT></DIV>
    <BLOCKQUOTE dir=ltr 
    style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
      <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> David Allan 
      [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, February 20, 
      2002 10:59 AM<BR><B>To:</B> Ron Bonica<BR><B>Cc:</B> 
      [email-masked]<BR><B>Subject:</B> re: 
      draft-bonica-tunneltrace-02<BR><BR></FONT></DIV>
      <P><FONT size=2>Ron:</FONT> </P>
      <P><FONT size=2>I have a number of comments on the draft.</FONT> </P>
      <P><FONT size=2>Clarifications:</FONT> </P>
      <P><FONT size=2>The discussion of traceroute in section 5, 2nd para. Are 
      you really saying that</FONT> <BR><FONT size=2>traceroute only reveals the 
      current layer/level and reveals no knowledge of nesting of</FONT> 
      <BR><FONT size=2>lower layer/level tunnels or the relationship of the 
      current level to higher levels? </FONT><BR><FONT size=2>It doesn't clearly 
      come out.</FONT>&nbsp;<SPAN class=899431818-21022002><FONT color=#0000ff 
      face=Arial size=2>&nbsp;</FONT></SPAN></P>
      <P><FONT size=2><FONT color=#0000ff><SPAN class=899431818-21022002><FONT 
      face=Arial>This is the case for some tunnel types, but not others. The 
      next two paragraphs provide examples.<FONT face="Comic Sans MS"><SPAN 
      class=760564419-21022002>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></FONT></P>
      <P><FONT size=2><FONT color=#0000ff><SPAN class=899431818-21022002><FONT 
      face=Arial><FONT face="Comic Sans MS"><SPAN 
      class=760564419-21022002>NH=&gt; I am really glad you pointed this out Ron 
      and its something I have tried to explain to randy in an earlier 
      mail.&nbsp; That is, whilst the *function* we are trying to use here (ie 
      trail-trace) is common (wrt objectives to be met) one has to 
      accept/understand the nuances/limitations of the technology of the layer 
      network trail in question.&nbsp; In other words, it can't be strictly 
      *common* in functional behaviour as the server layer technologies are 
      different.&nbsp;&nbsp; Quite obvious 
      IMO.</SPAN></FONT></FONT></SPAN></FONT></FONT></P>
      <P><FONT size=2>Comments on application requirements (numbers correspond 
      to the requirement):</FONT> </P>
      <P><FONT size=2>1) I think a broader discussion of some of the security 
      issues needs to be raised. First by</FONT> <BR><FONT size=2>whatever means 
      a trace request needs to be able to be instantiated at a tunnel end</FONT> 
      <BR><FONT size=2>point. Second, as a result of initiating a trace, any 
      node in the network may be required to</FONT> <BR><FONT size=2>generate a 
      response to the tracing application. Therefore the tracing application is 
      required</FONT> <BR><FONT size=2>to promiscuously accept responses. A 
      mechanism is required to authoritatively associate</FONT> <BR><FONT 
      size=2>responses with requests and discard spurious messages. Further such 
      a mechanism should not be</FONT> <BR><FONT size=2>able to be leveraged for 
      denial of service attacks (e.g. spurious trace responses forcing lots 
      </FONT><BR><FONT size=2>of cryptography, defense against replay attacks 
      etc.).</FONT>&nbsp;<SPAN class=899431818-21022002><FONT color=#0000ff 
      face=Arial size=2>&nbsp;</FONT></SPAN></P>
      <P><SPAN class=899431818-21022002><FONT color=#0000ff face=Arial 
      size=2>Hmm.... good point! I thought about the probed device 
      authenticating traceProbes, but never considered the&nbsp;possibility that 
      the probing device might need to authenticate responses.&nbsp;I will add 
      this to the next draft&nbsp;version.</FONT></SPAN><SPAN 
      class=899431818-21022002>&nbsp;<FONT color=#0000ff face="Comic Sans MS" 
      size=2><SPAN class=760564419-21022002>&nbsp;</SPAN></FONT></SPAN></P>
      <P><SPAN class=899431818-21022002><FONT color=#0000ff face="Comic Sans MS" 
      size=2><SPAN class=760564419-21022002>NH=&gt; This is also related to the 
      point in my earlier mail about&nbsp;usually having to assume a network to 
      be defect free so that any such 'request/response' pairs work in an 
      expected manner.&nbsp; I suspect Dave is alluding to the case where the 
      'request' pkt ends up at unexpected nodes (eg due to swapped or mismerged 
      LSPs say) and so (i) there has to be a viable return path from anywhere 
      and (ii) the nodes getting the requests must be able to respond.....and if 
      you expect to use this under such defect conditions, then by inference the 
      whole network must be 'GTTP aware' and constantly looking for request 
      occurences.</SPAN></FONT></SPAN></P>
      <P>&nbsp;</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1BBC3.F04030C0--

Delivery-date: Fri, 22 Feb 2002 08:17:51 -0800
From: Shahram Davari <[email-masked]>
To: "'Ron Bonica'" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Fri, 22 Feb 2002 08:17:21 -0800

Hi Ron,

Some more comments. Some may have been asked before but I fail to understand them:

1) IPO is one of the tunneling technologies you propose must be supported. Do you mean that the ultimate solution should be able to trace SONET/SDH, DWDM, fiber forwarding trails?

2) Requirement 10,11: Do you mean it should ONLY support these kind of tunnels, or it should ALSO support these kind of tunnels? What about tunnels that don't use TTL? Should the solution support them or not?

3) Requirement 12, 13: Could you please explain more what do you mean by reverse MTU, and what is it useful for? 

4) section 7.4: Why MUST the solution be stateless? Will something break if it is not stateless? 

Thanks,
Shahram

Delivery-date: Fri, 22 Feb 2002 08:13:28 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Mannie, Eric" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: ccamp-wg <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Fri, 22 Feb 2002 17:12:36 +0100

Guys... I have seen to much of this. I have asked Kireeti
EXPLICITLY to try and CALL FOR or DECLARE CONSENSUS on the
WG mailing list. I do NOT want another 500 emails going back
and forth on this issue. We need to approach this pragmatically.

- WG Chair(s) try to get (rough) CONSENSUS CALLED OUT on the 
  WG mailing list on what exactly we agreed in SLC. That will
  help to prepare a response to ITU-T as well
- Based on that WG chairs try to get (rough) CONSENSUS CALLED OUT
  on the WG mailing list on the exact text. 
- Then Eric (editor) makes the changes as per CONSENSUS
- Then we're done.

Sorry that I need to step in, but this has been going on TOO long.

Bert 
speaking as AD

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Friday, February 22, 2002 5:03 PM
> To: [email-masked]'
> Cc: [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'
> Subject: SONET/SDH label agreement for IETF, ITU-T and OIF
> Importance: High
> 
> 
> Hi All,
> 
> Please note:
> 
> The two updated drafts "implementing" the agreement were sent 
> on the CCAMP
> mailing list the 14th of December 2001.
> 
> > move "Appendix 1 - Signal Type Values Extension For Group 
> > Signals" from the sonet-sdh document to the 
> sonet-sdh-extensions document;
> 
> Was done and sent on the CCAMP mailing list as said before. I 
> don't seen
> where the agreement was not fulfilled (just copy/pasted the 
> appendix to the
> non standard draft).
> 
> > Afterwards I noticed that the latter agreement is 
> > interpreted in different ways
> 
> The sentence that was added in the intro to implement the 
> agreement was
> reviewed by Maarten. It could certainly be improved, I agree, 
> but this was
> the result of several hours of discussions.
> 
> "A SONET signal which has an identical SDH signal SHOULD be 
> requested using
> the same traffic parameters as for the equivalent SDH signal, and will
> consequently use the SDH label."
> 
> The key point here is that the LSP Encoding Type (i.e. the 
> circuit type) in
> the root GMPLS signaling will indicate either SDH or SONET 
> (xor). It is
> impossible to have a double coding since we have an exclusive 
> OR. It is
> impossible to interpret it in two different ways.
> 
> The sentence above should better speak explicitly in terms of 
> LSP Encoding
> Type.
> 
> Having said that, there is something magic of having the 
> GMPLS SDH/SONET
> specification accepted also by the ITU-T as part of GMPLS for G.ASON
> (on-going activity). It would be a pity if the SONET label 
> format prevents
> it.
> 
> From my humble point of view, and since I understood that 
> ITU-T and ATM
> Forum have decided to work on PNNI extensions, there is also 
> something magic
> of using the same traffic parameters for GMPLS and PNNI, and 
> moreover at the
> IETF, ITU-T, ATM Forum and OIF. That will allow further 
> interoperability
> between the GMPLS and the PNNI control planes.
> 
> It would be a mistake if these discussions on the label 
> format prevent us to
> use the traffic parameter, and moreover if it results in 
> different label
> formats between IETF and ITU-T.
> 
> If we change the SONET label format there are two issues:
> 
> - already used by the OIF for UNI1.0.
> - already implemented in many boxes.
> 
> The OIF started to work on UNI 2.0 and we could suggest to 
> change the SONET
> label such as it is fully identical to the SDH label as part 
> of UNI 2.0.
> 
> Is there somebody fundamentally against changing the SONET 
> label format in
> the current context ?
> 
> I know that these issues are larger than the scope of IETF 
> but it becomes
> difficult to work without encompassing the broader scope of 
> also ITU-T, OIF
> and now ATM Forum.
> 
> I would suggest that Maarten and myself (with the help of Juergen and
> Dimitri Papadimitriou) review the two SDH/SONET drafts and 
> reach a FINAL
> consensus (as far as we are concerned) such as these 
> documents could be
> re-used in different contexts to ensure interoperability. I 
> am confident
> that by the end of next week we could republish these two 
> drafts with a very
> strong consensus.
> 
> Please advice.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Friday, February 22, 2002 3:13 PM
> To: Kireeti Kompella; Vijay Gill
> Cc: ccamp; Maarten Vissers; Scott Bradner
> Subject: RE: SONET/SDH label agreement?
> 
> 
> WG chairs, I think Maarten is correct here in the sense
> that by now, he (and the WG mailing list) could have 
> expected an answer. 
> 
> PLEASE act asap.
> 
> Bert 
> 
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Friday, February 22, 2002 9:17 AM
> > To: Kireeti Kompella; Vijay Gill
> > Cc: ccamp; Wijnen, Bert; Scott Bradner
> > Subject: Re: SONET/SDH label agreement?
> > 
> > 
> > Kireeti, Vijay,
> > 
> > On Feb. 8 I send you the email below. So far I haven't 
> > received an answer and I
> > assume the email has not been received by you or has got at 
> > the bottom of the
> > stack. As such a resent. Hope you will be able to respond today.
> > 
> > Thanks,
> > 
> > Maarten
> > 
> > Maarten Vissers wrote:
> > > 
> > > Vijay, Kireeti,
> > > 
> > > Almost two months ago we met in a small team to address the 
> > issues hindering the
> > > completion of draft-ietf-ccamp-gmpls-sonet-sdh and
> > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions.
> > > When this meeting ended, I was convinced we had reached 
> > agreement on the way to
> > > continue:
> > > 
> > > - move "Appendix 1 - Signal Type Values Extension For Group 
> > Signals" from the
> > > sonet-sdh document to the sonet-sdh-extensions document;
> > > 
> > > - modify the sonet-sdh document such that the SDH traffic 
> > parameters and label
> > > will be used for SONET signals for which there exists an 
> > identical SDH signal.
> > > SONET signals for which there is no SDH equivalent will 
> > keep using the SONET
> > > specific traffic parameters and label.
> > > 
> > > Afterwards I noticed that the latter agreement is 
> > interpreted in different ways:
> > > 
> > > A) keep both SONET and SDH specific traffic parameter and 
> > label specifications
> > > in the sonet-sdh document, and let the equipment 
> > manufacturer and/or operator
> > > choose if the traffic parameters and label for a SONET 
> > signal (with identical
> > > SDH signal) will use the SONET specification or the SDH 
> > specification. This
> > > results in a "double coding" scheme for SONET signals.
> > > 
> > > B) modify the sonet-sdh document such that there is one set 
> > of traffic
> > > parameters and label for each SONET signal. For those SONET 
> > signals with
> > > identical SDH signal (i.e. all SONET signals except VT-3) 
> > only the SDH traffic
> > > parameters and label will be specified. For those SONET 
> > signals that do not have
> > > an SDH equivalent (i.e. VT-3) the SONET traffic parameters 
> > and label will be
> > > specified. This results in a "single coding" scheme for 
> > SONET signals.
> > > 
> > > This dual interpretation is again hindering the completion 
> > of the sonet-sdh
> > > document.
> > > 
> > > Note that interpretation B) sufficiently meets the request 
> > from ITU-T SG15 as
> > > laid down in the its communications statement and as such 
> > was an acceptable
> > > compromise for me.
> > > 
> > ftp://sg15opticalt:[email-masked]/tsg15opticaltransport
> /COMMUNICATIONS/ccamp/IETF_ccamp_sdhgroup.html
> > (note -  I can't find this document on the IETF web site anymore)
> > Interpretation A) will at the best require two coding schemes to be
> supported in
> > each equipment, and at the worst will cause interworking 
> problems. It
> doesn't
> > meet the request from ITU-T SG15. If I would have been aware of this
> > interpretation, I would not have agreed with it.
> > 
> > May I ask you for your understanding/interpretation on this matter.
> > 
> > Regards,
> > 
> > Maarten
> 

Delivery-date: Fri, 22 Feb 2002 08:06:00 -0800
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: SONET/SDH label agreement for IETF, ITU-T and OIF
Date: Fri, 22 Feb 2002 17:02:40 +0100

Hi All,

Please note:

The two updated drafts "implementing" the agreement were sent on the CCAMP
mailing list the 14th of December 2001.

> move "Appendix 1 - Signal Type Values Extension For Group 
> Signals" from the sonet-sdh document to the sonet-sdh-extensions document;

Was done and sent on the CCAMP mailing list as said before. I don't seen
where the agreement was not fulfilled (just copy/pasted the appendix to the
non standard draft).

> Afterwards I noticed that the latter agreement is 
> interpreted in different ways

The sentence that was added in the intro to implement the agreement was
reviewed by Maarten. It could certainly be improved, I agree, but this was
the result of several hours of discussions.

"A SONET signal which has an identical SDH signal SHOULD be requested using
the same traffic parameters as for the equivalent SDH signal, and will
consequently use the SDH label."

The key point here is that the LSP Encoding Type (i.e. the circuit type) in
the root GMPLS signaling will indicate either SDH or SONET (xor). It is
impossible to have a double coding since we have an exclusive OR. It is
impossible to interpret it in two different ways.

The sentence above should better speak explicitly in terms of LSP Encoding
Type.

Having said that, there is something magic of having the GMPLS SDH/SONET
specification accepted also by the ITU-T as part of GMPLS for G.ASON
(on-going activity). It would be a pity if the SONET label format prevents
it.

>From my humble point of view, and since I understood that ITU-T and ATM
Forum have decided to work on PNNI extensions, there is also something magic
of using the same traffic parameters for GMPLS and PNNI, and moreover at the
IETF, ITU-T, ATM Forum and OIF. That will allow further interoperability
between the GMPLS and the PNNI control planes.

It would be a mistake if these discussions on the label format prevent us to
use the traffic parameter, and moreover if it results in different label
formats between IETF and ITU-T.

If we change the SONET label format there are two issues:

- already used by the OIF for UNI1.0.
- already implemented in many boxes.

The OIF started to work on UNI 2.0 and we could suggest to change the SONET
label such as it is fully identical to the SDH label as part of UNI 2.0.

Is there somebody fundamentally against changing the SONET label format in
the current context ?

I know that these issues are larger than the scope of IETF but it becomes
difficult to work without encompassing the broader scope of also ITU-T, OIF
and now ATM Forum.

I would suggest that Maarten and myself (with the help of Juergen and
Dimitri Papadimitriou) review the two SDH/SONET drafts and reach a FINAL
consensus (as far as we are concerned) such as these documents could be
re-used in different contexts to ensure interoperability. I am confident
that by the end of next week we could republish these two drafts with a very
strong consensus.

Please advice.

Kind regards,

Eric

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Friday, February 22, 2002 3:13 PM
To: Kireeti Kompella; Vijay Gill
Cc: ccamp; Maarten Vissers; Scott Bradner
Subject: RE: SONET/SDH label agreement?

WG chairs, I think Maarten is correct here in the sense
that by now, he (and the WG mailing list) could have 
expected an answer. 

PLEASE act asap.

Bert 

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Friday, February 22, 2002 9:17 AM
> To: Kireeti Kompella; Vijay Gill
> Cc: ccamp; Wijnen, Bert; Scott Bradner
> Subject: Re: SONET/SDH label agreement?
> 
> 
> Kireeti, Vijay,
> 
> On Feb. 8 I send you the email below. So far I haven't 
> received an answer and I
> assume the email has not been received by you or has got at 
> the bottom of the
> stack. As such a resent. Hope you will be able to respond today.
> 
> Thanks,
> 
> Maarten
> 
> Maarten Vissers wrote:
> > 
> > Vijay, Kireeti,
> > 
> > Almost two months ago we met in a small team to address the 
> issues hindering the
> > completion of draft-ietf-ccamp-gmpls-sonet-sdh and
> > draft-ietf-ccamp-gmpls-sonet-sdh-extensions.
> > When this meeting ended, I was convinced we had reached 
> agreement on the way to
> > continue:
> > 
> > - move "Appendix 1 - Signal Type Values Extension For Group 
> Signals" from the
> > sonet-sdh document to the sonet-sdh-extensions document;
> > 
> > - modify the sonet-sdh document such that the SDH traffic 
> parameters and label
> > will be used for SONET signals for which there exists an 
> identical SDH signal.
> > SONET signals for which there is no SDH equivalent will 
> keep using the SONET
> > specific traffic parameters and label.
> > 
> > Afterwards I noticed that the latter agreement is 
> interpreted in different ways:
> > 
> > A) keep both SONET and SDH specific traffic parameter and 
> label specifications
> > in the sonet-sdh document, and let the equipment 
> manufacturer and/or operator
> > choose if the traffic parameters and label for a SONET 
> signal (with identical
> > SDH signal) will use the SONET specification or the SDH 
> specification. This
> > results in a "double coding" scheme for SONET signals.
> > 
> > B) modify the sonet-sdh document such that there is one set 
> of traffic
> > parameters and label for each SONET signal. For those SONET 
> signals with
> > identical SDH signal (i.e. all SONET signals except VT-3) 
> only the SDH traffic
> > parameters and label will be specified. For those SONET 
> signals that do not have
> > an SDH equivalent (i.e. VT-3) the SONET traffic parameters 
> and label will be
> > specified. This results in a "single coding" scheme for 
> SONET signals.
> > 
> > This dual interpretation is again hindering the completion 
> of the sonet-sdh
> > document.
> > 
> > Note that interpretation B) sufficiently meets the request 
> from ITU-T SG15 as
> > laid down in the its communications statement and as such 
> was an acceptable
> > compromise for me.
> > 
> ftp://sg15opticalt:[email-masked]/tsg15opticaltransport
/COMMUNICATIONS/ccamp/IETF_ccamp_sdhgroup.html
> (note -  I can't find this document on the IETF web site anymore)
> Interpretation A) will at the best require two coding schemes to be
supported in
> each equipment, and at the worst will cause interworking problems. It
doesn't
> meet the request from ITU-T SG15. If I would have been aware of this
> interpretation, I would not have agreed with it.
> 
> May I ask you for your understanding/interpretation on this matter.
> 
> Regards,
> 
> Maarten

Delivery-date: Fri, 22 Feb 2002 06:38:52 -0800
From: "David Allan"<[email-masked]>
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: FW: draft bonica
Date: Fri, 22 Feb 2002 09:36:24 -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_01C1BBAE.4DACD300
Content-Type: text/plain;
	charset="iso-8859-1"

Ron:

Thanks for the reply. Comments in line:

rgds
Dave
<snip>

>>  The discussion of traceroute in section 5, 2nd para. Are you really
saying
>>  that traceroute only reveals the current layer/level and reveals no
knowledge
>>  of nesting of lower layer/level tunnels or the relationship of the
current level to
>>  higher levels?  It doesn't clearly come out.
>
>  This is the case for some tunnel types, but not others. The next two
>  paragraphs provide examples.

I'll read it again. I interpreted it is "I can see the current hop, or i can
see the underlying hops, it all depends on what level/layer I insert my
probes", that struck me as rather self evident but awkwardly worded.

>>Comments on application requirements (numbers correspond to the
>>requirement):
>>
>>  1) I think a broader discussion of some of the security issues needs to
be
>>  raised. First by whatever means a trace request needs to be able to be
instantiated at a
>>  tunnel end point. Second, as a result of initiating a trace, any node in
the network
>>  may be required to generate a response to the tracing application.
Therefore the tracing
>>  application is required to promiscuously accept responses. A mechanism
is required to
>>  authoritatively associate responses with requests and discard spurious
messages. Further such a
>>  mechanism should not be able to be leveraged for denial of service
attacks (e.g. spurious trace
>>  responses forcing lots of cryptography, defense against replay attacks
etc.).
>
>  Hmm.... good point! I thought about the probed device authenticating
>  traceProbes, but never considered the possibility that the probing device
>  might need to authenticate responses. I will add this to the next draft
>  version.

Actually the problem breaks down into about 4 things:

- any host can inject trace requests into the network.
- if you do not want to share trace information on your network, the only
mechanism is to block replies.
- if you are able to block replies, you are screening initiators (who can be
anyone). This imples authentication and replay protection.
- any host can send malicious replies to a tracing agent.
- you don't want unauthorized folks instructing other network elements to do
things, but that is more an requirement of the system design, and not
necessarily that of the protocol. 

>>
>>  2) Any interface? I think any routable interface (mind you this is where
>> separating out routing limitations into a separate section reduces the
clarity). I think there is
>> a separate stipulation that   there is no representation as to the number
of protocol exchanges it takes
>> to perform a trace (other than permitting the trace originator to perform
some measure of
>> flow control by the protocol being designed to bound the number of
responses a transaction will elicit;
>> ideally 1 to 1, this also has DOS implications similar to ICMP smurf type
attacks whereby the
>> responses to a single message can be unbounded). You actually bring this
up obliquely in the
>> protocol requirements, but IMHO it should be expressed less
prescriptively.
>
>  I am not sure that I understand the comment. Could you restate it?

Sure: There's actually two points in here, mainly relating to protocol 
requirements:
- one is the editorial suggestion that non-prescriptive requirements get 
extracted from the protocol requirements section and added to the 
application requirements section to improve clarity.
- the other is that rather than stipulating that the protocol design is 
built around two legged transactions, that it simply be able to pace 
itself by having any transaction have a bounded number of responses. It 
doesn't have to explicitly be one.

>>  3) Is third party really a special case? Can I not instantiate an
in-line
>>  trace using management protocols etc. and pull back the results.
>
>  One of our initial requirements was to provide all of the functionality
>  that "traceroute" currently provides. Currently, traceroute supports
third
>  party traces. Unfortunately, it does so using the IP source routing
option.
>  I wanted to support this functionality without fundamentally altering the
>  routing mechanism.

I'm not sure that saying this has to be a superset of traceroute is 
sustainable, simply desirable. I would agree with eliminating source 
routing as that is a major security hole. Can I suggest that the 
document suggest that third party traces would be a useful function, and 
that the mechanism chosen should avoid solutions with known problems 
(such as source routing).

>>  4) the application "displays" tunnels (editorial nit)? are we really
>>  discussing how much information the application collects and reports on.
The alternative interpretation is
>>  that the same amount of information is always collected, and somehow
filtered during presentation.
>>
>  The former. I will clarify this.

Great.

>>  4) When you say "single hop" or "in detail", are you really saying "this
>>  layer" or "constituent lower layer components"? It could use
clarification.
>
>  Yes. Again, I will clarify this

Again, great.

>>  5) Are you sure the collected information includes round trip delay?
It's
>>  not clear to me whether this is some pre-existing chunk of information
just lying around,
>>  or where the trace transaction is expected to measure RTT on the fly for
every hop and
>>  provide current view.
>
>  Again, we are mimicking functionality currently provided by traceroute.
We
>  would timestamp probes and echo the timestamp back in responses. The
tracing
>  application could calculate RTT by comparing the current time with the
>  timestamp.

The statement "RTT across each component" led me to believe you were
measuring each hop.

The other observagtion is that this would be irrelevant for third party
traces as it would include 
the latency from the tracing agent to one tunnel endpoint, and the 
latency from the intermediate node (where TTL exhaust occurred or 
whatever the mechanism used was) back to the tracing agent, plus if the 
authentication/priviledge token had any crypto requirements, this would 
introduce additional latency that had nothing to do with the path under 
trace.

>>  6) I think are more accurate statement is support any tunneling
technology
>>  that is used between IP endpoints. Otherwise this is not a sustainable
requirement. I am
>>  concerned, for example, that any intervening L2 or layer 2 and a half
skewers the model. (e.g..
>>  IP/PPP/L2TP, you can only reveal the PPP end points, or if you look at
L2TP tunnel switches, you
>>  appear to be SOL)

>   I am not sure that I agree. Given that the device at the head end of the
>   L2TP tunnel tells us that there is an L2TP tunnel involved, what stops
us
>   from tracing through it?

Okay, there was the two scenarios I mentioned. One was PPP over L2TP. 
The PPP would render the trace impossible as the LAC would not be 
visible to the client IP layer trace. The LNS would, so I suppose you 
could work backwards. The other is when there is a tunnel switch, where 
I can trace the client layer, but when I try to trace the IP carrying 
the L2TP, it would have to have knowledge of the tunnel switch function 
 in order to accurately report the real path. Put my LAC in Ottawa, my 
LNS in Toronto and my tunnel switch in Vancouver. The stuff is actually 
going Ottawa, Vancouver Toronto, but the trace of the layer below L2TP 
would only know the IP endpoints, and would trace the shortest path 
Ottawa->Toronto.

I think the generalized statement is that the tunnel technology must support
IP/TTL at every hop.

>>  7) This is the "detail" referred to earlier? Seems this one is subject
to
>>  the routing requirements reported later. Might be easier simply to
introduce that
>>  limitation here.

>  No. Requirement 4 states that the application will tell us details about
a
>  tunnel. Requirement 7 states that the application can tell us details
about
>  tunnels within tunnels.

I'm missing the distinction, only being able to recurse once (rq 4) 
seems to be an artificial restriction.

>>  8) Is the expectation that the quality of information obtained from a
>>  control plane trace and a forwarding plane be comparable? Can you
clarify what you mean by a control
>>  plane trace? I can see augmenting signalling protocols to faciliate this
(e.g. LSP query I-D), but that does
>>  not fit into this discussion.

>  Currently, traceroute traces through the forwarding plane. It sends a
>  probe downstream and each network device responds, indicating that it has
>  received the probe. When tracing the forwarding plane, only the device at
>  the tail-end of a hop can report on that hop.

>  Alternatively, we could ask the device at the head end of each hop to
>  report on the downstream interface. This is tracing through the control
>  plane.

Now I understand what you meant by control plane. Actually I would have
thought of 
this as tracing through the forwarding table. What should happen vs. what
does happen. That does'nt necessarily detect when what should happen is
wrong but it catches disconnects. That does look useful, I would have
described it differently.

>  Generally, control plane information and forwarding plane information are
>  pretty similar. There are, however, times when the two diverge. For
example,
>  when tracing through the forwarding plane of an MPLS LSP that is
configure
>  for penultimate hop popping, the egress LSR would have no way to know
that a
>  datagram was delivered through an LSP.

>  The control and forwarding plane can also diverge when routers are
broken.

>>   10) This seems to be overlapping with a solution framework.

>  How would you trace through the forwarding plane for tunnel types that do
>  not support TTL decrement?

I understand the point, more philosophical that it should not appear in 
a requirments document, even if the obvious solution.

Your staring point is the traceroute application, my starting point is more
generic.

>>  11) Any intention of aligning TTL models with the terminology emerging
>>  elsewhere (pipe or uniform models?).

  Always glad to clarify terminology.

>>  13) Don't quite grok the motivation. I plead ignorance ;-)

>  We could actually expand this requirement to include more interface
>  attributes and do it in both directions. You could get attributes in one
>  direction when tracing the control plane and in the other direction when
>  tracing the forwarding plane.

I should have been more clear. I did not understand why I would want to
collect reverse direction information. As the reverse path between two
points frequently will be disjoint from the forward path, struck me I was
simply collecting a lot of noise.

>>  The protocol requirements section is actually rather prescriptive. There
>>  are specific requirements in there that end up as either application
limitations or part of an
>>  applicability statement (e.g. routing requirements) or design
guidelines. The rest shouldn't be in this
>>  document.

  IMHO at the present time the document is not quite ready for "prime time".

------_=_NextPart_001_01C1BBAE.4DACD300
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>FW: draft bonica</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ron:</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for the reply. Comments in line:</FONT>
</P>

<P><FONT SIZE=3D2>rgds</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
<BR><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp; The discussion of traceroute in =
section 5, 2nd para. Are you really saying</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; that traceroute only reveals the =
current layer/level and reveals no knowledge</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; of nesting of lower layer/level =
tunnels or the relationship of the current level to</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; higher levels?&nbsp; It doesn't =
clearly come out.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; This is the case for some tunnel types, =
but not others. The next two</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; paragraphs provide examples.</FONT>
</P>

<P><FONT SIZE=3D2>I'll read it again. I interpreted it is &quot;I can =
see the current hop, or i can see the underlying hops, it all depends =
on what level/layer I insert my probes&quot;, that struck me as rather =
self evident but awkwardly worded.</FONT></P>

<P><FONT SIZE=3D2>&gt;&gt;Comments on application requirements (numbers =
correspond to the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;requirement):</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; 1) I think a broader discussion of =
some of the security issues needs to be</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; raised. First by whatever means a =
trace request needs to be able to be instantiated at a</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; tunnel end point. Second, as a result =
of initiating a trace, any node in the network</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; may be required to generate a =
response to the tracing application. Therefore the tracing</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; application is required to =
promiscuously accept responses. A mechanism is required to</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; authoritatively associate responses =
with requests and discard spurious messages. Further such a</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; mechanism should not be able to be =
leveraged for denial of service attacks (e.g. spurious trace</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; responses forcing lots of =
cryptography, defense against replay attacks etc.).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Hmm.... good point! I thought about the =
probed device authenticating</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; traceProbes, but never considered the =
possibility that the probing device</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; might need to authenticate responses. I =
will add this to the next draft</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; version.</FONT>
</P>

<P><FONT SIZE=3D2>Actually the problem breaks down into about 4 =
things:</FONT>
</P>

<P><FONT SIZE=3D2>- any host can inject trace requests into the =
network.</FONT>
<BR><FONT SIZE=3D2>- if you do not want to share trace information on =
your network, the only mechanism is to block replies.</FONT>
<BR><FONT SIZE=3D2>- if you are able to block replies, you are =
screening initiators (who can be anyone). This imples authentication =
and replay protection.</FONT></P>

<P><FONT SIZE=3D2>- any host can send malicious replies to a tracing =
agent.</FONT>
<BR><FONT SIZE=3D2>- you don't want unauthorized folks instructing =
other network elements to do things, but that is more an requirement of =
the system design, and not necessarily that of the protocol. =
</FONT></P>

<P><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; 2) Any interface? I think any =
routable interface (mind you this is where</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; separating out routing limitations into a =
separate section reduces the clarity). I think there is</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; a separate stipulation that&nbsp;&nbsp; =
there is no representation as to the number of protocol exchanges it =
takes</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; to perform a trace (other than permitting =
the trace originator to perform some measure of</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; flow control by the protocol being designed =
to bound the number of responses a transaction will elicit;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; ideally 1 to 1, this also has DOS =
implications similar to ICMP smurf type attacks whereby the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; responses to a single message can be =
unbounded). You actually bring this up obliquely in the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; protocol requirements, but IMHO it should =
be expressed less prescriptively.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; I am not sure that I understand the =
comment. Could you restate it?</FONT>
</P>

<P><FONT SIZE=3D2>Sure: There's actually two points in here, mainly =
relating to protocol </FONT>
<BR><FONT SIZE=3D2>requirements:</FONT>
<BR><FONT SIZE=3D2>- one is the editorial suggestion that =
non-prescriptive requirements get </FONT>
<BR><FONT SIZE=3D2>extracted from the protocol requirements section and =
added to the </FONT>
<BR><FONT SIZE=3D2>application requirements section to improve =
clarity.</FONT>
<BR><FONT SIZE=3D2>- the other is that rather than stipulating that the =
protocol design is </FONT>
<BR><FONT SIZE=3D2>built around two legged transactions, that it simply =
be able to pace </FONT>
<BR><FONT SIZE=3D2>itself by having any transaction have a bounded =
number of responses. It </FONT>
<BR><FONT SIZE=3D2>doesn't have to explicitly be one.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp; 3) Is third party really a special =
case? Can I not instantiate an in-line</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; trace using management protocols etc. =
and pull back the results.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; One of our initial requirements was to =
provide all of the functionality</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; that &quot;traceroute&quot; currently =
provides. Currently, traceroute supports third</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; party traces. Unfortunately, it does so =
using the IP source routing option.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; I wanted to support this functionality =
without fundamentally altering the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; routing mechanism.</FONT>
</P>

<P><FONT SIZE=3D2>I'm not sure that saying this has to be a superset of =
traceroute is </FONT>
<BR><FONT SIZE=3D2>sustainable, simply desirable. I would agree with =
eliminating source </FONT>
<BR><FONT SIZE=3D2>routing as that is a major security hole. Can I =
suggest that the </FONT>
<BR><FONT SIZE=3D2>document suggest that third party traces would be a =
useful function, and </FONT>
<BR><FONT SIZE=3D2>that the mechanism chosen should avoid solutions =
with known problems </FONT>
<BR><FONT SIZE=3D2>(such as source routing).</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp; 4) the application =
&quot;displays&quot; tunnels (editorial nit)? are we really</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; discussing how much information the =
application collects and reports on. The alternative interpretation =
is</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; that the same amount of information =
is always collected, and somehow filtered during presentation.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; The former. I will clarify this.</FONT>
</P>

<P><FONT SIZE=3D2>Great.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp; 4) When you say &quot;single hop&quot; =
or &quot;in detail&quot;, are you really saying &quot;this</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; layer&quot; or &quot;constituent =
lower layer components&quot;? It could use clarification.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Yes. Again, I will clarify this</FONT>
</P>

<P><FONT SIZE=3D2>Again, great.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp; 5) Are you sure the collected =
information includes round trip delay? It's</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; not clear to me whether this is some =
pre-existing chunk of information just lying around,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; or where the trace transaction is =
expected to measure RTT on the fly for every hop and</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; provide current view.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Again, we are mimicking functionality =
currently provided by traceroute. We</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; would timestamp probes and echo the =
timestamp back in responses. The tracing</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; application could calculate RTT by =
comparing the current time with the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; timestamp.</FONT>
</P>

<P><FONT SIZE=3D2>The statement &quot;RTT across each component&quot; =
led me to believe you were measuring each hop.</FONT>
</P>

<P><FONT SIZE=3D2>The other observagtion is that this would be =
irrelevant for third party traces as it would include </FONT>
<BR><FONT SIZE=3D2>the latency from the tracing agent to one tunnel =
endpoint, and the </FONT>
<BR><FONT SIZE=3D2>latency from the intermediate node (where TTL =
exhaust occurred or </FONT>
<BR><FONT SIZE=3D2>whatever the mechanism used was) back to the tracing =
agent, plus if the </FONT>
<BR><FONT SIZE=3D2>authentication/priviledge token had any crypto =
requirements, this would </FONT>
<BR><FONT SIZE=3D2>introduce additional latency that had nothing to do =
with the path under </FONT>
<BR><FONT SIZE=3D2>trace.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp; 6) I think are more accurate statement =
is support any tunneling technology</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; that is used between IP endpoints. =
Otherwise this is not a sustainable requirement. I am</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; concerned, for example, that any =
intervening L2 or layer 2 and a half skewers the model. (e.g..</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; IP/PPP/L2TP, you can only reveal the =
PPP end points, or if you look at L2TP tunnel switches, you</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; appear to be SOL)</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp; I am not sure that I agree. Given =
that the device at the head end of the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; L2TP tunnel tells us that there is =
an L2TP tunnel involved, what stops us</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; from tracing through it?</FONT>
</P>

<P><FONT SIZE=3D2>Okay, there was the two scenarios I mentioned. One =
was PPP over L2TP. </FONT>
<BR><FONT SIZE=3D2>The PPP would render the trace impossible as the LAC =
would not be </FONT>
<BR><FONT SIZE=3D2>visible to the client IP layer trace. The LNS would, =
so I suppose you </FONT>
<BR><FONT SIZE=3D2>could work backwards. The other is when there is a =
tunnel switch, where </FONT>
<BR><FONT SIZE=3D2>I can trace the client layer, but when I try to =
trace the IP carrying </FONT>
<BR><FONT SIZE=3D2>the L2TP, it would have to have knowledge of the =
tunnel switch function </FONT>
<BR><FONT SIZE=3D2>&nbsp;in order to accurately report the real path. =
Put my LAC in Ottawa, my </FONT>
<BR><FONT SIZE=3D2>LNS in Toronto and my tunnel switch in Vancouver. =
The stuff is actually </FONT>
<BR><FONT SIZE=3D2>going Ottawa, Vancouver Toronto, but the trace of =
the layer below L2TP </FONT>
<BR><FONT SIZE=3D2>would only know the IP endpoints, and would trace =
the shortest path </FONT>
<BR><FONT SIZE=3D2>Ottawa-&gt;Toronto.</FONT>
</P>

<P><FONT SIZE=3D2>I think the generalized statement is that the tunnel =
technology must support IP/TTL at every hop.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp; 7) This is the &quot;detail&quot; =
referred to earlier? Seems this one is subject to</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; the routing requirements reported =
later. Might be easier simply to introduce that</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; limitation here.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; No. Requirement 4 states that the =
application will tell us details about a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; tunnel. Requirement 7 states that the =
application can tell us details about</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; tunnels within tunnels.</FONT>
</P>

<P><FONT SIZE=3D2>I'm missing the distinction, only being able to =
recurse once (rq 4) </FONT>
<BR><FONT SIZE=3D2>seems to be an artificial restriction.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp; 8) Is the expectation that the quality =
of information obtained from a</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; control plane trace and a forwarding =
plane be comparable? Can you clarify what you mean by a control</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; plane trace? I can see augmenting =
signalling protocols to faciliate this (e.g. LSP query I-D), but that =
does</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; not fit into this discussion.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; Currently, traceroute traces through the =
forwarding plane. It sends a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; probe downstream and each network device =
responds, indicating that it has</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; received the probe. When tracing the =
forwarding plane, only the device at</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; the tail-end of a hop can report on that =
hop.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; Alternatively, we could ask the device at =
the head end of each hop to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; report on the downstream interface. This =
is tracing through the control</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; plane.</FONT>
</P>

<P><FONT SIZE=3D2>Now I understand what you meant by control plane. =
Actually I would have thought of </FONT>
<BR><FONT SIZE=3D2>this as tracing through the forwarding table. What =
should happen vs. what does happen. That does'nt necessarily detect =
when what should happen is wrong but it catches disconnects. That does =
look useful, I would have described it differently.</FONT></P>

<P><FONT SIZE=3D2>&gt;&nbsp; Generally, control plane information and =
forwarding plane information are</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; pretty similar. There are, however, times =
when the two diverge. For example,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; when tracing through the forwarding plane =
of an MPLS LSP that is configure</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; for penultimate hop popping, the egress =
LSR would have no way to know that a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; datagram was delivered through an =
LSP.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; The control and forwarding plane can also =
diverge when routers are broken.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp; 10) This seems to be overlapping =
with a solution framework.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; How would you trace through the forwarding =
plane for tunnel types that do</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; not support TTL decrement?</FONT>
</P>

<P><FONT SIZE=3D2>I understand the point, more philosophical that it =
should not appear in </FONT>
<BR><FONT SIZE=3D2>a requirments document, even if the obvious =
solution.</FONT>
</P>

<P><FONT SIZE=3D2>Your staring point is the traceroute application, my =
starting point is more generic.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp; 11) Any intention of aligning TTL =
models with the terminology emerging</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; elsewhere (pipe or uniform =
models?).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; Always glad to clarify terminology.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp; 13) Don't quite grok the motivation. I =
plead ignorance ;-)</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; We could actually expand this requirement =
to include more interface</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; attributes and do it in both directions. =
You could get attributes in one</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; direction when tracing the control plane =
and in the other direction when</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; tracing the forwarding plane.</FONT>
</P>

<P><FONT SIZE=3D2>I should have been more clear. I did not understand =
why I would want to collect reverse direction information. As the =
reverse path between two points frequently will be disjoint from the =
forward path, struck me I was simply collecting a lot of =
noise.</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt;&gt;&nbsp; The protocol requirements section is =
actually rather prescriptive. There</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; are specific requirements in there =
that end up as either application limitations or part of an</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; applicability statement (e.g. routing =
requirements) or design guidelines. The rest shouldn't be in =
this</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; document.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; IMHO at the present time the document is not =
quite ready for &quot;prime time&quot;.</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1BBAE.4DACD300--

Delivery-date: Fri, 22 Feb 2002 06:33:29 -0800
Date: Fri, 22 Feb 2002 09:33:07 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: question about LDP restart...

Hi all,

I was just browsing some files, and came across two similar WG documents 
covering what I think are very similar areas:

draft-ietf-mpls-ldp-restart-00.txt (published Jan '02)
draft-ietf-mpls-ldp-ft-02.txt (published Oct '01)

My question is: since the ldp-ft already provides a solution, is 
referenced in GMPLS CR-LDP as the way to go, what was the reason for 
making the ldp-restart also a WG document?

Thanks for any clarification...

Zhi

Delivery-date: Fri, 22 Feb 2002 06:13:33 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>
Cc: ccamp <[email-masked]>, Maarten Vissers <[email-masked]>, Scott Bradner <[email-masked]>
Subject: RE: SONET/SDH label agreement?
Date: Fri, 22 Feb 2002 15:12:58 +0100

WG chairs, I think Maarten is correct here in the sense
that by now, he (and the WG mailing list) could have 
expected an answer. 

PLEASE act asap.

Bert 

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Friday, February 22, 2002 9:17 AM
> To: Kireeti Kompella; Vijay Gill
> Cc: ccamp; Wijnen, Bert; Scott Bradner
> Subject: Re: SONET/SDH label agreement?
> 
> 
> Kireeti, Vijay,
> 
> On Feb. 8 I send you the email below. So far I haven't 
> received an answer and I
> assume the email has not been received by you or has got at 
> the bottom of the
> stack. As such a resent. Hope you will be able to respond today.
> 
> Thanks,
> 
> Maarten
> 
> Maarten Vissers wrote:
> > 
> > Vijay, Kireeti,
> > 
> > Almost two months ago we met in a small team to address the 
> issues hindering the
> > completion of draft-ietf-ccamp-gmpls-sonet-sdh and
> > draft-ietf-ccamp-gmpls-sonet-sdh-extensions.
> > When this meeting ended, I was convinced we had reached 
> agreement on the way to
> > continue:
> > 
> > - move "Appendix 1 - Signal Type Values Extension For Group 
> Signals" from the
> > sonet-sdh document to the sonet-sdh-extensions document;
> > 
> > - modify the sonet-sdh document such that the SDH traffic 
> parameters and label
> > will be used for SONET signals for which there exists an 
> identical SDH signal.
> > SONET signals for which there is no SDH equivalent will 
> keep using the SONET
> > specific traffic parameters and label.
> > 
> > Afterwards I noticed that the latter agreement is 
> interpreted in different ways:
> > 
> > A) keep both SONET and SDH specific traffic parameter and 
> label specifications
> > in the sonet-sdh document, and let the equipment 
> manufacturer and/or operator
> > choose if the traffic parameters and label for a SONET 
> signal (with identical
> > SDH signal) will use the SONET specification or the SDH 
> specification. This
> > results in a "double coding" scheme for SONET signals.
> > 
> > B) modify the sonet-sdh document such that there is one set 
> of traffic
> > parameters and label for each SONET signal. For those SONET 
> signals with
> > identical SDH signal (i.e. all SONET signals except VT-3) 
> only the SDH traffic
> > parameters and label will be specified. For those SONET 
> signals that do not have
> > an SDH equivalent (i.e. VT-3) the SONET traffic parameters 
> and label will be
> > specified. This results in a "single coding" scheme for 
> SONET signals.
> > 
> > This dual interpretation is again hindering the completion 
> of the sonet-sdh
> > document.
> > 
> > Note that interpretation B) sufficiently meets the request 
> from ITU-T SG15 as
> > laid down in the its communications statement and as such 
> was an acceptable
> > compromise for me.
> > 
> ftp://sg15opticalt:[email-masked]/tsg15opticaltransport
/COMMUNICATIONS/ccamp/IETF_ccamp_sdhgroup.html
> (note -  I can't find this document on the IETF web site anymore)
> Interpretation A) will at the best require two coding schemes to be supported in
> each equipment, and at the worst will cause interworking problems. It doesn't
> meet the request from ITU-T SG15. If I would have been aware of this
> interpretation, I would not have agreed with it.
> 
> May I ask you for your understanding/interpretation on this matter.
> 
> Regards,
> 
> Maarten

Delivery-date: Fri, 22 Feb 2002 05:55:56 -0800
Date: Fri, 22 Feb 2002 08:48:42 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
To: Shahram Davari <[email-masked]>, [email-masked]

Ooops....

I meant to send this to the list.

                     Ron

> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 5:15 PM
> To: 'Ron Bonica'
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> Ron,
> 
> This response of yours is not sent to the list. Did you intend 
> not to send it?
> 
> -Shahram
> 
> > -----Original Message-----
> > From: Ron Bonica [mailto:[email-masked]]
> > Sent: Thursday, February 21, 2002 5:04 PM
> > To: Shahram Davari
> > Subject: RE: draft-bonica-tunneltrace-02
> > 
> > 
> > Shahram,
> > 
> > You are correct. There is a backward compatibility requirement.
> > 
> > The required tracing protocol should be capable of tracing 
> > through many
> > tunnel types without changing any of those tunneling 
> > technologies. This is
> > to say, "we can't build some new feature into foo so that the 
> > tunnel tracing
> > protocol will work for foo".
> > 
> > I will add this to the next version of the spec.
> > 
> > Can you think of any other backwards compatibility requirement?
> > 
> >                                            Ron
> > 
> > > -----Original Message-----
> > > From: Shahram Davari [mailto:[email-masked]]
> > > Sent: Thursday, February 21, 2002 12:14 PM
> > > To: Shahram Davari; 'Ron Bonica'; [email-masked]'
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > > Hi,
> > >
> > > Also, don't you think backward compatibility is a requirement?
> > >
> > > -Shahram
> > >
> > > > -----Original Message-----
> > > > From: Shahram Davari
> > > > Sent: Thursday, February 21, 2002 12:03 PM
> > > > To: 'Ron Bonica'; [email-masked]
> > > > Subject: RE: draft-bonica-tunneltrace-02
> > > >
> > > >
> > > > Hi Ron,
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Ron Bonica [mailto:[email-masked]]
> > > > > Sent: Thursday, February 21, 2002 11:34 AM
> > > > > To: Shahram Davari; [email-masked]
> > > > > Subject: RE: draft-bonica-tunneltrace-02
> > > > >
> > > > >
> > > > > Sharam,
> > > > >
> > > > > Section 7 of this document enumerates a some minimal protocol
> > > > > requirements.
> > > > > Specifically, it states that:
> > > > >
> > > > > o a traceResponse will carry information regarding a section
> > > > > of the traced
> > > > > path
> > > >
> > > > Why not information about the whole path? Is it becasue GTTP
> > > > can't do it?
> > > >
> > > > > o a traceProbe will elicit a traceResponse
> > > >
> > > > Why not a series of trace responses? Anything fundamentally
> > > > wrong with it or is it becasue GTTP can't do it?
> > > >
> > > > > o UDP will carry traceProbes and traceResponses
> > > >
> > > > Why not TCP or even GTTP over IP?
> > > >
> > > > > o the protocol will be stateless
> > > > > o each device within the trace path need not maintain an IP
> > > > > route back to
> > > > > the device that hosts that tracing application
> > > >
> > > > Why? Why return path from head of the path is not enough?
> > > >
> > > > >
> > > >
> > > > > Although these broad brushstrokes do not specify a protocol,
> > > > > they provide
> > > > > direction to protocol developers.
> > > >
> > > > To develop GTTP!
> > > >
> > > >  We are looking for an IP
> > > > > based protocol
> > > > > that can probe network elements about whatever tunnels they
> > > > maintain,
> > > > > regardless of the tunnel type. We are not looking to extend
> > > > > the capabilities
> > > > > of any particular tunneling technology.
> > > >
> > > > I know. But the protocol restrictions that are mentioned must
> > > > be justified.
> > > >
> > > > -Shahram
> > > > >
> > > > >                                       Ron
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked] 
> [mailto:[email-masked]]On
> > > > > Behalf Of Shahram Davari
> > > > > Sent: Tuesday, February 19, 2002 5:29 PM
> > > > > To: [email-masked]
> > > > > Subject: RE: draft-bonica-tunneltrace-02
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > Although this document is a generic requirement for tunnel
> > > > > tracing, I find many protocol specific requirements that are not
> > > > > actually a requirement, rather they are suggesting a
> > > > specific solution.
> > > > >
> > > > > For example:
> > > > >
> > > > > "The protocol elicits a series of traceResponse messages."
> > > > > "Each traceResponse message represents a hop that connects the
> > > > > head-end of the traced path to the tail-end of the traced path"
> > > > > "Each traceProbe message elicits exactly one
> > > traceResponse message."
> > > > > "UDP carries traceProbe and traceResponse messages to their
> > > > destinations."
> > > > >
> > > > >
> > > > > Thanks,
> > > > > -Shahram
> > > > >
> > > > >
> > > >
> > >

Delivery-date: Fri, 22 Feb 2002 00:18:58 -0800
Cc: ccamp <[email-masked]>, "Wijnen, Bert" <[email-masked]>, Scott Bradner <[email-masked]>
Date: Fri, 22 Feb 2002 09:16:34 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>
Original-CC: ccamp <[email-masked]>, "Wijnen, Bert" <[email-masked]>, Scott Bradner <[email-masked]>
Subject: Re: SONET/SDH label agreement?

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

Kireeti, Vijay,

On Feb. 8 I send you the email below. So far I haven't received an answer and I
assume the email has not been received by you or has got at the bottom of the
stack. As such a resent. Hope you will be able to respond today.

Thanks,

Maarten

Maarten Vissers wrote:
> 
> Vijay, Kireeti,
> 
> Almost two months ago we met in a small team to address the issues hindering the
> completion of draft-ietf-ccamp-gmpls-sonet-sdh and
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions.
> When this meeting ended, I was convinced we had reached agreement on the way to
> continue:
> 
> - move "Appendix 1 - Signal Type Values Extension For Group Signals" from the
> sonet-sdh document to the sonet-sdh-extensions document;
> 
> - modify the sonet-sdh document such that the SDH traffic parameters and label
> will be used for SONET signals for which there exists an identical SDH signal.
> SONET signals for which there is no SDH equivalent will keep using the SONET
> specific traffic parameters and label.
> 
> Afterwards I noticed that the latter agreement is interpreted in different ways:
> 
> A) keep both SONET and SDH specific traffic parameter and label specifications
> in the sonet-sdh document, and let the equipment manufacturer and/or operator
> choose if the traffic parameters and label for a SONET signal (with identical
> SDH signal) will use the SONET specification or the SDH specification. This
> results in a "double coding" scheme for SONET signals.
> 
> B) modify the sonet-sdh document such that there is one set of traffic
> parameters and label for each SONET signal. For those SONET signals with
> identical SDH signal (i.e. all SONET signals except VT-3) only the SDH traffic
> parameters and label will be specified. For those SONET signals that do not have
> an SDH equivalent (i.e. VT-3) the SONET traffic parameters and label will be
> specified. This results in a "single coding" scheme for SONET signals.
> 
> This dual interpretation is again hindering the completion of the sonet-sdh
> document.
> 
> Note that interpretation B) sufficiently meets the request from ITU-T SG15 as
> laid down in the its communications statement and as such was an acceptable
> compromise for me.
> ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_sdhgroup.html
> (note -  I can't find this document on the IETF web site anymore)
> Interpretation A) will at the best require two coding schemes to be supported in
> each equipment, and at the worst will cause interworking problems. It doesn't
> meet the request from ITU-T SG15. If I would have been aware of this
> interpretation, I would not have agreed with it.
> 
> May I ask you for your understanding/interpretation on this matter.
> 
> Regards,
> 
> Maarten
--------------B45EB8F6C37F38E1E7895B36
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;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------B45EB8F6C37F38E1E7895B36--

Delivery-date: Thu, 21 Feb 2002 15:30:21 -0800
From: Shahram Davari <[email-masked]>
To: "'Ron Bonica'" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 15:28:54 -0800

Hi Ron,

It seems that most of what you described are things that you THINK are good to have, but there is no solid technical reason that they MUST be as requirements.  By doing so I think you will limit new ideas and innovations. Please see my other comments in-line:

-Shahram

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 5:04 PM
> To: Shahram Davari; [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> 
> 
> > -----Original Message-----
> > From: Shahram Davari [mailto:[email-masked]]
> > Sent: Thursday, February 21, 2002 12:03 PM
> > To: 'Ron Bonica'; [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> > Hi Ron,
> >
> >
> > > -----Original Message-----
> > > From: Ron Bonica [mailto:[email-masked]]
> > > Sent: Thursday, February 21, 2002 11:34 AM
> > > To: Shahram Davari; [email-masked]
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > > Sharam,
> > >
> > > Section 7 of this document enumerates a some minimal protocol
> > > requirements.
> > > Specifically, it states that:
> > >
> > > o a traceResponse will carry information regarding a section
> > > of the traced
> > > path
> >
> > Why not information about the whole path? Is it becasue 
> GTTP can't do it?
> 
> We have a requirement to trace through IP-in-IP tunnels. In this
> environment, no single device knows the entire path. The only 
> solution is to
> ask each device, either directly or through a proxy, about 
> the hop(s) in
> which it participates.

But a single device could solicit response from other devices on the same path.

> 
> >
> > > o a traceProbe will elicit a traceResponse
> >
> > Why not a series of trace responses? Anything fundamentally wrong
> > with it or is it becasue GTTP can't do it?
> 
> Given that we must trace through IP-in-IP tunnels, we must 
> elicit responses
> from multiple devices. So, when you ask why a single 
> traceProbe doesn't
> elicit a series of traceResponses, I assume that you are 
> asking why a single
> traceProbe doesn't elicit a series of traceResponses from a series of
> devices.
> 
> Let's entertain this possiblity. How could we alert each 
> router along the
> traced path to respond to a single probe?
> 
> We could specify the IP Router Alert Option on our probe, but 
> the presence
> of that option can cause the datagram to follow a different 
> path than it
> might otherwise follow. Another possibility is to maintains 
> some stateful,
> intermediate proxy that amplifies one traceProbe into many. 
> But why do that
> when the probing application is capable of doing the same thing?

a) It reduces the BW usage, b) eleminates connectivity to an outside application,
c) simplifies the application, etc.

What I am trying to say is it is best if you don't put the solution that you think is the
simplest solution as a requirement. Others may have simpler ideas. Perhaps you could add simplicity as a requirement.

BTW, shouldn't scalability be also a requirement?

> Even if you found a neat way to make multiple routers respond 
> to a single
> probe, you would still need to deal with out of sequence and missing
> responses.
> 
> IMHO, a one-to-one mapping of probe to response is simplest.
> 
> >
> > > o UDP will carry traceProbes and traceResponses
> >
> > Why not TCP or even GTTP over IP?
> 
> Does TCP add any value when a single probe elicits a single response?

Yes, it could make sure the message gets delivered.

> Putting the protocol PDU over IP is a possibility, but 
> protocol identifiers
> are in much shorter supply than UDP port numbers.

But this is not a requirement, it is a suggestion.

> 
> >
> > > o the protocol will be stateless
> > > o each device within the trace path need not maintain an IP
> > > route back to
> > > the device that hosts that tracing application
> >
> > Why? Why return path from head of the path is not enough?
> >
> 
> In its first version, a route from the head end of the traced path was
> enough. I changed this in response to a comment from the WG.
> 

Could you please refer me to such discussions.

> > >
> >
> > > Although these broad brushstrokes do not specify a protocol,
> > > they provide
> > > direction to protocol developers.
> >
> > To develop GTTP!
> 
> Or any other protocol that satisfies the requirements.
> 
> >
> >  We are looking for an IP
> > > based protocol
> > > that can probe network elements about whatever tunnels 
> they maintain,
> > > regardless of the tunnel type. We are not looking to extend
> > > the capabilities
> > > of any particular tunneling technology.
> >
> > I know. But the protocol restrictions that are mentioned must be
> > justified.
> >
> > -Shahram
> > >
> > >                                       Ron
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] 
[mailto:[email-masked]]On
> > > Behalf Of Shahram Davari
> > > Sent: Tuesday, February 19, 2002 5:29 PM
> > > To: [email-masked]
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > > Hi,
> > >
> > > Although this document is a generic requirement for tunnel
> > > tracing, I find many protocol specific requirements that are not
> > > actually a requirement, rather they are suggesting a
> > specific solution.
> > >
> > > For example:
> > >
> > > "The protocol elicits a series of traceResponse messages."
> > > "Each traceResponse message represents a hop that connects the
> > > head-end of the traced path to the tail-end of the traced path"
> > > "Each traceProbe message elicits exactly one traceResponse message."
> > > "UDP carries traceProbe and traceResponse messages to their
> > destinations."
> > >
> > >
> > > Thanks,
> > > -Shahram
> > >
> > >
> >

Delivery-date: Thu, 21 Feb 2002 14:10:14 -0800
Date: Thu, 21 Feb 2002 17:04:03 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
To: Shahram Davari <[email-masked]>, [email-masked]

> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 12:03 PM
> To: 'Ron Bonica'; [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
>
>
> Hi Ron,
>
>
> > -----Original Message-----
> > From: Ron Bonica [mailto:[email-masked]]
> > Sent: Thursday, February 21, 2002 11:34 AM
> > To: Shahram Davari; [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> > Sharam,
> >
> > Section 7 of this document enumerates a some minimal protocol
> > requirements.
> > Specifically, it states that:
> >
> > o a traceResponse will carry information regarding a section
> > of the traced
> > path
>
> Why not information about the whole path? Is it becasue GTTP can't do it?

We have a requirement to trace through IP-in-IP tunnels. In this
environment, no single device knows the entire path. The only solution is to
ask each device, either directly or through a proxy, about the hop(s) in
which it participates.

>
> > o a traceProbe will elicit a traceResponse
>
> Why not a series of trace responses? Anything fundamentally wrong
> with it or is it becasue GTTP can't do it?

Given that we must trace through IP-in-IP tunnels, we must elicit responses
from multiple devices. So, when you ask why a single traceProbe doesn't
elicit a series of traceResponses, I assume that you are asking why a single
traceProbe doesn't elicit a series of traceResponses from a series of
devices.

Let's entertain this possiblity. How could we alert each router along the
traced path to respond to a single probe?

We could specify the IP Router Alert Option on our probe, but the presence
of that option can cause the datagram to follow a different path than it
might otherwise follow. Another possibility is to maintains some stateful,
intermediate proxy that amplifies one traceProbe into many. But why do that
when the probing application is capable of doing the same thing?

Even if you found a neat way to make multiple routers respond to a single
probe, you would still need to deal with out of sequence and missing
responses.

IMHO, a one-to-one mapping of probe to response is simplest.

>
> > o UDP will carry traceProbes and traceResponses
>
> Why not TCP or even GTTP over IP?

Does TCP add any value when a single probe elicits a single response?
Putting the protocol PDU over IP is a possibility, but protocol identifiers
are in much shorter supply than UDP port numbers.

>
> > o the protocol will be stateless
> > o each device within the trace path need not maintain an IP
> > route back to
> > the device that hosts that tracing application
>
> Why? Why return path from head of the path is not enough?
>

In its first version, a route from the head end of the traced path was
enough. I changed this in response to a comment from the WG.

> >
>
> > Although these broad brushstrokes do not specify a protocol,
> > they provide
> > direction to protocol developers.
>
> To develop GTTP!

Or any other protocol that satisfies the requirements.

>
>  We are looking for an IP
> > based protocol
> > that can probe network elements about whatever tunnels they maintain,
> > regardless of the tunnel type. We are not looking to extend
> > the capabilities
> > of any particular tunneling technology.
>
> I know. But the protocol restrictions that are mentioned must be
> justified.
>
> -Shahram
> >
> >                                       Ron
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Shahram Davari
> > > Sent: Tuesday, February 19, 2002 5:29 PM
> > > To: [email-masked]
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > > Hi,
> > >
> > > Although this document is a generic requirement for tunnel
> > > tracing, I find many protocol specific requirements that are not
> > > actually a requirement, rather they are suggesting a
> > specific solution.
> > >
> > > For example:
> > >
> > > "The protocol elicits a series of traceResponse messages."
> > > "Each traceResponse message represents a hop that connects the
> > > head-end of the traced path to the tail-end of the traced path"
> > > "Each traceProbe message elicits exactly one traceResponse message."
> > > "UDP carries traceProbe and traceResponse messages to their
> > destinations."
> > >
> > >
> > > Thanks,
> > > -Shahram
> > >
> > >
> >

Delivery-date: Thu, 21 Feb 2002 12:09:38 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 20:08:27 -0000

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_01C1BB13.862DB640
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Ron....nice to us getting back on to the real discussion here.  Few small
observations below.
Regards, Neil

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]]
Sent: 21 February 2002 19:32
To: David Allan
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02

Hi David,
 
Comments inline......

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 10:59 AM
To: Ron Bonica
Cc: [email-masked]
Subject: re: draft-bonica-tunneltrace-02

Ron: 

I have a number of comments on the draft. 

Clarifications: 

The discussion of traceroute in section 5, 2nd para. Are you really saying
that 
traceroute only reveals the current layer/level and reveals no knowledge of
nesting of 
lower layer/level tunnels or the relationship of the current level to higher
levels? 
It doesn't clearly come out.  

This is the case for some tunnel types, but not others. The next two
paragraphs provide examples. 

NH=> I am really glad you pointed this out Ron and its something I have
tried to explain to randy in an earlier mail.  That is, whilst the
*function* we are trying to use here (ie trail-trace) is common (wrt
objectives to be met) one has to accept/understand the nuances/limitations
of the technology of the layer network trail in question.  In other words,
it can't be strictly *common* in functional behaviour as the server layer
technologies are different.   Quite obvious IMO.

Comments on application requirements (numbers correspond to the
requirement): 

1) I think a broader discussion of some of the security issues needs to be
raised. First by 
whatever means a trace request needs to be able to be instantiated at a
tunnel end 
point. Second, as a result of initiating a trace, any node in the network
may be required to 
generate a response to the tracing application. Therefore the tracing
application is required 
to promiscuously accept responses. A mechanism is required to
authoritatively associate 
responses with requests and discard spurious messages. Further such a
mechanism should not be 
able to be leveraged for denial of service attacks (e.g. spurious trace
responses forcing lots 
of cryptography, defense against replay attacks etc.).  

Hmm.... good point! I thought about the probed device authenticating
traceProbes, but never considered the possibility that the probing device
might need to authenticate responses. I will add this to the next draft
version.  

NH=> This is also related to the point in my earlier mail about usually
having to assume a network to be defect free so that any such
'request/response' pairs work in an expected manner.  I suspect Dave is
alluding to the case where the 'request' pkt ends up at unexpected nodes (eg
due to swapped or mismerged LSPs say) and so (i) there has to be a viable
return path from anywhere and (ii) the nodes getting the requests must be
able to respond.....and if you expect to use this under such defect
conditions, then by inference the whole network must be 'GTTP aware' and
constantly looking for request occurences.

------_=_NextPart_001_01C1BB13.862DB640
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>re: draft-bonica-tunneltrace-02</TITLE>

<META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face="Comic Sans MS" size=2><SPAN 
class=760564419-21022002>Hi Ron....nice to us getting back on to the real 
discussion here.&nbsp; Few small observations below.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS" size=2><SPAN 
class=760564419-21022002>Regards, Neil</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Ron Bonica 
  [mailto:[email-masked]]<BR><B>Sent:</B> 21 February 2002 
  19:32<BR><B>To:</B> David Allan<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> RE: 
  draft-bonica-tunneltrace-02<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=899431818-21022002>Hi 
  David,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=899431818-21022002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=899431818-21022002>Comments inline......</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=ltr 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> David Allan 
    [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, February 20, 
    2002 10:59 AM<BR><B>To:</B> Ron Bonica<BR><B>Cc:</B> 
    [email-masked]<BR><B>Subject:</B> re: 
    draft-bonica-tunneltrace-02<BR><BR></FONT></DIV>
    <P><FONT size=2>Ron:</FONT> </P>
    <P><FONT size=2>I have a number of comments on the draft.</FONT> </P>
    <P><FONT size=2>Clarifications:</FONT> </P>
    <P><FONT size=2>The discussion of traceroute in section 5, 2nd para. Are you 
    really saying that</FONT> <BR><FONT size=2>traceroute only reveals the 
    current layer/level and reveals no knowledge of nesting of</FONT> <BR><FONT 
    size=2>lower layer/level tunnels or the relationship of the current level to 
    higher levels? </FONT><BR><FONT size=2>It doesn't clearly come 
    out.</FONT>&nbsp;<SPAN class=899431818-21022002><FONT color=#0000ff 
    face=Arial size=2>&nbsp;</FONT></SPAN></P>
    <P><FONT size=2><FONT color=#0000ff><SPAN class=899431818-21022002><FONT 
    face=Arial>This is the case for some tunnel types, but not others. The next 
    two paragraphs provide examples.<FONT face="Comic Sans MS"><SPAN 
    class=760564419-21022002>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></FONT></P>
    <P><FONT size=2><FONT color=#0000ff><SPAN class=899431818-21022002><FONT 
    face=Arial><FONT face="Comic Sans MS"><SPAN class=760564419-21022002>NH=&gt; 
    I am really glad you pointed this out Ron and its something I have tried to 
    explain to randy in an earlier mail.&nbsp; That is, whilst the *function* we 
    are trying to use here (ie trail-trace) is common (wrt objectives to be met) 
    one has to accept/understand the nuances/limitations of the technology of 
    the layer network trail in question.&nbsp; In other words, it can't be 
    strictly *common* in functional behaviour as the server layer technologies 
    are different.&nbsp;&nbsp; Quite obvious 
    IMO.</SPAN></FONT></FONT></SPAN></FONT></FONT></P>
    <P><FONT size=2>Comments on application requirements (numbers correspond to 
    the requirement):</FONT> </P>
    <P><FONT size=2>1) I think a broader discussion of some of the security 
    issues needs to be raised. First by</FONT> <BR><FONT size=2>whatever means a 
    trace request needs to be able to be instantiated at a tunnel end</FONT> 
    <BR><FONT size=2>point. Second, as a result of initiating a trace, any node 
    in the network may be required to</FONT> <BR><FONT size=2>generate a 
    response to the tracing application. Therefore the tracing application is 
    required</FONT> <BR><FONT size=2>to promiscuously accept responses. A 
    mechanism is required to authoritatively associate</FONT> <BR><FONT 
    size=2>responses with requests and discard spurious messages. Further such a 
    mechanism should not be</FONT> <BR><FONT size=2>able to be leveraged for 
    denial of service attacks (e.g. spurious trace responses forcing lots 
    </FONT><BR><FONT size=2>of cryptography, defense against replay attacks 
    etc.).</FONT>&nbsp;<SPAN class=899431818-21022002><FONT color=#0000ff 
    face=Arial size=2>&nbsp;</FONT></SPAN></P>
    <P><SPAN class=899431818-21022002><FONT color=#0000ff face=Arial 
    size=2>Hmm.... good point! I thought about the probed device authenticating 
    traceProbes, but never considered the&nbsp;possibility that the probing 
    device might need to authenticate responses.&nbsp;I will add this to the 
    next draft&nbsp;version.</FONT></SPAN><SPAN 
    class=899431818-21022002>&nbsp;<FONT color=#0000ff face="Comic Sans MS" 
    size=2><SPAN class=760564419-21022002>&nbsp;</SPAN></FONT></SPAN></P>
    <P><SPAN class=899431818-21022002><FONT color=#0000ff face="Comic Sans MS" 
    size=2><SPAN class=760564419-21022002>NH=&gt; This is also related to the 
    point in my earlier mail about&nbsp;usually having to assume a network to be 
    defect free so that any such 'request/response' pairs work in an expected 
    manner.&nbsp; I suspect Dave is alluding to the case where the 'request' pkt 
    ends up at unexpected nodes (eg due to swapped or mismerged LSPs say) and so 
    (i) there has to be a viable return path from anywhere and (ii) the nodes 
    getting the requests must be able to respond.....and if you expect to use 
    this under such defect conditions, then by inference the whole network must 
    be 'GTTP aware' and constantly looking for request 
    occurences.</SPAN></FONT></SPAN></P>
    <P>&nbsp;</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1BB13.862DB640--

Delivery-date: Thu, 21 Feb 2002 11:36:47 -0800
Date: Thu, 21 Feb 2002 14:31:35 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
To: David Allan <[email-masked]>
Cc: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_mkxpWJL/oBePvflv+q8ABA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

re: draft-bonica-tunneltrace-02Hi David,

Comments inline......
  -----Original Message-----
  From: David Allan [mailto:[email-masked]]
  Sent: Wednesday, February 20, 2002 10:59 AM
  To: Ron Bonica
  Cc: [email-masked]
  Subject: re: draft-bonica-tunneltrace-02

  Ron:

  I have a number of comments on the draft.

  Clarifications:

  The discussion of traceroute in section 5, 2nd para. Are you really saying
that
  traceroute only reveals the current layer/level and reveals no knowledge
of nesting of
  lower layer/level tunnels or the relationship of the current level to
higher levels?
  It doesn't clearly come out.

  This is the case for some tunnel types, but not others. The next two
paragraphs provide examples.

  Comments on application requirements (numbers correspond to the
requirement):

  1) I think a broader discussion of some of the security issues needs to be
raised. First by
  whatever means a trace request needs to be able to be instantiated at a
tunnel end
  point. Second, as a result of initiating a trace, any node in the network
may be required to
  generate a response to the tracing application. Therefore the tracing
application is required
  to promiscuously accept responses. A mechanism is required to
authoritatively associate
  responses with requests and discard spurious messages. Further such a
mechanism should not be
  able to be leveraged for denial of service attacks (e.g. spurious trace
responses forcing lots
  of cryptography, defense against replay attacks etc.).

  Hmm.... good point! I thought about the probed device authenticating
traceProbes, but never considered the possibility that the probing device
might need to authenticate responses. I will add this to the next draft
version.

  2) Any interface? I think any routable interface (mind you this is where
separating out routing
  limitations into a separate section reduces the clarity). I think there is
a separate stipulation that
  there is no representation as to the number of protocol exchanges it takes
to perform a trace
  (other than permitting the trace originator to perform some measure of
flow control by the protocol
  being designed to bound the number of responses a transaction will elicit;
ideally 1 to 1, this also
  has DOS implications similar to ICMP smurf type attacks whereby the
responses to a single
  message can be unbounded). You actually bring this up obliquely in the
protocol requirements, but IMHO it
  should be expressed less prescriptively.

  I am not sure that I understand the comment. Could you restate it?

  3) Is third party really a special case? Can I not instantiate an in-line
trace using management
  protocols etc. and pull back the results.

  One of our initial requirements was to provide all of the functionality
that "traceroute" currently provides. Currently, traceroute supports third
party traces. Unfortunately, it does so using the IP source routing option.
I wanted to support this functionality without fundamentally altering the
routing mechanism.

  4) the application "displays" tunnels (editorial nit)? are we really
discussing how much information the
  application collects and reports on. The alternative interpretation is
that the same amount of
  information is always collected, and somehow filtered during presentation.

  The former. I will clarify this.

  4) When you say "single hop" or "in detail", are you really saying "this
layer" or "constituent
  lower layer components"? It could use clarification.

  Yes. Again, I will clarify this

  5) Are you sure the collected information includes round trip delay? It's
not clear to me
  whether this is some pre-existing chunk of information just lying around,
or where the trace
  transaction is expected to measure RTT on the fly for every hop and
provide current view.

  Again, we are mimicking functionality currently provided by traceroute. We
would timestamp probes and echo the timestamp back in responses. The tracing
 application could calculate RTT by comparing the current time with the
timestamp.

  6) I think are more accurate statement is support any tunneling technology
that is used between
  IP endpoints. Otherwise this is not a sustainable requirement. I am
concerned, for example, that
  any intervening L2 or layer 2 and a half skewers the model. (e.g..
IP/PPP/L2TP, you can only
  reveal the PPP end points, or if you look at L2TP tunnel switches, you
appear to be SOL)

  I am not sure that I agree. Given that the device at the head end of the
L2TP tunnel tells us that there is an L2TP tunnel involved, what stops us
from tracing through it?

  7) This is the "detail" referred to earlier? Seems this one is subject to
the routing
  requirements reported later. Might be easier simply to introduce that
limitation here.

  No. Requirement 4 states that the application will tell us details about a
tunnel. Requirement 7 states that the application can tell us details about
tunnels within tunnels.

  8) Is the expectation that the quality of information obtained from a
control plane trace and a
  forwarding plane be comparable? Can you clarify what you mean by a control
plane trace? I can see augmenting
  signalling protocols to faciliate this (e.g. LSP query I-D), but that does
not fit into this discussion.

  Currently, traceroute traces through the forwarding plane. It sends a
probe downstream and each network device responds, indicating that it has
received the probe. When tracing the forwarding plane, only the device at
the tail-end of a hop can report on that hop.

  Alternatively, we could ask the device at the head end of each hop to
report on the downstream interface. This is tracing through the control
plane.

  Generally, control plane information and forwarding plane information are
pretty similar. There are, however, times when the two diverge. For example,
when tracing through the forwarding plane of an MPLS LSP that is configure
for penultimate hop popping, the egress LSR would have no way to know that a
datagram was delivered through an LSP.

  The control and forwarding plane can also diverge when routers are broken.

   10) This seems to be overlapping with a solution framework.

  How would you trace through the forwarding plane for tunnel types that do
not support TTL decrement?

  11) Any intention of aligning TTL models with the terminology emerging
elsewhere (pipe or uniform
  models?).

  Always glad to clarify terminology.

  13) Don't quite grok the motivation. I plead ignorance ;-)

  We could actually expand this requirement to include more interface
attributes and do it in both directions. You could get attributes in one
direction when tracing the control plane and in the other direction when
tracing the forwarding plane.

  The protocol requirements section is actually rather prescriptive. There
are specific requirements
  in there that end up as either application limitations or part of an
applicability statement (e.g. routing
  requirements) or design guidelines. The rest shouldn't be in this
document.

  IMHO at the present time the document is not quite ready for "prime time".

  my two cents
  Dave

--Boundary_(ID_mkxpWJL/oBePvflv+q8ABA)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>re: draft-bonica-tunneltrace-02</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D899431818-21022002>Hi=20
David,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D899431818-21022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D899431818-21022002>Comments inline......</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> David Allan=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, February =
20,=20
  2002 10:59 AM<BR><B>To:</B> Ron Bonica<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> re:=20
  draft-bonica-tunneltrace-02<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Ron:</FONT> </P>
  <P><FONT size=3D2>I have a number of comments on the draft.</FONT> =
</P>
  <P><FONT size=3D2>Clarifications:</FONT> </P>
  <P><FONT size=3D2>The discussion of traceroute in section 5, 2nd para. =
Are you=20
  really saying that</FONT> <BR><FONT size=3D2>traceroute only reveals =
the current=20
  layer/level and reveals no knowledge of nesting of</FONT> <BR><FONT=20
  size=3D2>lower layer/level tunnels or the relationship of the current =
level to=20
  higher levels? </FONT><BR><FONT size=3D2>It doesn't clearly come=20
  out.</FONT>&nbsp;<SPAN class=3D899431818-21022002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>This=20
  is the case for some tunnel types, but not others. The next two =
paragraphs=20
  provide examples.</FONT></SPAN></P>
  <P><FONT size=3D2>Comments on application requirements (numbers =
correspond to=20
  the requirement):</FONT> </P>
  <P><FONT size=3D2>1) I think a broader discussion of some of the =
security issues=20
  needs to be raised. First by</FONT> <BR><FONT size=3D2>whatever means =
a trace=20
  request needs to be able to be instantiated at a tunnel end</FONT> =
<BR><FONT=20
  size=3D2>point. Second, as a result of initiating a trace, any node in =
the=20
  network may be required to</FONT> <BR><FONT size=3D2>generate a =
response to the=20
  tracing application. Therefore the tracing application is =
required</FONT>=20
  <BR><FONT size=3D2>to promiscuously accept responses. A mechanism is =
required to=20
  authoritatively associate</FONT> <BR><FONT size=3D2>responses with =
requests and=20
  discard spurious messages. Further such a mechanism should not =
be</FONT>=20
  <BR><FONT size=3D2>able to be leveraged for denial of service attacks =
(e.g.=20
  spurious trace responses forcing lots </FONT><BR><FONT size=3D2>of =
cryptography,=20
  defense against replay attacks etc.).</FONT>&nbsp;<SPAN=20
  class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =

  size=3D2>Hmm.... good point! I thought about the probed device =
authenticating=20
  traceProbes, but never considered the&nbsp;possibility that the =
probing device=20
  might need to authenticate responses.&nbsp;I will add this to the next =

  draft&nbsp;version.</FONT></SPAN><SPAN=20
  class=3D899431818-21022002>&nbsp;</SPAN></P>
  <P><FONT size=3D2>2) Any interface? I think any routable interface =
(mind you=20
  this is where separating out routing</FONT> <BR><FONT =
size=3D2>limitations into=20
  a separate section reduces the clarity). I think there is a separate=20
  stipulation that</FONT> <BR><FONT size=3D2>there is no representation =
as to the=20
  number of protocol exchanges it takes to perform a trace</FONT> =
<BR><FONT=20
  size=3D2>(other than permitting the trace originator to perform some =
measure of=20
  flow control by the protocol</FONT> <BR><FONT size=3D2>being designed =
to bound=20
  the number of responses a transaction will elicit; ideally 1 to 1, =
this also=20
  </FONT><BR><FONT size=3D2>has DOS implications similar to ICMP smurf =
type=20
  attacks whereby the responses to a single </FONT><BR><FONT =
size=3D2>message can=20
  be unbounded). You actually bring this up obliquely in the protocol=20
  requirements, but IMHO it</FONT> <BR><FONT size=3D2>should be =
expressed less=20
  prescriptively.</FONT>&nbsp;<SPAN class=3D899431818-21022002><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>I am=20
  not sure that I understand the comment. Could you restate=20
it?</FONT></SPAN></P>
  <P><FONT size=3D2>3) Is third party really a special case? Can I not =
instantiate=20
  an in-line trace using management</FONT> <BR><FONT size=3D2>protocols =
etc. and=20
  pull back the results.</FONT>&nbsp;<SPAN =
class=3D899431818-21022002><FONT=20
  face=3DArial color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>One of=20
  our initial requirements was to provide all of the =
functionality&nbsp;that=20
  "traceroute" currently provides. Currently, traceroute supports third =
party=20
  traces. Unfortunately, it does so using the IP source routing option. =
I wanted=20
  to support this functionality without fundamentally altering the =
routing=20
  mechanism.</FONT></SPAN></P>
  <P><FONT size=3D2>4) the application "displays" tunnels (editorial =
nit)? are we=20
  really discussing how much information the</FONT> <BR><FONT =
size=3D2>application=20
  collects and reports on. The alternative interpretation is that the =
same=20
  amount of</FONT> <BR><FONT size=3D2>information is always collected, =
and somehow=20
  filtered during presentation.</FONT>&nbsp;<SPAN =
class=3D899431818-21022002><FONT=20
  face=3DArial color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN><SPAN=20
  class=3D899431818-21022002>&nbsp;</SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
  former. I will clarify this.</FONT></SPAN></P>
  <P><FONT size=3D2>4) When you say "single hop" or "in detail", are you =
really=20
  saying "this layer" or "constituent</FONT> <BR><FONT size=3D2>lower =
layer=20
  components"? It could use clarification.</FONT>&nbsp;<SPAN=20
  class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN><SPAN =
class=3D899431818-21022002>&nbsp;</SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>Yes.=20
  Again, I will clarify this</FONT></SPAN></P>
  <P><FONT size=3D2>5) Are you sure the collected information includes =
round trip=20
  delay? It's not clear to me</FONT> <BR><FONT size=3D2>whether this is =
some=20
  pre-existing chunk of information just lying around, or where the =
trace</FONT>=20
  <BR><FONT size=3D2>transaction is expected to measure RTT on the fly =
for every=20
  hop and provide current view.</FONT>&nbsp;<SPAN =
class=3D899431818-21022002><FONT=20
  face=3DArial color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>Again,=20
  we are mimicking functionality currently provided by traceroute. We =
would=20
  timestamp probes and echo the timestamp back in responses. The tracing =

  application could calculate RTT by comparing the current time with the =

  timestamp.</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>6) I think are more accurate statement is support =
any=20
  tunneling technology that is used between</FONT> <BR><FONT size=3D2>IP =

  endpoints. Otherwise this is not a sustainable requirement. I am =
concerned,=20
  for example, that</FONT> <BR><FONT size=3D2>any intervening L2 or =
layer 2 and a=20
  half skewers the model. (e.g.. IP/PPP/L2TP, you can only</FONT> =
<BR><FONT=20
  size=3D2>reveal the PPP end points, or if you look at L2TP tunnel =
switches, you=20
  appear to be SOL)</FONT>&nbsp;<SPAN class=3D899431818-21022002><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>I am=20
  not sure that I agree. Given that the device at the head end of the =
L2TP=20
  tunnel tells&nbsp;us that there is an L2TP tunnel involved, what =
stops&nbsp;us=20
  from tracing through it?</FONT></SPAN></P>
  <P><FONT size=3D2>7) This is the "detail" referred to earlier? Seems =
this one is=20
  subject to the routing</FONT> <BR><FONT size=3D2>requirements reported =
later.=20
  Might be easier simply to introduce that limitation =
here.</FONT>&nbsp;<SPAN=20
  class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>No.=20
  Requirement 4 states that the application will =
tell&nbsp;us&nbsp;details about=20
  a tunnel. Requirement 7 states that the application can=20
  tell&nbsp;us&nbsp;details about tunnels within=20
tunnels.</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>8) Is the expectation that the quality of =
information obtained=20
  from a control plane trace and a</FONT> <BR><FONT size=3D2>forwarding =
plane be=20
  comparable? Can you clarify what you mean by a control plane trace? I =
can see=20
  augmenting</FONT> <BR><FONT size=3D2>signalling protocols to faciliate =
this=20
  (e.g. LSP query I-D), but that does not fit into this=20
  discussion.</FONT>&nbsp;<SPAN class=3D899431818-21022002><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =

  size=3D2>Currently, traceroute traces through the forwarding plane. It =
sends a=20
  probe downstream and each network device responds, indicating that it =
has=20
  received the probe. When tracing the forwarding plane, only the device =
at the=20
  tail-end of a hop can report on that hop.</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =

  size=3D2>Alternatively, we could ask the device at the head end of =
each hop to=20
  report on the downstream interface. This is tracing through the =
control plane.=20
  </FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =

  size=3D2>Generally, control plane information and forwarding plane =
information=20
  are pretty similar. There are, however, times when the two diverge. =
For=20
  example, when tracing through the forwarding plane of an MPLS LSP that =
is=20
  configure for penultimate hop popping, the egress LSR would have no =
way to=20
  know that a datagram was delivered through an LSP.</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
  control and forwarding plane can also diverge when routers are=20
  broken.</FONT></SPAN></P>
  <P><FONT size=3D2><SPAN class=3D899431818-21022002>&nbsp;</SPAN>10) =
This seems to=20
  be overlapping with a solution framework.</FONT>&nbsp;<SPAN=20
  class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>How=20
  would you trace through the forwarding plane for tunnel types that do =
not=20
  support TTL decrement?</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>11) Any intention of aligning TTL models with the =
terminology=20
  emerging elsewhere (pipe or uniform</FONT> <BR><FONT=20
  size=3D2>models?).</FONT>&nbsp;<SPAN class=3D899431818-21022002><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>Always=20
  glad to clarify terminology.</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>13) Don't quite grok the motivation. I plead =
ignorance=20
  ;-)</FONT>&nbsp;<SPAN class=3D899431818-21022002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D899431818-21022002><FONT face=3DArial color=3D#0000ff =
size=3D2>We=20
  could actually expand this requirement to include more interface =
attributes=20
  and do it in both directions. You could get attributes in one =
direction when=20
  tracing the control plane and in the other direction when tracing the=20
  forwarding plane.</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>The protocol requirements section is actually rather =

  prescriptive. There are specific requirements</FONT> <BR><FONT =
size=3D2>in there=20
  that end up as either application limitations or part of an =
applicability=20
  statement (e.g. routing </FONT><BR><FONT size=3D2>requirements) or =
design=20
  guidelines. The rest shouldn't be in this document.</FONT> </P>
  <P><FONT size=3D2>IMHO at the present time the document is not quite =
ready for=20
  "prime time".</FONT> </P>
  <P><FONT size=3D2>my two cents</FONT> <BR><FONT size=3D2>Dave</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_mkxpWJL/oBePvflv+q8ABA)--

Delivery-date: Thu, 21 Feb 2002 11:33:33 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 19:31:08 -0000

Randy,

Please see below.  Regards, Neil
 
> >>  - Define signalling protocols and measurement protocols 
> such that they
> >>    support multiple physical path and tunnel technologies
> > 2) Does OAM, that measure availability, also fall under 
> this definition? 
> 
> does OAM work on GRE?  IPsec?  if not, guess it's not Common, eh?
NH=> The thing that is *common* here is the function.  There are common
network problems that need solving for *any* cnls protocol and *any* co
protocol....and in the latter case there are some minor differences whether
the user-plane trail is cct or pkt based.  So OAM *is* a common
requirement....as is an ability to measure availability and QoS, since these
define the (server) SLAs for whatever the client payload of the layer
network in question is (which, dare I say it, is often another layer
network).  One thing that is *not* a common function however across all
layer networks is trail-trace as a per node 'request/response'
mechanism....at least as done in the user-plane (since to work
correctly/reliably one has to make certain assumptions about the behaviour
of the network, ie usually simply that it is defect-free....and in which
case one can simply ask the control-plane).  Another thing that is not
common in most layer networks is built-in layer violations, ie using the OAM
mechanisms of layer network X to proxy for missing OAM functions in layer
network Y....and there are very good reasons to avoid layer violations.

However, to have *common* availability and QoS SLAs, you needs to use a
*common* approach......which for any co technology goes like this:
-	1st identify all defect types
-	2nd define their entry/exit criteria and consequent actions....some
of which can be really quite important, like client layer alarms suppression
on lower layer failure, or supressing traffic (to protect customer
information integrity) if a misconfiguration failure occurs
-	3rd define available/unavailable trail state entry/exit criteria
based on defect state persitencies
-	4th you can now begin to define QoS and availability SLAs.  Note
carefully that although these are disjoint, the QoS metrics must only be
measured when the trail is in the available state since their SLA objectives
are only valid then......very obvious why I think.

So it's not a technology specific OAM embodiment that is common across all
layer networks (and in fact this would be a layer violation by direct
inference if it was) but the *function* that is common....and its embodiment
is layer/technology specific.

Delivery-date: Thu, 21 Feb 2002 10:40:12 -0800
From: Shahram Davari <[email-masked]>
To: "'Scott  Bradner'" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 10:39:40 -0800

Scott,

This is a different question. First thing is to decide whether it is included in the charter or not. If it is not then a WG consensus is needed in order to add it. I don't think my single vote will change anything.

-Shahram

> -----Original Message-----
> From: Scott Bradner [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 1:30 PM
> To: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> 
> Shahram sez:
>   The problem is not that the charter text is not clear. The 
> problem is that
>   path-trace inherently does not fit into the mandate of the charter.
> 
> should it?
> 
> Scott
> 

Envelope-to: [email-masked]
Delivery-date: Thu, 21 Feb 2002 10:30:46 -0800
Date: Thu, 21 Feb 2002 13:30:28 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02

Shahram sez:
  The problem is not that the charter text is not clear. The problem is that
  path-trace inherently does not fit into the mandate of the charter.

should it?

Scott

Delivery-date: Thu, 21 Feb 2002 10:27:46 -0800
From: Shahram Davari <[email-masked]>
To: "'Randy Bush'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 10:27:07 -0800

Hi,

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 1:18 PM
> To: Shahram Davari
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> >> does OAM work on GRE?  IPsec?  if not, guess it's not Common, eh?
> > I was talking about a generic OAM not MPLS OAM. 
> 
> no such draft that i can find.

This was a generic question, not about any specific draft. So based on you reponses, a generic OAM falls under CCAMP. Good. 

> 
> > The problem is not that the charter text is not clear. The 
> problem is that
> > path-trace inherently does not fit into the mandate of the charter.
> 
> the folk who formed the mandate seem not to agree with your 
> position.

Their intention is irrelevant now. What is WRITTEN as the current charter should be the
base for discussion. May be they were not careful in writing the charter to express their
views, that is not the WGs fault. The current charter has been consented and any change needs WG conesensus.

-Shahram

  but
> if there is anything we can do to fix the text of the charter 
> to better
> communicate that to you, do tell us.
> 
> randy
> 

Delivery-date: Thu, 21 Feb 2002 10:19:07 -0800
From: Randy Bush <[email-masked]>
To: Shahram Davari <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 10:18:25 -0800

>> does OAM work on GRE?  IPsec?  if not, guess it's not Common, eh?
> I was talking about a generic OAM not MPLS OAM. 

no such draft that i can find.

> The problem is not that the charter text is not clear. The problem is that
> path-trace inherently does not fit into the mandate of the charter.

the folk who formed the mandate seem not to agree with your position.  but
if there is anything we can do to fix the text of the charter to better
communicate that to you, do tell us.

randy

Delivery-date: Thu, 21 Feb 2002 10:14:20 -0800
From: Shahram Davari <[email-masked]>
To: "'Randy Bush'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 10:13:52 -0800

Hi,

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 1:08 PM
> To: Shahram Davari
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> >>  - Define signalling protocols and measurement protocols 
> such that they
> >>    support multiple physical path and tunnel technologies
> > 2) Does OAM, that measure availability, also fall under 
> this definition? 
> 
> does OAM work on GRE?  IPsec?  if not, guess it's not Common, eh?

I was talking about a generic OAM not MPLS OAM. 

> 
> >> - and draft-bonica-tunneltrace-01.txt to this section.
> 
> > The charter only says this is under consideration, it is 
> not saying it is
> > a WG document or should be a WG document.
> 
> as i offered previously, if you don't feel the current 
> charter text covers
> this document, then send text that you will accept that says 
> it is in the
> charter and the charter will be fixed.  not a problem.

The problem is not that the charter text is not clear. The problem is that path-trace inherently does not fit into the mandate of the charter. 

-Shahram

> 
> randy
> 

Delivery-date: Thu, 21 Feb 2002 10:08:24 -0800
From: Randy Bush <[email-masked]>
To: Shahram Davari <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 10:08:06 -0800

>>  - Define signalling protocols and measurement protocols such that they
>>    support multiple physical path and tunnel technologies
> 2) Does OAM, that measure availability, also fall under this definition? 

does OAM work on GRE?  IPsec?  if not, guess it's not Common, eh?

>> - and draft-bonica-tunneltrace-01.txt to this section.

> The charter only says this is under consideration, it is not saying it is
> a WG document or should be a WG document.

as i offered previously, if you don't feel the current charter text covers
this document, then send text that you will accept that says it is in the
charter and the charter will be fixed.  not a problem.

randy

Delivery-date: Thu, 21 Feb 2002 10:06:48 -0800
From: Shahram Davari <[email-masked]>
To: "'Randy Bush'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 10:05:25 -0800

Hi Randy,

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 12:23 PM
> To: Shahram Davari
> Cc: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> > I don't see path-trace being mentioned in the charter.
> 
> try the first one
> 
>     - Define signalling protocols and measurement protocols 
> such that they
>       support multiple physical path and tunnel technologies
>

If you mean trace-route is part of the measurement protocol, then:

1) I don't think path-trace is measuring anything, unless the reason for adding round trip delay as an additional function was to make it look like it is measuring something.

2) Does OAM, that measure availability, also fall under this definition? 

> also
> 
>     - and draft-bonica-tunneltrace-01.txt to this section.

The charter only says this is under consideration, it is not saying it is a WG document or should be a WG document.

 
> 
> may be relevant
> 
> but if you think it needs more specific text in the charter, 
> then suggest
> the text and the ADs, who seem to think this is within 
> charter, can have
> the charter changed.

I think those that want this as a WG item, should do it!
As I see it path-trace is not, even implicitly, in the current charter.

-Shahram

> 
> randy
> 

Delivery-date: Thu, 21 Feb 2002 09:38:20 -0800
From: "David Allan"<[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: Ron Bonica <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 12:37:24 -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_01C1BAFE.6C159DA0
Content-Type: text/plain;
	charset="iso-8859-1"

Loa:

Sometimes a group has a sufficiently inclusive charter in advance of
specific proposals, sometimes specific proposals have sufficient utility to
justify a charter change. OK...we agree on process

However, none of this discussion of process is doing anything to resolve my
original technical concerns with the content of the draft. As elevation to
WG draft status implies that some portion of the content has a reasonable
probability of making it's way into an RFC, and the document may/will be
referenced as a "work in progress" and granted some degree of influence, I'd
like to focus more on those issues. esp when I've voiced concerns or sought
clarifications on the majority of the requirements presented.

later
Dave

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 12:21 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Ron Bonica; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02
> 
> 
> Dave,
> 
> if you change "appeared in" to "is within the scope of" I agree.
> 
> /Loa
> 
> David Allan wrote:
> 
> > Loa:
> > 
> > I thought the first criteria (somthing we should do) was met when 
> > somthing appeared in a WG charter and milestones ;-).
> > 
> > As for the second, I'll agree to disagree. I've provided my 
> suggestions 
> > as to changes that should be made before IMO the document is a good 
> > enough starting point. Others should offer their opinions.
> > 
> > cheers
> > Dave
> > 
> >  > -----Original Message-----
> >  > From: Loa Andersson [mailto:[email-masked]]
> >  > Sent: Wednesday, February 20, 2002 11:31 AM
> >  > To: Allan, David [CAR:NS00:EXCH]
> >  > Cc: Ron Bonica; [email-masked]
> >  > Subject: Re: draft-bonica-tunneltrace-02
> >  >
> >  >
> >  > All,
> >  >
> >  > a more IETF (possibly ccamp) philosophical question. What do
> >  > we do when we accept a document as a WG document. In my mind
> >  > it is a step taken when we realise that this is something that
> >  > the WG group should do and the document is a good enough starting
> >  > point for doing this work.
> >  >
> >  > Even if I agreed with all of Dave's comments it is my 2 c's
> >  > that both the criteria above are met and that we should progress
> >  > the doc as a WG document.
> >  >
> >  > There will be a couple of iterations where the comments will be
> >  > addressed and possibly be worked into the final req doc.
> >  >
> >  >
> >  > /Loa
> >  >
> >  > David Allan wrote:
> >  >
> >  > > Ron:
> >  > >
> >  > > I have a number of comments on the draft.
> >  > >
> >  > > Clarifications:
> >  > >
> >  > > The discussion of traceroute in section 5, 2nd para. 
> Are you really
> >  > > saying that
> >  > > traceroute only reveals the current layer/level and reveals
> >  > no knowledge
> >  > > of nesting of
> >  > > lower layer/level tunnels or the relationship of the
> >  > current level to
> >  > > higher levels?
> >  > > It doesn't clearly come out.
> >  > >
> >  > > Comments on application requirements (numbers correspond to the
> >  > > requirement):
> >  > >
> >  > > 1) I think a broader discussion of some of the security
> >  > issues needs to
> >  > > be raised. First by
> >  > > whatever means a trace request needs to be able to be
> >  > instantiated at a
> >  > > tunnel end
> >  > > point. Second, as a result of initiating a trace, any 
> node in the
> >  > > network may be required to
> >  > > generate a response to the tracing application. Therefore
> >  > the tracing
> >  > > application is required
> >  > > to promiscuously accept responses. A mechanism is required to
> >  > > authoritatively associate
> >  > > responses with requests and discard spurious messages.
> >  > Further such a
> >  > > mechanism should not be
> >  > > able to be leveraged for denial of service attacks (e.g.
> >  > spurious trace
> >  > > responses forcing lots
> >  > > of cryptography, defense against replay attacks etc.).
> >  > >
> >  > > 2) Any interface? I think any routable interface (mind you
> >  > this is where
> >  > > separating out routing
> >  > > limitations into a separate section reduces the clarity). I
> >  > think there
> >  > > is a separate stipulation that
> >  > > there is no representation as to the number of protocol
> >  > exchanges it
> >  > > takes to perform a trace
> >  > > (other than permitting the trace originator to perform some
> >  > measure of
> >  > > flow control by the protocol
> >  > > being designed to bound the number of responses a 
> transaction will
> >  > > elicit; ideally 1 to 1, this also
> >  > > has DOS implications similar to ICMP smurf type 
> attacks whereby the
> >  > > responses to a single
> >  > > message can be unbounded). You actually bring this up
> >  > obliquely in the
> >  > > protocol requirements, but IMHO it
> >  > > should be expressed less prescriptively.
> >  > >
> >  > > 3) Is third party really a special case? Can I not 
> instantiate an
> >  > > in-line trace using management
> >  > > protocols etc. and pull back the results.
> >  > >
> >  > > 4) the application "displays" tunnels (editorial nit)? are
> >  > we really
> >  > > discussing how much information the
> >  > > application collects and reports on. The alternative
> >  > interpretation is
> >  > > that the same amount of
> >  > > information is always collected, and somehow filtered
> >  > during presentation.
> >  > >
> >  > > 4) When you say "single hop" or "in detail", are you really
> >  > saying "this
> >  > > layer" or "constituent
> >  > > lower layer components"? It could use clarification.
> >  > >
> >  > > 5) Are you sure the collected information includes round
> >  > trip delay?
> >  > > It's not clear to me
> >  > > whether this is some pre-existing chunk of information 
> just lying
> >  > > around, or where the trace
> >  > > transaction is expected to measure RTT on the fly for 
> every hop and
> >  > > provide current view.
> >  > >
> >  > > 6) I think are more accurate statement is support any tunneling
> >  > > technology that is used between
> >  > > IP endpoints. Otherwise this is not a sustainable 
> requirement. I am
> >  > > concerned, for example, that
> >  > > any intervening L2 or layer 2 and a half skewers the 
> model. (e.g..
> >  > > IP/PPP/L2TP, you can only
> >  > > reveal the PPP end points, or if you look at L2TP tunnel
> >  > switches, you
> >  > > appear to be SOL)
> >  > >
> >  > > 7) This is the "detail" referred to earlier? Seems this one
> >  > is subject
> >  > > to the routing
> >  > > requirements reported later. Might be easier simply to
> >  > introduce that
> >  > > limitation here.
> >  > >
> >  > > 8) Is the expectation that the quality of information
> >  > obtained from a
> >  > > control plane trace and a
> >  > > forwarding plane be comparable? Can you clarify what 
> you mean by a
> >  > > control plane trace? I can see augmenting
> >  > > signalling protocols to faciliate this (e.g. LSP query
> >  > I-D), but that
> >  > > does not fit into this discussion.
> >  > >
> >  > > 10) This seems to be overlapping with a solution framework.
> >  > >
> >  > > 11) Any intention of aligning TTL models with the
> >  > terminology emerging
> >  > > elsewhere (pipe or uniform
> >  > > models?).
> >  > >
> >  > > 13) Don't quite grok the motivation. I plead ignorance ;-)
> >  > >
> >  > > The protocol requirements section is actually rather
> >  > prescriptive. There
> >  > > are specific requirements
> >  > > in there that end up as either application limitations or
> >  > part of an
> >  > > applicability statement (e.g. routing
> >  > > requirements) or design guidelines. The rest shouldn't be
> >  > in this document.
> >  > >
> >  > > IMHO at the present time the document is not quite ready
> >  > for "prime time".
> >  > >
> >  > > my two cents
> >  > > Dave
> >  > >
> >  >
> >  >
> >  > --
> >  > Loa Andersson
> >  > Chief Architect,
> >  > Utfors Research, Architecture and Future Lab (URAX)
> >  > Utfors AB
> >  > Råsundavägen 12
> >  > Box 525, 169 29 Solna
> >  > Office          +46 8 5270 2000
> >  > Office direct   +46 8 5270 5038
> >  > Mobile          +46 70 848 5038
> >  > Email           [email-masked]
> >  > WWW             www.utfors.se
> >  >
> >  >
> >  >
> > 
> 
> 
> -- 
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> Råsundavägen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           [email-masked]
> WWW             www.utfors.se
> 
> 

------_=_NextPart_001_01C1BAFE.6C159DA0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Loa:</FONT>
</P>

<P><FONT SIZE=3D2>Sometimes a group has a sufficiently inclusive =
charter in advance of specific proposals, sometimes specific proposals =
have sufficient utility to justify a charter change. OK...we agree on =
process</FONT></P>

<P><FONT SIZE=3D2>However, none of this discussion of process is doing =
anything to resolve my original technical concerns with the content of =
the draft. As elevation to WG draft status implies that some portion of =
the content has a reasonable probability of making it's way into an =
RFC, and the document may/will be referenced as a &quot;work in =
progress&quot; and granted some degree of influence, I'd like to focus =
more on those issues. esp when I've voiced concerns or sought =
clarifications on the majority of the requirements =
presented.</FONT></P>

<P><FONT SIZE=3D2>later</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Loa Andersson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, February 21, 2002 12:21 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Allan, David [CAR:NS00:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Ron Bonica; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; if you change &quot;appeared in&quot; to =
&quot;is within the scope of&quot; I agree.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; /Loa</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David Allan wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Loa:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I thought the first criteria (somthing we =
should do) was met when </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; somthing appeared in a WG charter and =
milestones ;-).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; As for the second, I'll agree to disagree. =
I've provided my </FONT>
<BR><FONT SIZE=3D2>&gt; suggestions </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; as to changes that should be made before =
IMO the document is a good </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; enough starting point. Others should offer =
their opinions.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; cheers</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; From: Loa Andersson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Sent: Wednesday, February 20, =
2002 11:31 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; To: Allan, David =
[CAR:NS00:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Cc: Ron Bonica; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Subject: Re: =
draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; a more IETF (possibly ccamp) =
philosophical question. What do</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; we do when we accept a document =
as a WG document. In my mind</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; it is a step taken when we =
realise that this is something that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; the WG group should do and the =
document is a good enough starting</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; point for doing this =
work.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Even if I agreed with all of =
Dave's comments it is my 2 c's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; that both the criteria above =
are met and that we should progress</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; the doc as a WG =
document.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; There will be a couple of =
iterations where the comments will be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; addressed and possibly be =
worked into the final req doc.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; /Loa</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; David Allan wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; Ron:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; I have a number of =
comments on the draft.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; Clarifications:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; The discussion of =
traceroute in section 5, 2nd para. </FONT>
<BR><FONT SIZE=3D2>&gt; Are you really</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; saying that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; traceroute only reveals =
the current layer/level and reveals</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; no knowledge</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; of nesting of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; lower layer/level tunnels =
or the relationship of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; current level to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; higher levels?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; It doesn't clearly come =
out.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; Comments on application =
requirements (numbers correspond to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; requirement):</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 1) I think a broader =
discussion of some of the security</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; issues needs to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; be raised. First by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; whatever means a trace =
request needs to be able to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; instantiated at a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; tunnel end</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; point. Second, as a result =
of initiating a trace, any </FONT>
<BR><FONT SIZE=3D2>&gt; node in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; network may be required =
to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; generate a response to the =
tracing application. Therefore</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; the tracing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; application is =
required</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; to promiscuously accept =
responses. A mechanism is required to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; authoritatively =
associate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; responses with requests =
and discard spurious messages.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Further such a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; mechanism should not =
be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; able to be leveraged for =
denial of service attacks (e.g.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; spurious trace</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; responses forcing =
lots</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; of cryptography, defense =
against replay attacks etc.).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 2) Any interface? I think =
any routable interface (mind you</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; this is where</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; separating out =
routing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; limitations into a =
separate section reduces the clarity). I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; think there</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; is a separate stipulation =
that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; there is no representation =
as to the number of protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; exchanges it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; takes to perform a =
trace</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; (other than permitting the =
trace originator to perform some</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; measure of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; flow control by the =
protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; being designed to bound =
the number of responses a </FONT>
<BR><FONT SIZE=3D2>&gt; transaction will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; elicit; ideally 1 to 1, =
this also</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; has DOS implications =
similar to ICMP smurf type </FONT>
<BR><FONT SIZE=3D2>&gt; attacks whereby the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; responses to a =
single</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; message can be unbounded). =
You actually bring this up</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; obliquely in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; protocol requirements, but =
IMHO it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; should be expressed less =
prescriptively.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 3) Is third party really a =
special case? Can I not </FONT>
<BR><FONT SIZE=3D2>&gt; instantiate an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; in-line trace using =
management</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; protocols etc. and pull =
back the results.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 4) the application =
&quot;displays&quot; tunnels (editorial nit)? are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; we really</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; discussing how much =
information the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; application collects and =
reports on. The alternative</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; interpretation is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; that the same amount =
of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; information is always =
collected, and somehow filtered</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; during presentation.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 4) When you say =
&quot;single hop&quot; or &quot;in detail&quot;, are you really</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; saying &quot;this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; layer&quot; or =
&quot;constituent</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; lower layer =
components&quot;? It could use clarification.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 5) Are you sure the =
collected information includes round</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; trip delay?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; It's not clear to =
me</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; whether this is some =
pre-existing chunk of information </FONT>
<BR><FONT SIZE=3D2>&gt; just lying</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; around, or where the =
trace</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; transaction is expected to =
measure RTT on the fly for </FONT>
<BR><FONT SIZE=3D2>&gt; every hop and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; provide current =
view.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 6) I think are more =
accurate statement is support any tunneling</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; technology that is used =
between</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; IP endpoints. Otherwise =
this is not a sustainable </FONT>
<BR><FONT SIZE=3D2>&gt; requirement. I am</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; concerned, for example, =
that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; any intervening L2 or =
layer 2 and a half skewers the </FONT>
<BR><FONT SIZE=3D2>&gt; model. (e.g..</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; IP/PPP/L2TP, you can =
only</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; reveal the PPP end points, =
or if you look at L2TP tunnel</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; switches, you</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; appear to be SOL)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 7) This is the =
&quot;detail&quot; referred to earlier? Seems this one</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; is subject</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; to the routing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; requirements reported =
later. Might be easier simply to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; introduce that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; limitation here.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 8) Is the expectation that =
the quality of information</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; obtained from a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; control plane trace and =
a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; forwarding plane be =
comparable? Can you clarify what </FONT>
<BR><FONT SIZE=3D2>&gt; you mean by a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; control plane trace? I can =
see augmenting</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; signalling protocols to =
faciliate this (e.g. LSP query</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; I-D), but that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; does not fit into this =
discussion.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 10) This seems to be =
overlapping with a solution framework.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 11) Any intention of =
aligning TTL models with the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; terminology emerging</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; elsewhere (pipe or =
uniform</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; models?).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; 13) Don't quite grok the =
motivation. I plead ignorance ;-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; The protocol requirements =
section is actually rather</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; prescriptive. There</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; are specific =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; in there that end up as =
either application limitations or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; part of an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; applicability statement =
(e.g. routing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; requirements) or design =
guidelines. The rest shouldn't be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; in this document.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; IMHO at the present time =
the document is not quite ready</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; for &quot;prime =
time&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; my two cents</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Loa Andersson</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Chief Architect,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Utfors Research, Architecture =
and Future Lab (URAX)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Utfors AB</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; R=E5sundav=E4gen 12</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Box 525, 169 29 Solna</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; =
Office&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +46 8 5270 =
2000</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Office direct&nbsp;&nbsp; +46 8 =
5270 5038</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; =
Mobile&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +46 70 848 =
5038</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; =
Email&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; =
WWW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; www.utfors.se</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Loa Andersson</FONT>
<BR><FONT SIZE=3D2>&gt; Chief Architect,</FONT>
<BR><FONT SIZE=3D2>&gt; Utfors Research, Architecture and Future Lab =
(URAX)</FONT>
<BR><FONT SIZE=3D2>&gt; Utfors AB</FONT>
<BR><FONT SIZE=3D2>&gt; R=E5sundav=E4gen 12</FONT>
<BR><FONT SIZE=3D2>&gt; Box 525, 169 29 Solna</FONT>
<BR><FONT SIZE=3D2>&gt; =
Office&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +46 8 5270 =
2000</FONT>
<BR><FONT SIZE=3D2>&gt; Office direct&nbsp;&nbsp; +46 8 5270 =
5038</FONT>
<BR><FONT SIZE=3D2>&gt; =
Mobile&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +46 70 848 =
5038</FONT>
<BR><FONT SIZE=3D2>&gt; =
Email&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; =
WWW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; www.utfors.se</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BAFE.6C159DA0--

Delivery-date: Thu, 21 Feb 2002 09:23:14 -0800
From: Randy Bush <[email-masked]>
To: Shahram Davari <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 09:22:33 -0800

> I don't see path-trace being mentioned in the charter.

try the first one

    - Define signalling protocols and measurement protocols such that they
      support multiple physical path and tunnel technologies

also

    - and draft-bonica-tunneltrace-01.txt to this section. 

may be relevant

but if you think it needs more specific text in the charter, then suggest
the text and the ADs, who seem to think this is within charter, can have
the charter changed.

randy

Delivery-date: Thu, 21 Feb 2002 09:21:38 -0800
Date: Thu, 21 Feb 2002 18:20:49 +0100
From: Loa Andersson <[email-masked]>
To: David Allan <[email-masked]>
CC: Ron Bonica <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

Dave,

if you change "appeared in" to "is within the scope of" I agree.

/Loa

David Allan wrote:

> Loa:
> 
> I thought the first criteria (somthing we should do) was met when 
> somthing appeared in a WG charter and milestones ;-).
> 
> As for the second, I'll agree to disagree. I've provided my suggestions 
> as to changes that should be made before IMO the document is a good 
> enough starting point. Others should offer their opinions.
> 
> cheers
> Dave
> 
>  > -----Original Message-----
>  > From: Loa Andersson [mailto:[email-masked]]
>  > Sent: Wednesday, February 20, 2002 11:31 AM
>  > To: Allan, David [CAR:NS00:EXCH]
>  > Cc: Ron Bonica; [email-masked]
>  > Subject: Re: draft-bonica-tunneltrace-02
>  >
>  >
>  > All,
>  >
>  > a more IETF (possibly ccamp) philosophical question. What do
>  > we do when we accept a document as a WG document. In my mind
>  > it is a step taken when we realise that this is something that
>  > the WG group should do and the document is a good enough starting
>  > point for doing this work.
>  >
>  > Even if I agreed with all of Dave's comments it is my 2 c's
>  > that both the criteria above are met and that we should progress
>  > the doc as a WG document.
>  >
>  > There will be a couple of iterations where the comments will be
>  > addressed and possibly be worked into the final req doc.
>  >
>  >
>  > /Loa
>  >
>  > David Allan wrote:
>  >
>  > > Ron:
>  > >
>  > > I have a number of comments on the draft.
>  > >
>  > > Clarifications:
>  > >
>  > > The discussion of traceroute in section 5, 2nd para. Are you really
>  > > saying that
>  > > traceroute only reveals the current layer/level and reveals
>  > no knowledge
>  > > of nesting of
>  > > lower layer/level tunnels or the relationship of the
>  > current level to
>  > > higher levels?
>  > > It doesn't clearly come out.
>  > >
>  > > Comments on application requirements (numbers correspond to the
>  > > requirement):
>  > >
>  > > 1) I think a broader discussion of some of the security
>  > issues needs to
>  > > be raised. First by
>  > > whatever means a trace request needs to be able to be
>  > instantiated at a
>  > > tunnel end
>  > > point. Second, as a result of initiating a trace, any node in the
>  > > network may be required to
>  > > generate a response to the tracing application. Therefore
>  > the tracing
>  > > application is required
>  > > to promiscuously accept responses. A mechanism is required to
>  > > authoritatively associate
>  > > responses with requests and discard spurious messages.
>  > Further such a
>  > > mechanism should not be
>  > > able to be leveraged for denial of service attacks (e.g.
>  > spurious trace
>  > > responses forcing lots
>  > > of cryptography, defense against replay attacks etc.).
>  > >
>  > > 2) Any interface? I think any routable interface (mind you
>  > this is where
>  > > separating out routing
>  > > limitations into a separate section reduces the clarity). I
>  > think there
>  > > is a separate stipulation that
>  > > there is no representation as to the number of protocol
>  > exchanges it
>  > > takes to perform a trace
>  > > (other than permitting the trace originator to perform some
>  > measure of
>  > > flow control by the protocol
>  > > being designed to bound the number of responses a transaction will
>  > > elicit; ideally 1 to 1, this also
>  > > has DOS implications similar to ICMP smurf type attacks whereby the
>  > > responses to a single
>  > > message can be unbounded). You actually bring this up
>  > obliquely in the
>  > > protocol requirements, but IMHO it
>  > > should be expressed less prescriptively.
>  > >
>  > > 3) Is third party really a special case? Can I not instantiate an
>  > > in-line trace using management
>  > > protocols etc. and pull back the results.
>  > >
>  > > 4) the application "displays" tunnels (editorial nit)? are
>  > we really
>  > > discussing how much information the
>  > > application collects and reports on. The alternative
>  > interpretation is
>  > > that the same amount of
>  > > information is always collected, and somehow filtered
>  > during presentation.
>  > >
>  > > 4) When you say "single hop" or "in detail", are you really
>  > saying "this
>  > > layer" or "constituent
>  > > lower layer components"? It could use clarification.
>  > >
>  > > 5) Are you sure the collected information includes round
>  > trip delay?
>  > > It's not clear to me
>  > > whether this is some pre-existing chunk of information just lying
>  > > around, or where the trace
>  > > transaction is expected to measure RTT on the fly for every hop and
>  > > provide current view.
>  > >
>  > > 6) I think are more accurate statement is support any tunneling
>  > > technology that is used between
>  > > IP endpoints. Otherwise this is not a sustainable requirement. I am
>  > > concerned, for example, that
>  > > any intervening L2 or layer 2 and a half skewers the model. (e.g..
>  > > IP/PPP/L2TP, you can only
>  > > reveal the PPP end points, or if you look at L2TP tunnel
>  > switches, you
>  > > appear to be SOL)
>  > >
>  > > 7) This is the "detail" referred to earlier? Seems this one
>  > is subject
>  > > to the routing
>  > > requirements reported later. Might be easier simply to
>  > introduce that
>  > > limitation here.
>  > >
>  > > 8) Is the expectation that the quality of information
>  > obtained from a
>  > > control plane trace and a
>  > > forwarding plane be comparable? Can you clarify what you mean by a
>  > > control plane trace? I can see augmenting
>  > > signalling protocols to faciliate this (e.g. LSP query
>  > I-D), but that
>  > > does not fit into this discussion.
>  > >
>  > > 10) This seems to be overlapping with a solution framework.
>  > >
>  > > 11) Any intention of aligning TTL models with the
>  > terminology emerging
>  > > elsewhere (pipe or uniform
>  > > models?).
>  > >
>  > > 13) Don't quite grok the motivation. I plead ignorance ;-)
>  > >
>  > > The protocol requirements section is actually rather
>  > prescriptive. There
>  > > are specific requirements
>  > > in there that end up as either application limitations or
>  > part of an
>  > > applicability statement (e.g. routing
>  > > requirements) or design guidelines. The rest shouldn't be
>  > in this document.
>  > >
>  > > IMHO at the present time the document is not quite ready
>  > for "prime time".
>  > >
>  > > my two cents
>  > > Dave
>  > >
>  >
>  >
>  > --
>  > Loa Andersson
>  > Chief Architect,
>  > Utfors Research, Architecture and Future Lab (URAX)
>  > Utfors AB
>  > Råsundavägen 12
>  > Box 525, 169 29 Solna
>  > Office          +46 8 5270 2000
>  > Office direct   +46 8 5270 5038
>  > Mobile          +46 70 848 5038
>  > Email           [email-masked]
>  > WWW             www.utfors.se
>  >
>  >
>  >
> 

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

Delivery-date: Thu, 21 Feb 2002 09:15:13 -0800
From: Shahram Davari <[email-masked]>
To: Shahram Davari <[email-masked]>, "'Ron Bonica'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 09:14:28 -0800

Hi,

Also, don't you think backward compatibility is a requirement?

-Shahram

> -----Original Message-----
> From: Shahram Davari 
> Sent: Thursday, February 21, 2002 12:03 PM
> To: 'Ron Bonica'; [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> Hi Ron,
> 
> 
> > -----Original Message-----
> > From: Ron Bonica [mailto:[email-masked]]
> > Sent: Thursday, February 21, 2002 11:34 AM
> > To: Shahram Davari; [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02
> > 
> > 
> > Sharam,
> > 
> > Section 7 of this document enumerates a some minimal protocol 
> > requirements.
> > Specifically, it states that:
> > 
> > o a traceResponse will carry information regarding a section 
> > of the traced
> > path
> 
> Why not information about the whole path? Is it becasue GTTP 
> can't do it?
> 
> > o a traceProbe will elicit a traceResponse
> 
> Why not a series of trace responses? Anything fundamentally 
> wrong with it or is it becasue GTTP can't do it?
> 
> > o UDP will carry traceProbes and traceResponses
> 
> Why not TCP or even GTTP over IP?
> 
> > o the protocol will be stateless
> > o each device within the trace path need not maintain an IP 
> > route back to
> > the device that hosts that tracing application
> 
> Why? Why return path from head of the path is not enough?
> 
> > 
> 
> > Although these broad brushstrokes do not specify a protocol, 
> > they provide
> > direction to protocol developers.
> 
> To develop GTTP!
> 
>  We are looking for an IP 
> > based protocol
> > that can probe network elements about whatever tunnels they 
> maintain,
> > regardless of the tunnel type. We are not looking to extend 
> > the capabilities
> > of any particular tunneling technology.
> 
> I know. But the protocol restrictions that are mentioned must 
> be justified.
> 
> -Shahram
> > 
> >                                       Ron
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Shahram Davari
> > > Sent: Tuesday, February 19, 2002 5:29 PM
> > > To: [email-masked]
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > > Hi,
> > >
> > > Although this document is a generic requirement for tunnel
> > > tracing, I find many protocol specific requirements that are not
> > > actually a requirement, rather they are suggesting a 
> > specific solution.
> > >
> > > For example:
> > >
> > > "The protocol elicits a series of traceResponse messages."
> > > "Each traceResponse message represents a hop that connects the
> > > head-end of the traced path to the tail-end of the traced path"
> > > "Each traceProbe message elicits exactly one 
> traceResponse message."
> > > "UDP carries traceProbe and traceResponse messages to their 
> > destinations."
> > >
> > >
> > > Thanks,
> > > -Shahram
> > >
> > >
> > 
> 

Delivery-date: Thu, 21 Feb 2002 09:04:16 -0800
From: Shahram Davari <[email-masked]>
To: "'Ron Bonica'" <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 09:03:24 -0800

Hi Ron,

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 11:34 AM
> To: Shahram Davari; [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> Sharam,
> 
> Section 7 of this document enumerates a some minimal protocol 
> requirements.
> Specifically, it states that:
> 
> o a traceResponse will carry information regarding a section 
> of the traced
> path

Why not information about the whole path? Is it becasue GTTP can't do it?

> o a traceProbe will elicit a traceResponse

Why not a series of trace responses? Anything fundamentally wrong with it or is it becasue GTTP can't do it?

> o UDP will carry traceProbes and traceResponses

Why not TCP or even GTTP over IP?

> o the protocol will be stateless
> o each device within the trace path need not maintain an IP 
> route back to
> the device that hosts that tracing application

Why? Why return path from head of the path is not enough?

> 

> Although these broad brushstrokes do not specify a protocol, 
> they provide
> direction to protocol developers.

To develop GTTP!

 We are looking for an IP 
> based protocol
> that can probe network elements about whatever tunnels they maintain,
> regardless of the tunnel type. We are not looking to extend 
> the capabilities
> of any particular tunneling technology.

I know. But the protocol restrictions that are mentioned must be justified.

-Shahram
> 
>                                       Ron
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Shahram Davari
> > Sent: Tuesday, February 19, 2002 5:29 PM
> > To: [email-masked]
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> > Hi,
> >
> > Although this document is a generic requirement for tunnel
> > tracing, I find many protocol specific requirements that are not
> > actually a requirement, rather they are suggesting a 
> specific solution.
> >
> > For example:
> >
> > "The protocol elicits a series of traceResponse messages."
> > "Each traceResponse message represents a hop that connects the
> > head-end of the traced path to the tail-end of the traced path"
> > "Each traceProbe message elicits exactly one traceResponse message."
> > "UDP carries traceProbe and traceResponse messages to their 
> destinations."
> >
> >
> > Thanks,
> > -Shahram
> >
> >
> 

Delivery-date: Thu, 21 Feb 2002 08:43:49 -0800
Date: Thu, 21 Feb 2002 11:34:13 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
To: Shahram Davari <[email-masked]>, [email-masked]

Sharam,

Section 7 of this document enumerates a some minimal protocol requirements.
Specifically, it states that:

o a traceResponse will carry information regarding a section of the traced
path
o a traceProbe will elicit a traceResponse
o UDP will carry traceProbes and traceResponses
o the protocol will be stateless
o each device within the trace path need not maintain an IP route back to
the device that hosts that tracing application

Although these broad brushstrokes do not specify a protocol, they provide
direction to protocol developers. We are looking for an IP based protocol
that can probe network elements about whatever tunnels they maintain,
regardless of the tunnel type. We are not looking to extend the capabilities
of any particular tunneling technology.

                                      Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Shahram Davari
> Sent: Tuesday, February 19, 2002 5:29 PM
> To: [email-masked]
> Subject: RE: draft-bonica-tunneltrace-02
>
>
> Hi,
>
> Although this document is a generic requirement for tunnel
> tracing, I find many protocol specific requirements that are not
> actually a requirement, rather they are suggesting a specific solution.
>
> For example:
>
> "The protocol elicits a series of traceResponse messages."
> "Each traceResponse message represents a hop that connects the
> head-end of the traced path to the tail-end of the traced path"
> "Each traceProbe message elicits exactly one traceResponse message."
> "UDP carries traceProbe and traceResponse messages to their destinations."
>
>
> Thanks,
> -Shahram
>
>

Delivery-date: Thu, 21 Feb 2002 08:43:46 -0800
From: Shahram Davari <[email-masked]>
To: "'Scott  Bradner'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Thu, 21 Feb 2002 08:39:31 -0800

Hi,

I don't see path-trace being mentioned in the charter.

Yours,
-Shahram

> -----Original Message-----
> From: Scott Bradner [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 6:40 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02
> 
> 
> > a more IETF (possibly ccamp) philosophical question. What do
> > we do when we accept a document as a WG document. In my mind
> > it is a step taken when we realise that this is something that
> > the WG group should do and the document is a good enough starting
> > point for doing this work.
> 
> that plus meeting a task in the charter - if there is a feeling that
> a WG should be working on some topic that is not in the charter then
> a proposal to add to the charter should be presented to the 
> ADs who, if
> they agree, will take the proposal to the IESG and IAB.
> 
> Scott
> 

Envelope-to: [email-masked]
Delivery-date: Wed, 20 Feb 2002 15:41:55 -0800
Date: Wed, 20 Feb 2002 18:39:55 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-bonica-tunneltrace-02
Cc: [email-masked], [email-masked]

> a more IETF (possibly ccamp) philosophical question. What do
> we do when we accept a document as a WG document. In my mind
> it is a step taken when we realise that this is something that
> the WG group should do and the document is a good enough starting
> point for doing this work.

that plus meeting a task in the charter - if there is a feeling that
a WG should be working on some topic that is not in the charter then
a proposal to add to the charter should be presented to the ADs who, if
they agree, will take the proposal to the IESG and IAB.

Scott

Delivery-date: Wed, 20 Feb 2002 14:28:29 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Loa Andersson <[email-masked]>, David Allan <[email-masked]>
Cc: Ron Bonica <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 20 Feb 2002 23:28:12 +0100

In general (i.e. not specific to this document)

- When the document is about a work item and deliverable that
  is in the current WG charter, then the WG chairs try to get
  consensus on which document or documents are to be used for
  delivering on that work item
- When the document addresses work that is not in the current
  WG charter, then the WG chairs can still try to figure out
  if the WG has consensus that such work SHOULD be done by
  the WG, but the WG chairs will need to get in discussion 
  with ADs to try and arrange for charter update.
- ADs will be very reluctant if the WG has not performed well
  according to current charter and milestones.
- When ADs accept the new work as reasonable, they will have
  to defend a charter change to IESG and IAB, and if they
  all agree, then WG charter gets changed, and we're back at
  step 1 above.

Hope thsi explains the process (for those who did not already know)

Bert

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 5:31 PM
> To: David Allan
> Cc: Ron Bonica; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02
> 
> 
> All,
> 
> a more IETF (possibly ccamp) philosophical question. What do
> we do when we accept a document as a WG document. In my mind
> it is a step taken when we realise that this is something that
> the WG group should do and the document is a good enough starting
> point for doing this work.
> 
> Even if I agreed with all of Dave's comments it is my 2 c's
> that both the criteria above are met and that we should progress
> the doc as a WG document.
> 
> There will be a couple of iterations where the comments will be
> addressed and possibly be worked into the final req doc.
> 
> 
> /Loa
> 
> David Allan wrote:
> 
> > Ron:
> > 
> > I have a number of comments on the draft.
> > 
> > Clarifications:
> > 
> > The discussion of traceroute in section 5, 2nd para. Are you really 
> > saying that
> > traceroute only reveals the current layer/level and reveals 
> no knowledge 
> > of nesting of
> > lower layer/level tunnels or the relationship of the 
> current level to 
> > higher levels?
> > It doesn't clearly come out.
> > 
> > Comments on application requirements (numbers correspond to the 
> > requirement):
> > 
> > 1) I think a broader discussion of some of the security 
> issues needs to 
> > be raised. First by
> > whatever means a trace request needs to be able to be 
> instantiated at a 
> > tunnel end
> > point. Second, as a result of initiating a trace, any node in the 
> > network may be required to
> > generate a response to the tracing application. Therefore 
> the tracing 
> > application is required
> > to promiscuously accept responses. A mechanism is required to 
> > authoritatively associate
> > responses with requests and discard spurious messages. 
> Further such a 
> > mechanism should not be
> > able to be leveraged for denial of service attacks (e.g. 
> spurious trace 
> > responses forcing lots
> > of cryptography, defense against replay attacks etc.).
> > 
> > 2) Any interface? I think any routable interface (mind you 
> this is where 
> > separating out routing
> > limitations into a separate section reduces the clarity). I 
> think there 
> > is a separate stipulation that
> > there is no representation as to the number of protocol 
> exchanges it 
> > takes to perform a trace
> > (other than permitting the trace originator to perform some 
> measure of 
> > flow control by the protocol
> > being designed to bound the number of responses a transaction will 
> > elicit; ideally 1 to 1, this also
> > has DOS implications similar to ICMP smurf type attacks whereby the 
> > responses to a single
> > message can be unbounded). You actually bring this up 
> obliquely in the 
> > protocol requirements, but IMHO it
> > should be expressed less prescriptively.
> > 
> > 3) Is third party really a special case? Can I not instantiate an 
> > in-line trace using management
> > protocols etc. and pull back the results.
> > 
> > 4) the application "displays" tunnels (editorial nit)? are 
> we really 
> > discussing how much information the
> > application collects and reports on. The alternative 
> interpretation is 
> > that the same amount of
> > information is always collected, and somehow filtered 
> during presentation.
> > 
> > 4) When you say "single hop" or "in detail", are you really 
> saying "this 
> > layer" or "constituent
> > lower layer components"? It could use clarification.
> > 
> > 5) Are you sure the collected information includes round 
> trip delay? 
> > It's not clear to me
> > whether this is some pre-existing chunk of information just lying 
> > around, or where the trace
> > transaction is expected to measure RTT on the fly for every hop and 
> > provide current view.
> > 
> > 6) I think are more accurate statement is support any tunneling 
> > technology that is used between
> > IP endpoints. Otherwise this is not a sustainable requirement. I am 
> > concerned, for example, that
> > any intervening L2 or layer 2 and a half skewers the model. (e.g.. 
> > IP/PPP/L2TP, you can only
> > reveal the PPP end points, or if you look at L2TP tunnel 
> switches, you 
> > appear to be SOL)
> > 
> > 7) This is the "detail" referred to earlier? Seems this one 
> is subject 
> > to the routing
> > requirements reported later. Might be easier simply to 
> introduce that 
> > limitation here.
> > 
> > 8) Is the expectation that the quality of information 
> obtained from a 
> > control plane trace and a
> > forwarding plane be comparable? Can you clarify what you mean by a 
> > control plane trace? I can see augmenting
> > signalling protocols to faciliate this (e.g. LSP query 
> I-D), but that 
> > does not fit into this discussion.
> > 
> > 10) This seems to be overlapping with a solution framework.
> > 
> > 11) Any intention of aligning TTL models with the 
> terminology emerging 
> > elsewhere (pipe or uniform
> > models?).
> > 
> > 13) Don't quite grok the motivation. I plead ignorance ;-)
> > 
> > The protocol requirements section is actually rather 
> prescriptive. There 
> > are specific requirements
> > in there that end up as either application limitations or 
> part of an 
> > applicability statement (e.g. routing
> > requirements) or design guidelines. The rest shouldn't be 
> in this document.
> > 
> > IMHO at the present time the document is not quite ready 
> for "prime time".
> > 
> > my two cents
> > Dave
> > 
> 
> 
> -- 
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> Råsundavägen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           [email-masked]
> WWW             www.utfors.se
> 
> 

Delivery-date: Wed, 20 Feb 2002 14:27:42 -0800
From: Randy Bush <[email-masked]>
To: "David Allan" <[email-masked]>
Cc: "Cuevas, Enrique G, ALASO" <[email-masked]>, [email-masked], Ron Bonica <[email-masked]>, Loa Andersson <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 20 Feb 2002 14:27:13 -0800

> I don't think closeness to CCAMPs heart is the issue. Given the current
> discussion, the WG is working on the document. Only question is when it
> hits escape velocity. I don't think there is a suggestion of never....

escape volicity comes after wg last call.

randy

Delivery-date: Wed, 20 Feb 2002 14:24:24 -0800
From: "David Allan"<[email-masked]>
To: Randy Bush <[email-masked]>, "Cuevas, Enrique G, ALASO" <[email-masked]>
Cc: [email-masked], Ron Bonica <[email-masked]>, Loa Andersson <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 20 Feb 2002 17:23:40 -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_01C1BA5D.3FA753E0
Content-Type: text/plain;
	charset="iso-8859-1"

Randy:

I don't think closeness to CCAMPs heart is the issue. Given the current
discussion, the WG is working on the document. Only question is when it hits
escape velocity. I don't think there is a suggestion of never....

rgds
Dave

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 5:10 PM
> To: Cuevas, Enrique G, ALASO
> Cc: [email-masked]; Ron Bonica; Loa Andersson; Allan, David
> [CAR:NS00:EXCH]
> Subject: RE: draft-bonica-tunneltrace-02
> 
> 
> > Why should a document be approved as a WG doc. if there are so many
> > conflicting issues?
> 
> so the wg can work on the document,  the question is not whether the
> document is perfect.  the question is whether it is well within the
> bounds of the charter.  in this case, this document seems nearer the
> center of the ccamp charter then most of the other documents i have
> seen here.
> 
> randy (hatless)
> 
> 

------_=_NextPart_001_01C1BA5D.3FA753E0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Randy:</FONT>
</P>

<P><FONT SIZE=3D2>I don't think closeness to CCAMPs heart is the issue. =
Given the current discussion, the WG is working on the document. Only =
question is when it hits escape velocity. I don't think there is a =
suggestion of never....</FONT></P>

<P><FONT SIZE=3D2>rgds</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Randy Bush [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, February 20, 2002 5:10 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Cuevas, Enrique G, ALASO</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]; Ron Bonica; Loa =
Andersson; Allan, David</FONT>
<BR><FONT SIZE=3D2>&gt; [CAR:NS00:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Why should a document be approved as a WG =
doc. if there are so many</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; conflicting issues?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; so the wg can work on the document,&nbsp; the =
question is not whether the</FONT>
<BR><FONT SIZE=3D2>&gt; document is perfect.&nbsp; the question is =
whether it is well within the</FONT>
<BR><FONT SIZE=3D2>&gt; bounds of the charter.&nbsp; in this case, this =
document seems nearer the</FONT>
<BR><FONT SIZE=3D2>&gt; center of the ccamp charter then most of the =
other documents i have</FONT>
<BR><FONT SIZE=3D2>&gt; seen here.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; randy (hatless)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BA5D.3FA753E0--

Delivery-date: Wed, 20 Feb 2002 14:10:58 -0800
From: Randy Bush <[email-masked]>
To: "Cuevas, Enrique G, ALASO" <[email-masked]>
Cc: <[email-masked]>, "Ron Bonica" <[email-masked]>, "Loa Andersson" <[email-masked]>, "David Allan" <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 20 Feb 2002 14:10:05 -0800

> Why should a document be approved as a WG doc. if there are so many
> conflicting issues?

so the wg can work on the document,  the question is not whether the
document is perfect.  the question is whether it is well within the
bounds of the charter.  in this case, this document seems nearer the
center of the ccamp charter then most of the other documents i have
seen here.

randy (hatless)

Delivery-date: Wed, 20 Feb 2002 13:42:00 -0800
content-class: urn:content-classes:message
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 20 Feb 2002 16:40:30 -0500
From: "Cuevas, Enrique G, ALASO" <[email-masked]>
To: <[email-masked]>
Cc: "Ron Bonica" <[email-masked]>, "Loa Andersson" <[email-masked]>, "David Allan" <[email-masked]>

All,
David has raised many good points that don't seem cosmetic but rather =
more fundamental. Why should a document be approved as a WG doc. if =
there are so many conflicting issues?

Enrique Cuevas
AT&T Labs
_______________
[email-masked]
Tel. (732)-420-3252

>-----Original Message-----
>From: Loa Andersson [mailto:[email-masked]]
>Sent: Wednesday, February 20, 2002 11:31 AM
>To: David Allan
>Cc: Ron Bonica; [email-masked]
>Subject: Re: draft-bonica-tunneltrace-02
>
>
>All,
>
>a more IETF (possibly ccamp) philosophical question. What do
>we do when we accept a document as a WG document. In my mind
>it is a step taken when we realise that this is something that
>the WG group should do and the document is a good enough starting
>point for doing this work.
>
>Even if I agreed with all of Dave's comments it is my 2 c's
>that both the criteria above are met and that we should progress
>the doc as a WG document.
>
>There will be a couple of iterations where the comments will be
>addressed and possibly be worked into the final req doc.
>
>
>/Loa
>
>David Allan wrote:
>
>> Ron:
>>=20
>> I have a number of comments on the draft.
>>=20
>> Clarifications:
>>=20
>> The discussion of traceroute in section 5, 2nd para. Are you really=20
>> saying that
>> traceroute only reveals the current layer/level and reveals=20
>no knowledge=20
>> of nesting of
>> lower layer/level tunnels or the relationship of the current=20
>level to=20
>> higher levels?
>> It doesn't clearly come out.
>>=20
>> Comments on application requirements (numbers correspond to the=20
>> requirement):
>>=20
>> 1) I think a broader discussion of some of the security=20
>issues needs to=20
>> be raised. First by
>> whatever means a trace request needs to be able to be=20
>instantiated at a=20
>> tunnel end
>> point. Second, as a result of initiating a trace, any node in the=20
>> network may be required to
>> generate a response to the tracing application. Therefore=20
>the tracing=20
>> application is required
>> to promiscuously accept responses. A mechanism is required to=20
>> authoritatively associate
>> responses with requests and discard spurious messages.=20
>Further such a=20
>> mechanism should not be
>> able to be leveraged for denial of service attacks (e.g.=20
>spurious trace=20
>> responses forcing lots
>> of cryptography, defense against replay attacks etc.).
>>=20
>> 2) Any interface? I think any routable interface (mind you=20
>this is where=20
>> separating out routing
>> limitations into a separate section reduces the clarity). I=20
>think there=20
>> is a separate stipulation that
>> there is no representation as to the number of protocol exchanges it=20
>> takes to perform a trace
>> (other than permitting the trace originator to perform some=20
>measure of=20
>> flow control by the protocol
>> being designed to bound the number of responses a transaction will=20
>> elicit; ideally 1 to 1, this also
>> has DOS implications similar to ICMP smurf type attacks whereby the=20
>> responses to a single
>> message can be unbounded). You actually bring this up=20
>obliquely in the=20
>> protocol requirements, but IMHO it
>> should be expressed less prescriptively.
>>=20
>> 3) Is third party really a special case? Can I not instantiate an=20
>> in-line trace using management
>> protocols etc. and pull back the results.
>>=20
>> 4) the application "displays" tunnels (editorial nit)? are we really=20
>> discussing how much information the
>> application collects and reports on. The alternative=20
>interpretation is=20
>> that the same amount of
>> information is always collected, and somehow filtered during=20
>presentation.
>>=20
>> 4) When you say "single hop" or "in detail", are you really=20
>saying "this=20
>> layer" or "constituent
>> lower layer components"? It could use clarification.
>>=20
>> 5) Are you sure the collected information includes round trip delay?=20
>> It's not clear to me
>> whether this is some pre-existing chunk of information just lying=20
>> around, or where the trace
>> transaction is expected to measure RTT on the fly for every hop and=20
>> provide current view.
>>=20
>> 6) I think are more accurate statement is support any tunneling=20
>> technology that is used between
>> IP endpoints. Otherwise this is not a sustainable requirement. I am=20
>> concerned, for example, that
>> any intervening L2 or layer 2 and a half skewers the model. (e.g..=20
>> IP/PPP/L2TP, you can only
>> reveal the PPP end points, or if you look at L2TP tunnel=20
>switches, you=20
>> appear to be SOL)
>>=20
>> 7) This is the "detail" referred to earlier? Seems this one=20
>is subject=20
>> to the routing
>> requirements reported later. Might be easier simply to=20
>introduce that=20
>> limitation here.
>>=20
>> 8) Is the expectation that the quality of information=20
>obtained from a=20
>> control plane trace and a
>> forwarding plane be comparable? Can you clarify what you mean by a=20
>> control plane trace? I can see augmenting
>> signalling protocols to faciliate this (e.g. LSP query I-D),=20
>but that=20
>> does not fit into this discussion.
>>=20
>> 10) This seems to be overlapping with a solution framework.
>>=20
>> 11) Any intention of aligning TTL models with the=20
>terminology emerging=20
>> elsewhere (pipe or uniform
>> models?).
>>=20
>> 13) Don't quite grok the motivation. I plead ignorance ;-)
>>=20
>> The protocol requirements section is actually rather=20
>prescriptive. There=20
>> are specific requirements
>> in there that end up as either application limitations or part of an=20
>> applicability statement (e.g. routing
>> requirements) or design guidelines. The rest shouldn't be in=20
>this document.
>>=20
>> IMHO at the present time the document is not quite ready for=20
>"prime time".
>>=20
>> my two cents
>> Dave
>>=20
>
>
>--=20
>Loa Andersson
>Chief Architect,
>Utfors Research, Architecture and Future Lab (URAX)
>Utfors AB
>R=E5sundav=E4gen 12
>Box 525, 169 29 Solna
>Office          +46 8 5270 2000
>Office direct   +46 8 5270 5038
>Mobile          +46 70 848 5038
>Email           [email-masked]
>WWW             www.utfors.se
>
>

Delivery-date: Wed, 20 Feb 2002 11:44:43 -0800
Date: Wed, 20 Feb 2002 14:43:28 -0500
To: "David Allan"<[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: re: draft-bonica-tunneltrace-02
Cc: Ron Bonica <[email-masked]>, [email-masked]

At 10:59 AM 2/20/2002 -0500, David Allan wrote:

>Ron:
>
>I have a number of comments on the draft.
>
>Clarifications:
>
>The discussion of traceroute in section 5, 2nd para. Are you really saying 
>that
>traceroute only reveals the current layer/level and reveals no knowledge 
>of nesting of
>lower layer/level tunnels or the relationship of the current level to 
>higher levels?
>It doesn't clearly come out.
>
>Comments on application requirements (numbers correspond to the requirement):
>
>1) I think a broader discussion of some of the security issues needs to be 
>raised. First by
>whatever means a trace request needs to be able to be instantiated at a 
>tunnel end
>point. Second, as a result of initiating a trace, any node in the network 
>may be required to
>generate a response to the tracing application. Therefore the tracing 
>application is required
>to promiscuously accept responses. A mechanism is required to 
>authoritatively associate
>responses with requests and discard spurious messages. Further such a 
>mechanism should not be
>able to be leveraged for denial of service attacks (e.g. spurious trace 
>responses forcing lots
>of cryptography, defense against replay attacks etc.).
>
>2) Any interface? I think any routable interface (mind you this is where 
>separating out routing
>limitations into a separate section reduces the clarity). I think there is 
>a separate stipulation that
>there is no representation as to the number of protocol exchanges it takes 
>to perform a trace
>(other than permitting the trace originator to perform some measure of 
>flow control by the protocol
>being designed to bound the number of responses a transaction will elicit; 
>ideally 1 to 1, this also
>has DOS implications similar to ICMP smurf type attacks whereby the 
>responses to a single
>message can be unbounded). You actually bring this up obliquely in the 
>protocol requirements, but IMHO it
>should be expressed less prescriptively.
>
>3) Is third party really a special case? Can I not instantiate an in-line 
>trace using management
>protocols etc. and pull back the results.

         You can certainly envision a proprietary (or standard) MIB
that could be crafted to configure and then activate the tunnel
trace operation (or many of them) remotely. Depending on how you have
your security configured, 3rd parties can be allowed to do this. I would
treat this as a special case only that special security measures need to be
taken to ensure that only the right 3rd party (or customer) has
access to the tools. Once authenticated, the operations should be the same
as if an operator was running the tool. An example of this in today's 
environment,
some companies offer VRF-aware ping MIBs for some of their customers
that they may also use themselves.

         --Tom

>4) the application "displays" tunnels (editorial nit)? are we really 
>discussing how much information the
>application collects and reports on. The alternative interpretation is 
>that the same amount of
>information is always collected, and somehow filtered during presentation.
>
>4) When you say "single hop" or "in detail", are you really saying "this 
>layer" or "constituent
>lower layer components"? It could use clarification.
>
>5) Are you sure the collected information includes round trip delay? It's 
>not clear to me
>whether this is some pre-existing chunk of information just lying around, 
>or where the trace
>transaction is expected to measure RTT on the fly for every hop and 
>provide current view.
>
>6) I think are more accurate statement is support any tunneling technology 
>that is used between
>IP endpoints. Otherwise this is not a sustainable requirement. I am 
>concerned, for example, that
>any intervening L2 or layer 2 and a half skewers the model. (e.g.. 
>IP/PPP/L2TP, you can only
>reveal the PPP end points, or if you look at L2TP tunnel switches, you 
>appear to be SOL)
>
>7) This is the "detail" referred to earlier? Seems this one is subject to 
>the routing
>requirements reported later. Might be easier simply to introduce that 
>limitation here.
>
>8) Is the expectation that the quality of information obtained from a 
>control plane trace and a
>forwarding plane be comparable? Can you clarify what you mean by a control 
>plane trace? I can see augmenting
>signalling protocols to faciliate this (e.g. LSP query I-D), but that does 
>not fit into this discussion.
>
>10) This seems to be overlapping with a solution framework.
>
>11) Any intention of aligning TTL models with the terminology emerging 
>elsewhere (pipe or uniform
>models?).
>
>13) Don't quite grok the motivation. I plead ignorance ;-)
>
>The protocol requirements section is actually rather prescriptive. There 
>are specific requirements
>in there that end up as either application limitations or part of an 
>applicability statement (e.g. routing
>requirements) or design guidelines. The rest shouldn't be in this document.
>
>IMHO at the present time the document is not quite ready for "prime time".
>
>my two cents
>Dave

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Wed, 20 Feb 2002 10:57:04 -0800
From: "David Allan"<[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: Ron Bonica <[email-masked]>, [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Wed, 20 Feb 2002 13:54:09 -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_01C1BA3F.FA9ACEC0
Content-Type: text/plain;
	charset="iso-8859-1"

Loa:

I thought the first criteria (somthing we should do) was met when somthing
appeared in a WG charter and milestones ;-).

As for the second, I'll agree to disagree. I've provided my suggestions as
to changes that should be made before IMO the document is a good enough
starting point. Others should offer their opinions.

cheers
Dave

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 11:31 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Ron Bonica; [email-masked]
> Subject: Re: draft-bonica-tunneltrace-02
> 
> 
> All,
> 
> a more IETF (possibly ccamp) philosophical question. What do
> we do when we accept a document as a WG document. In my mind
> it is a step taken when we realise that this is something that
> the WG group should do and the document is a good enough starting
> point for doing this work.
> 
> Even if I agreed with all of Dave's comments it is my 2 c's
> that both the criteria above are met and that we should progress
> the doc as a WG document.
> 
> There will be a couple of iterations where the comments will be
> addressed and possibly be worked into the final req doc.
> 
> 
> /Loa
> 
> David Allan wrote:
> 
> > Ron:
> > 
> > I have a number of comments on the draft.
> > 
> > Clarifications:
> > 
> > The discussion of traceroute in section 5, 2nd para. Are you really 
> > saying that
> > traceroute only reveals the current layer/level and reveals 
> no knowledge 
> > of nesting of
> > lower layer/level tunnels or the relationship of the 
> current level to 
> > higher levels?
> > It doesn't clearly come out.
> > 
> > Comments on application requirements (numbers correspond to the 
> > requirement):
> > 
> > 1) I think a broader discussion of some of the security 
> issues needs to 
> > be raised. First by
> > whatever means a trace request needs to be able to be 
> instantiated at a 
> > tunnel end
> > point. Second, as a result of initiating a trace, any node in the 
> > network may be required to
> > generate a response to the tracing application. Therefore 
> the tracing 
> > application is required
> > to promiscuously accept responses. A mechanism is required to 
> > authoritatively associate
> > responses with requests and discard spurious messages. 
> Further such a 
> > mechanism should not be
> > able to be leveraged for denial of service attacks (e.g. 
> spurious trace 
> > responses forcing lots
> > of cryptography, defense against replay attacks etc.).
> > 
> > 2) Any interface? I think any routable interface (mind you 
> this is where 
> > separating out routing
> > limitations into a separate section reduces the clarity). I 
> think there 
> > is a separate stipulation that
> > there is no representation as to the number of protocol 
> exchanges it 
> > takes to perform a trace
> > (other than permitting the trace originator to perform some 
> measure of 
> > flow control by the protocol
> > being designed to bound the number of responses a transaction will 
> > elicit; ideally 1 to 1, this also
> > has DOS implications similar to ICMP smurf type attacks whereby the 
> > responses to a single
> > message can be unbounded). You actually bring this up 
> obliquely in the 
> > protocol requirements, but IMHO it
> > should be expressed less prescriptively.
> > 
> > 3) Is third party really a special case? Can I not instantiate an 
> > in-line trace using management
> > protocols etc. and pull back the results.
> > 
> > 4) the application "displays" tunnels (editorial nit)? are 
> we really 
> > discussing how much information the
> > application collects and reports on. The alternative 
> interpretation is 
> > that the same amount of
> > information is always collected, and somehow filtered 
> during presentation.
> > 
> > 4) When you say "single hop" or "in detail", are you really 
> saying "this 
> > layer" or "constituent
> > lower layer components"? It could use clarification.
> > 
> > 5) Are you sure the collected information includes round 
> trip delay? 
> > It's not clear to me
> > whether this is some pre-existing chunk of information just lying 
> > around, or where the trace
> > transaction is expected to measure RTT on the fly for every hop and 
> > provide current view.
> > 
> > 6) I think are more accurate statement is support any tunneling 
> > technology that is used between
> > IP endpoints. Otherwise this is not a sustainable requirement. I am 
> > concerned, for example, that
> > any intervening L2 or layer 2 and a half skewers the model. (e.g.. 
> > IP/PPP/L2TP, you can only
> > reveal the PPP end points, or if you look at L2TP tunnel 
> switches, you 
> > appear to be SOL)
> > 
> > 7) This is the "detail" referred to earlier? Seems this one 
> is subject 
> > to the routing
> > requirements reported later. Might be easier simply to 
> introduce that 
> > limitation here.
> > 
> > 8) Is the expectation that the quality of information 
> obtained from a 
> > control plane trace and a
> > forwarding plane be comparable? Can you clarify what you mean by a 
> > control plane trace? I can see augmenting
> > signalling protocols to faciliate this (e.g. LSP query 
> I-D), but that 
> > does not fit into this discussion.
> > 
> > 10) This seems to be overlapping with a solution framework.
> > 
> > 11) Any intention of aligning TTL models with the 
> terminology emerging 
> > elsewhere (pipe or uniform
> > models?).
> > 
> > 13) Don't quite grok the motivation. I plead ignorance ;-)
> > 
> > The protocol requirements section is actually rather 
> prescriptive. There 
> > are specific requirements
> > in there that end up as either application limitations or 
> part of an 
> > applicability statement (e.g. routing
> > requirements) or design guidelines. The rest shouldn't be 
> in this document.
> > 
> > IMHO at the present time the document is not quite ready 
> for "prime time".
> > 
> > my two cents
> > Dave
> > 
> 
> 
> -- 
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> Råsundavägen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           [email-masked]
> WWW             www.utfors.se
> 
> 
> 

------_=_NextPart_001_01C1BA3F.FA9ACEC0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Loa:</FONT>
</P>

<P><FONT SIZE=3D2>I thought the first criteria (somthing we should do) =
was met when somthing appeared in a WG charter and milestones =
;-).</FONT>
</P>

<P><FONT SIZE=3D2>As for the second, I'll agree to disagree. I've =
provided my suggestions as to changes that should be made before IMO =
the document is a good enough starting point. Others should offer their =
opinions.</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Loa Andersson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, February 20, 2002 11:31 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Allan, David [CAR:NS00:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Ron Bonica; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; a more IETF (possibly ccamp) philosophical =
question. What do</FONT>
<BR><FONT SIZE=3D2>&gt; we do when we accept a document as a WG =
document. In my mind</FONT>
<BR><FONT SIZE=3D2>&gt; it is a step taken when we realise that this is =
something that</FONT>
<BR><FONT SIZE=3D2>&gt; the WG group should do and the document is a =
good enough starting</FONT>
<BR><FONT SIZE=3D2>&gt; point for doing this work.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Even if I agreed with all of Dave's comments it =
is my 2 c's</FONT>
<BR><FONT SIZE=3D2>&gt; that both the criteria above are met and that =
we should progress</FONT>
<BR><FONT SIZE=3D2>&gt; the doc as a WG document.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There will be a couple of iterations where the =
comments will be</FONT>
<BR><FONT SIZE=3D2>&gt; addressed and possibly be worked into the final =
req doc.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; /Loa</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David Allan wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ron:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I have a number of comments on the =
draft.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Clarifications:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The discussion of traceroute in section 5, =
2nd para. Are you really </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; saying that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; traceroute only reveals the current =
layer/level and reveals </FONT>
<BR><FONT SIZE=3D2>&gt; no knowledge </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of nesting of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; lower layer/level tunnels or the =
relationship of the </FONT>
<BR><FONT SIZE=3D2>&gt; current level to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; higher levels?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; It doesn't clearly come out.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Comments on application requirements =
(numbers correspond to the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirement):</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1) I think a broader discussion of some of =
the security </FONT>
<BR><FONT SIZE=3D2>&gt; issues needs to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be raised. First by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; whatever means a trace request needs to be =
able to be </FONT>
<BR><FONT SIZE=3D2>&gt; instantiated at a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; tunnel end</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; point. Second, as a result of initiating a =
trace, any node in the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; network may be required to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; generate a response to the tracing =
application. Therefore </FONT>
<BR><FONT SIZE=3D2>&gt; the tracing </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; application is required</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to promiscuously accept responses. A =
mechanism is required to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; authoritatively associate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; responses with requests and discard =
spurious messages. </FONT>
<BR><FONT SIZE=3D2>&gt; Further such a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; mechanism should not be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; able to be leveraged for denial of service =
attacks (e.g. </FONT>
<BR><FONT SIZE=3D2>&gt; spurious trace </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; responses forcing lots</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of cryptography, defense against replay =
attacks etc.).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2) Any interface? I think any routable =
interface (mind you </FONT>
<BR><FONT SIZE=3D2>&gt; this is where </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; separating out routing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; limitations into a separate section =
reduces the clarity). I </FONT>
<BR><FONT SIZE=3D2>&gt; think there </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; is a separate stipulation that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; there is no representation as to the =
number of protocol </FONT>
<BR><FONT SIZE=3D2>&gt; exchanges it </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; takes to perform a trace</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (other than permitting the trace =
originator to perform some </FONT>
<BR><FONT SIZE=3D2>&gt; measure of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; flow control by the protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; being designed to bound the number of =
responses a transaction will </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; elicit; ideally 1 to 1, this also</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; has DOS implications similar to ICMP smurf =
type attacks whereby the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; responses to a single</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; message can be unbounded). You actually =
bring this up </FONT>
<BR><FONT SIZE=3D2>&gt; obliquely in the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocol requirements, but IMHO it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; should be expressed less =
prescriptively.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 3) Is third party really a special case? =
Can I not instantiate an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in-line trace using management</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocols etc. and pull back the =
results.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 4) the application &quot;displays&quot; =
tunnels (editorial nit)? are </FONT>
<BR><FONT SIZE=3D2>&gt; we really </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; discussing how much information the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; application collects and reports on. The =
alternative </FONT>
<BR><FONT SIZE=3D2>&gt; interpretation is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that the same amount of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; information is always collected, and =
somehow filtered </FONT>
<BR><FONT SIZE=3D2>&gt; during presentation.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 4) When you say &quot;single hop&quot; or =
&quot;in detail&quot;, are you really </FONT>
<BR><FONT SIZE=3D2>&gt; saying &quot;this </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; layer&quot; or &quot;constituent</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; lower layer components&quot;? It could use =
clarification.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 5) Are you sure the collected information =
includes round </FONT>
<BR><FONT SIZE=3D2>&gt; trip delay? </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; It's not clear to me</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; whether this is some pre-existing chunk of =
information just lying </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; around, or where the trace</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; transaction is expected to measure RTT on =
the fly for every hop and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; provide current view.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 6) I think are more accurate statement is =
support any tunneling </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; technology that is used between</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; IP endpoints. Otherwise this is not a =
sustainable requirement. I am </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; concerned, for example, that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; any intervening L2 or layer 2 and a half =
skewers the model. (e.g.. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; IP/PPP/L2TP, you can only</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; reveal the PPP end points, or if you look =
at L2TP tunnel </FONT>
<BR><FONT SIZE=3D2>&gt; switches, you </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; appear to be SOL)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 7) This is the &quot;detail&quot; referred =
to earlier? Seems this one </FONT>
<BR><FONT SIZE=3D2>&gt; is subject </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to the routing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirements reported later. Might be =
easier simply to </FONT>
<BR><FONT SIZE=3D2>&gt; introduce that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; limitation here.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 8) Is the expectation that the quality of =
information </FONT>
<BR><FONT SIZE=3D2>&gt; obtained from a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; control plane trace and a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; forwarding plane be comparable? Can you =
clarify what you mean by a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; control plane trace? I can see =
augmenting</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; signalling protocols to faciliate this =
(e.g. LSP query </FONT>
<BR><FONT SIZE=3D2>&gt; I-D), but that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; does not fit into this discussion.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 10) This seems to be overlapping with a =
solution framework.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 11) Any intention of aligning TTL models =
with the </FONT>
<BR><FONT SIZE=3D2>&gt; terminology emerging </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; elsewhere (pipe or uniform</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; models?).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 13) Don't quite grok the motivation. I =
plead ignorance ;-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The protocol requirements section is =
actually rather </FONT>
<BR><FONT SIZE=3D2>&gt; prescriptive. There </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; are specific requirements</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in there that end up as either application =
limitations or </FONT>
<BR><FONT SIZE=3D2>&gt; part of an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; applicability statement (e.g. =
routing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirements) or design guidelines. The =
rest shouldn't be </FONT>
<BR><FONT SIZE=3D2>&gt; in this document.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; IMHO at the present time the document is =
not quite ready </FONT>
<BR><FONT SIZE=3D2>&gt; for &quot;prime time&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; my two cents</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Loa Andersson</FONT>
<BR><FONT SIZE=3D2>&gt; Chief Architect,</FONT>
<BR><FONT SIZE=3D2>&gt; Utfors Research, Architecture and Future Lab =
(URAX)</FONT>
<BR><FONT SIZE=3D2>&gt; Utfors AB</FONT>
<BR><FONT SIZE=3D2>&gt; R=E5sundav=E4gen 12</FONT>
<BR><FONT SIZE=3D2>&gt; Box 525, 169 29 Solna</FONT>
<BR><FONT SIZE=3D2>&gt; =
Office&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +46 8 5270 =
2000</FONT>
<BR><FONT SIZE=3D2>&gt; Office direct&nbsp;&nbsp; +46 8 5270 =
5038</FONT>
<BR><FONT SIZE=3D2>&gt; =
Mobile&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +46 70 848 =
5038</FONT>
<BR><FONT SIZE=3D2>&gt; =
Email&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; =
WWW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; www.utfors.se</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BA3F.FA9ACEC0--

Delivery-date: Wed, 20 Feb 2002 08:32:02 -0800
Date: Wed, 20 Feb 2002 17:30:39 +0100
From: Loa Andersson <[email-masked]>
To: David Allan <[email-masked]>
CC: Ron Bonica <[email-masked]>, [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

All,

a more IETF (possibly ccamp) philosophical question. What do
we do when we accept a document as a WG document. In my mind
it is a step taken when we realise that this is something that
the WG group should do and the document is a good enough starting
point for doing this work.

Even if I agreed with all of Dave's comments it is my 2 c's
that both the criteria above are met and that we should progress
the doc as a WG document.

There will be a couple of iterations where the comments will be
addressed and possibly be worked into the final req doc.

/Loa

David Allan wrote:

> Ron:
> 
> I have a number of comments on the draft.
> 
> Clarifications:
> 
> The discussion of traceroute in section 5, 2nd para. Are you really 
> saying that
> traceroute only reveals the current layer/level and reveals no knowledge 
> of nesting of
> lower layer/level tunnels or the relationship of the current level to 
> higher levels?
> It doesn't clearly come out.
> 
> Comments on application requirements (numbers correspond to the 
> requirement):
> 
> 1) I think a broader discussion of some of the security issues needs to 
> be raised. First by
> whatever means a trace request needs to be able to be instantiated at a 
> tunnel end
> point. Second, as a result of initiating a trace, any node in the 
> network may be required to
> generate a response to the tracing application. Therefore the tracing 
> application is required
> to promiscuously accept responses. A mechanism is required to 
> authoritatively associate
> responses with requests and discard spurious messages. Further such a 
> mechanism should not be
> able to be leveraged for denial of service attacks (e.g. spurious trace 
> responses forcing lots
> of cryptography, defense against replay attacks etc.).
> 
> 2) Any interface? I think any routable interface (mind you this is where 
> separating out routing
> limitations into a separate section reduces the clarity). I think there 
> is a separate stipulation that
> there is no representation as to the number of protocol exchanges it 
> takes to perform a trace
> (other than permitting the trace originator to perform some measure of 
> flow control by the protocol
> being designed to bound the number of responses a transaction will 
> elicit; ideally 1 to 1, this also
> has DOS implications similar to ICMP smurf type attacks whereby the 
> responses to a single
> message can be unbounded). You actually bring this up obliquely in the 
> protocol requirements, but IMHO it
> should be expressed less prescriptively.
> 
> 3) Is third party really a special case? Can I not instantiate an 
> in-line trace using management
> protocols etc. and pull back the results.
> 
> 4) the application "displays" tunnels (editorial nit)? are we really 
> discussing how much information the
> application collects and reports on. The alternative interpretation is 
> that the same amount of
> information is always collected, and somehow filtered during presentation.
> 
> 4) When you say "single hop" or "in detail", are you really saying "this 
> layer" or "constituent
> lower layer components"? It could use clarification.
> 
> 5) Are you sure the collected information includes round trip delay? 
> It's not clear to me
> whether this is some pre-existing chunk of information just lying 
> around, or where the trace
> transaction is expected to measure RTT on the fly for every hop and 
> provide current view.
> 
> 6) I think are more accurate statement is support any tunneling 
> technology that is used between
> IP endpoints. Otherwise this is not a sustainable requirement. I am 
> concerned, for example, that
> any intervening L2 or layer 2 and a half skewers the model. (e.g.. 
> IP/PPP/L2TP, you can only
> reveal the PPP end points, or if you look at L2TP tunnel switches, you 
> appear to be SOL)
> 
> 7) This is the "detail" referred to earlier? Seems this one is subject 
> to the routing
> requirements reported later. Might be easier simply to introduce that 
> limitation here.
> 
> 8) Is the expectation that the quality of information obtained from a 
> control plane trace and a
> forwarding plane be comparable? Can you clarify what you mean by a 
> control plane trace? I can see augmenting
> signalling protocols to faciliate this (e.g. LSP query I-D), but that 
> does not fit into this discussion.
> 
> 10) This seems to be overlapping with a solution framework.
> 
> 11) Any intention of aligning TTL models with the terminology emerging 
> elsewhere (pipe or uniform
> models?).
> 
> 13) Don't quite grok the motivation. I plead ignorance ;-)
> 
> The protocol requirements section is actually rather prescriptive. There 
> are specific requirements
> in there that end up as either application limitations or part of an 
> applicability statement (e.g. routing
> requirements) or design guidelines. The rest shouldn't be in this document.
> 
> IMHO at the present time the document is not quite ready for "prime time".
> 
> my two cents
> Dave
> 

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

Delivery-date: Wed, 20 Feb 2002 08:00:14 -0800
From: "David Allan"<[email-masked]>
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: re: draft-bonica-tunneltrace-02
Date: Wed, 20 Feb 2002 10:59:25 -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_01C1BA27.91BF5190
Content-Type: text/plain;
	charset="iso-8859-1"

Ron:

I have a number of comments on the draft.

Clarifications:

The discussion of traceroute in section 5, 2nd para. Are you really saying
that
traceroute only reveals the current layer/level and reveals no knowledge of
nesting of
lower layer/level tunnels or the relationship of the current level to higher
levels? 
It doesn't clearly come out.

Comments on application requirements (numbers correspond to the
requirement):

1) I think a broader discussion of some of the security issues needs to be
raised. First by
whatever means a trace request needs to be able to be instantiated at a
tunnel end
point. Second, as a result of initiating a trace, any node in the network
may be required to
generate a response to the tracing application. Therefore the tracing
application is required
to promiscuously accept responses. A mechanism is required to
authoritatively associate
responses with requests and discard spurious messages. Further such a
mechanism should not be
able to be leveraged for denial of service attacks (e.g. spurious trace
responses forcing lots 
of cryptography, defense against replay attacks etc.).

2) Any interface? I think any routable interface (mind you this is where
separating out routing
limitations into a separate section reduces the clarity). I think there is a
separate stipulation that
there is no representation as to the number of protocol exchanges it takes
to perform a trace
(other than permitting the trace originator to perform some measure of flow
control by the protocol
being designed to bound the number of responses a transaction will elicit;
ideally 1 to 1, this also 
has DOS implications similar to ICMP smurf type attacks whereby the
responses to a single 
message can be unbounded). You actually bring this up obliquely in the
protocol requirements, but IMHO it
should be expressed less prescriptively.

3) Is third party really a special case? Can I not instantiate an in-line
trace using management
protocols etc. and pull back the results.

4) the application "displays" tunnels (editorial nit)? are we really
discussing how much information the
application collects and reports on. The alternative interpretation is that
the same amount of
information is always collected, and somehow filtered during presentation.

4) When you say "single hop" or "in detail", are you really saying "this
layer" or "constituent
lower layer components"? It could use clarification.

5) Are you sure the collected information includes round trip delay? It's
not clear to me
whether this is some pre-existing chunk of information just lying around, or
where the trace
transaction is expected to measure RTT on the fly for every hop and provide
current view.

6) I think are more accurate statement is support any tunneling technology
that is used between
IP endpoints. Otherwise this is not a sustainable requirement. I am
concerned, for example, that
any intervening L2 or layer 2 and a half skewers the model. (e.g..
IP/PPP/L2TP, you can only
reveal the PPP end points, or if you look at L2TP tunnel switches, you
appear to be SOL)

7) This is the "detail" referred to earlier? Seems this one is subject to
the routing
requirements reported later. Might be easier simply to introduce that
limitation here.

8) Is the expectation that the quality of information obtained from a
control plane trace and a
forwarding plane be comparable? Can you clarify what you mean by a control
plane trace? I can see augmenting
signalling protocols to faciliate this (e.g. LSP query I-D), but that does
not fit into this discussion.

10) This seems to be overlapping with a solution framework.

11) Any intention of aligning TTL models with the terminology emerging
elsewhere (pipe or uniform
models?).

13) Don't quite grok the motivation. I plead ignorance ;-)

The protocol requirements section is actually rather prescriptive. There are
specific requirements
in there that end up as either application limitations or part of an
applicability statement (e.g. routing 
requirements) or design guidelines. The rest shouldn't be in this document.

IMHO at the present time the document is not quite ready for "prime time".

my two cents
Dave

------_=_NextPart_001_01C1BA27.91BF5190
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>re: draft-bonica-tunneltrace-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ron:</FONT>
</P>

<P><FONT SIZE=3D2>I have a number of comments on the draft.</FONT>
</P>

<P><FONT SIZE=3D2>Clarifications:</FONT>
</P>

<P><FONT SIZE=3D2>The discussion of traceroute in section 5, 2nd para. =
Are you really saying that</FONT>
<BR><FONT SIZE=3D2>traceroute only reveals the current layer/level and =
reveals no knowledge of nesting of</FONT>
<BR><FONT SIZE=3D2>lower layer/level tunnels or the relationship of the =
current level to higher levels? </FONT>
<BR><FONT SIZE=3D2>It doesn't clearly come out.</FONT>
</P>

<P><FONT SIZE=3D2>Comments on application requirements (numbers =
correspond to the requirement):</FONT>
</P>

<P><FONT SIZE=3D2>1) I think a broader discussion of some of the =
security issues needs to be raised. First by</FONT>
<BR><FONT SIZE=3D2>whatever means a trace request needs to be able to =
be instantiated at a tunnel end</FONT>
<BR><FONT SIZE=3D2>point. Second, as a result of initiating a trace, =
any node in the network may be required to</FONT>
<BR><FONT SIZE=3D2>generate a response to the tracing application. =
Therefore the tracing application is required</FONT>
<BR><FONT SIZE=3D2>to promiscuously accept responses. A mechanism is =
required to authoritatively associate</FONT>
<BR><FONT SIZE=3D2>responses with requests and discard spurious =
messages. Further such a mechanism should not be</FONT>
<BR><FONT SIZE=3D2>able to be leveraged for denial of service attacks =
(e.g. spurious trace responses forcing lots </FONT>
<BR><FONT SIZE=3D2>of cryptography, defense against replay attacks =
etc.).</FONT>
</P>

<P><FONT SIZE=3D2>2) Any interface? I think any routable interface =
(mind you this is where separating out routing</FONT>
<BR><FONT SIZE=3D2>limitations into a separate section reduces the =
clarity). I think there is a separate stipulation that</FONT>
<BR><FONT SIZE=3D2>there is no representation as to the number of =
protocol exchanges it takes to perform a trace</FONT>
<BR><FONT SIZE=3D2>(other than permitting the trace originator to =
perform some measure of flow control by the protocol</FONT>
<BR><FONT SIZE=3D2>being designed to bound the number of responses a =
transaction will elicit; ideally 1 to 1, this also </FONT>
<BR><FONT SIZE=3D2>has DOS implications similar to ICMP smurf type =
attacks whereby the responses to a single </FONT>
<BR><FONT SIZE=3D2>message can be unbounded). You actually bring this =
up obliquely in the protocol requirements, but IMHO it</FONT>
<BR><FONT SIZE=3D2>should be expressed less prescriptively.</FONT>
</P>

<P><FONT SIZE=3D2>3) Is third party really a special case? Can I not =
instantiate an in-line trace using management</FONT>
<BR><FONT SIZE=3D2>protocols etc. and pull back the results.</FONT>
</P>

<P><FONT SIZE=3D2>4) the application &quot;displays&quot; tunnels =
(editorial nit)? are we really discussing how much information =
the</FONT>
<BR><FONT SIZE=3D2>application collects and reports on. The alternative =
interpretation is that the same amount of</FONT>
<BR><FONT SIZE=3D2>information is always collected, and somehow =
filtered during presentation.</FONT>
</P>

<P><FONT SIZE=3D2>4) When you say &quot;single hop&quot; or &quot;in =
detail&quot;, are you really saying &quot;this layer&quot; or =
&quot;constituent</FONT>
<BR><FONT SIZE=3D2>lower layer components&quot;? It could use =
clarification.</FONT>
</P>

<P><FONT SIZE=3D2>5) Are you sure the collected information includes =
round trip delay? It's not clear to me</FONT>
<BR><FONT SIZE=3D2>whether this is some pre-existing chunk of =
information just lying around, or where the trace</FONT>
<BR><FONT SIZE=3D2>transaction is expected to measure RTT on the fly =
for every hop and provide current view.</FONT>
</P>

<P><FONT SIZE=3D2>6) I think are more accurate statement is support any =
tunneling technology that is used between</FONT>
<BR><FONT SIZE=3D2>IP endpoints. Otherwise this is not a sustainable =
requirement. I am concerned, for example, that</FONT>
<BR><FONT SIZE=3D2>any intervening L2 or layer 2 and a half skewers the =
model. (e.g.. IP/PPP/L2TP, you can only</FONT>
<BR><FONT SIZE=3D2>reveal the PPP end points, or if you look at L2TP =
tunnel switches, you appear to be SOL)</FONT>
</P>

<P><FONT SIZE=3D2>7) This is the &quot;detail&quot; referred to =
earlier? Seems this one is subject to the routing</FONT>
<BR><FONT SIZE=3D2>requirements reported later. Might be easier simply =
to introduce that limitation here.</FONT>
</P>

<P><FONT SIZE=3D2>8) Is the expectation that the quality of information =
obtained from a control plane trace and a</FONT>
<BR><FONT SIZE=3D2>forwarding plane be comparable? Can you clarify what =
you mean by a control plane trace? I can see augmenting</FONT>
<BR><FONT SIZE=3D2>signalling protocols to faciliate this (e.g. LSP =
query I-D), but that does not fit into this discussion.</FONT>
</P>

<P><FONT SIZE=3D2>10) This seems to be overlapping with a solution =
framework.</FONT>
</P>

<P><FONT SIZE=3D2>11) Any intention of aligning TTL models with the =
terminology emerging elsewhere (pipe or uniform</FONT>
<BR><FONT SIZE=3D2>models?).</FONT>
</P>

<P><FONT SIZE=3D2>13) Don't quite grok the motivation. I plead =
ignorance ;-)</FONT>
</P>

<P><FONT SIZE=3D2>The protocol requirements section is actually rather =
prescriptive. There are specific requirements</FONT>
<BR><FONT SIZE=3D2>in there that end up as either application =
limitations or part of an applicability statement (e.g. routing </FONT>
<BR><FONT SIZE=3D2>requirements) or design guidelines. The rest =
shouldn't be in this document.</FONT>
</P>

<P><FONT SIZE=3D2>IMHO at the present time the document is not quite =
ready for &quot;prime time&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>my two cents</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BA27.91BF5190--

Delivery-date: Wed, 20 Feb 2002 07:30:34 -0800
To: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-02.txt
Date: Wed, 20 Feb 2002 07:27:39 -0800
From: Yakov Rekhter <[email-masked]>

Folks,

The only changes relative to the -01 version are (a)  globally
replace "SONET ANSI T1.105-1995" with "SONET ANSI T1.105" and (b)
"Photonic" with "Lambda (photonic)".

Yakov.
------- Forwarded Message

Date:    Wed, 20 Feb 2002 07:07:13 -0500
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-02.txt

- --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 G
roup of the IETF.

	Title		: Routing Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella et al.
	Filename	: draft-ietf-ccamp-gmpls-routing-02.txt
	Pages		: 21
	Date		: 19-Feb-02
	
This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS).

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-02.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-routing-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

Delivery-date: Wed, 20 Feb 2002 04:09:16 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-02.txt
Date: Wed, 20 Feb 2002 07:07:13 -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		: Routing Extensions in Support of Generalized MPLS
	Author(s)	: K. Kompella et al.
	Filename	: draft-ietf-ccamp-gmpls-routing-02.txt
	Pages		: 21
	Date		: 19-Feb-02
	
This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS).

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-routing-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 19 Feb 2002 14:40:17 -0800
From: Shahram Davari <[email-masked]>
To: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Tue, 19 Feb 2002 14:28:39 -0800

Hi,

Although this document is a generic requirement for tunnel tracing, I find many protocol specific requirements that are not actually a requirement, rather they are suggesting a specific solution.

For example:

"The protocol elicits a series of traceResponse messages."
"Each traceResponse message represents a hop that connects the head-end of the traced path to the tail-end of the traced path"  
"Each traceProbe message elicits exactly one traceResponse message."
"UDP carries traceProbe and traceResponse messages to their destinations."

Thanks,
-Shahram

Delivery-date: Mon, 18 Feb 2002 08:50:48 -0800
Date: Mon, 18 Feb 2002 17:44:51 +0100
From: Tove Madsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-bonica-tunneltrace-02

Hi,
I support that we do a WG draft of the draft-bonica-tunneltrace-02.
/ Tove Madsen

> -------- Original Message --------
> Subject: draft-bonica-tunneltrace-02
> Date: Sat, 16 Feb 2002 21:13:47 -0500
> From: Ron Bonica <[email-masked]>
> To: [email-masked]
>
> Folks,
>
> I would like to propose that we adopt
>
> Comments?
>
> ===========================================
> 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."
>                  -- Angello Giuseppe Roncalli

--
Tove Madsen
Architecture Specialist
Utfors Bredband AB
Råsundavägen 12, P.O. Box 525, SE-169 29 Solna, Sweden

phone:  +46 8 5270 5040
mobile: +46 70 848 5040
fax:    +46 8 5270 2595
mailto:[email-masked]
http://www.utfors.se/

Delivery-date: Mon, 18 Feb 2002 08:04:22 -0800
From: Randy Bush <[email-masked]>
To: Mina Azad <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Mon, 18 Feb 2002 08:03:40 -0800

> Is this not the same tool that was presented in the OAM BOF in IETF 52?
> In the BOF, the ADs were to decide on the proper location to progress work
> on MPLS related management/maintenance (a.k.a. OAM) tools. Have ADs made a
> decision?

draft-bonica-tunneltrace-02.txt is not mpls-specific, and is a COMMON
mechanism.  i know that l2-agnostic mechanisms are not the fashion in the
ccamp wg, but they're supposed to be.

> Also, given that the ITU-T draft recommendation Y.1711 "OAM Mechanism for
> MPLS Networks" has been consented, what is the rational for standardizing
> this tool in isolation?

this isn't the itu.  we actually have layer three operators and users here,
who want stuff that operates above layers one and two.

randy

Delivery-date: Mon, 18 Feb 2002 07:46:21 -0800
Date: Mon, 18 Feb 2002 10:41:02 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: draft-bonica-tunneltrace-02
To: Mina Azad <[email-masked]>
Cc: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_KCEYEv9f0fQZ0LlAYG5zjA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

RE: draft-bonica-tunneltrace-02Mina,

This is a requirements specification, not an implementation. Many tools
might satisfy the requirements specified by this draft.

This draft states a requirement to trace through many types of tunnels
(e.g., MPLS, IP-in-IP). MPLS OAM does not satisfy this requirement because
it applies only to MPLS LSPs.

Ron

  -----Original Message-----
  From: Mina Azad [mailto:[email-masked]]
  Sent: Monday, February 18, 2002 10:16 AM
  To: Ron Bonica
  Cc: [email-masked]
  Subject: RE: draft-bonica-tunneltrace-02

  Is this not the same tool that was presented in the OAM BOF in IETF 52?
  In the BOF, the ADs were to decide on the proper location to progress work
on MPLS related management/maintenance (a.k.a. OAM) tools. Have ADs made a
decision?

  Also, given that the ITU-T draft recommendation Y.1711 "OAM Mechanism for
MPLS Networks" has been consented, what is the rational for standardizing
this tool in isolation?

  Regards,

  Mina Azad

  > -----Original Message-----
  > From: Ron Bonica [mailto:[email-masked]]
  > Sent: Saturday, February 16, 2002 9:14 PM
  > To: [email-masked]
  > Subject: draft-bonica-tunneltrace-02
  >
  >
  > Folks,
  >
  > I would like to propose that we adopt
  > draft-bonica-tunneltrace-02 as a WG
  > draft.
  >
  > Comments?
  >
  > ===========================================
  > 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."
  >                 -- Angello Giuseppe Roncalli
  >
  >
  >

--Boundary_(ID_KCEYEv9f0fQZ0LlAYG5zjA)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: draft-bonica-tunneltrace-02</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D548063315-18022002><FONT face=3DArial color=3D#0000ff =

size=3D2>Mina,</FONT></SPAN></DIV>
<DIV><SPAN class=3D548063315-18022002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D548063315-18022002><FONT face=3DArial color=3D#0000ff =
size=3D2>This=20
is a requirements specification, not an implementation. Many tools might =
satisfy=20
the requirements&nbsp;specified by this draft.</FONT></SPAN></DIV>
<DIV><SPAN class=3D548063315-18022002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D548063315-18022002><FONT face=3DArial color=3D#0000ff =
size=3D2>This=20
draft states a requirement to trace through many types of tunnels (e.g., =
MPLS,=20
IP-in-IP). MPLS OAM does not satisfy this requirement because it applies =
only to=20
MPLS LSPs.</FONT></SPAN></DIV>
<DIV><SPAN class=3D548063315-18022002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D548063315-18022002><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
Ron</FONT></SPAN></DIV>
<DIV><SPAN class=3D548063315-18022002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Mina Azad=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, February 18, =
2002=20
  10:16 AM<BR><B>To:</B> Ron Bonica<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> RE:=20
  draft-bonica-tunneltrace-02<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Is this not the same tool that was presented in the =
OAM BOF in=20
  IETF 52?</FONT> <BR><FONT size=3D2>In the BOF, the ADs were to decide =
on the=20
  proper location to progress work on MPLS related =
management/maintenance=20
  (a.k.a. OAM) tools. Have ADs made a decision?&nbsp; </FONT></P>
  <P><FONT size=3D2>Also, given that the ITU-T draft recommendation =
Y.1711 "OAM=20
  Mechanism for MPLS Networks" has been consented, what is the rational =
for=20
  standardizing this tool in isolation?</FONT></P>
  <P><FONT size=3D2>&nbsp; </FONT><BR><FONT size=3D2>Regards,</FONT> =
</P>
  <P><FONT size=3D2>Mina Azad</FONT> </P><BR>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Ron Bonica [<A=20
  =
href=3D"mailto:[email-masked]">mailto:[email-masked]<=
/A>]</FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Saturday, February 16, 2002 9:14 =
PM</FONT>=20
  <BR><FONT size=3D2>&gt; To: [email-masked]</FONT> <BR><FONT =
size=3D2>&gt;=20
  Subject: draft-bonica-tunneltrace-02</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
Folks,</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I would like to =
propose=20
  that we adopt </FONT><BR><FONT size=3D2>&gt; =
draft-bonica-tunneltrace-02 as a=20
  WG</FONT> <BR><FONT size=3D2>&gt; draft.</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Comments?</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt;=20
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT> <BR><FONT =
size=3D2>&gt;=20
  Ronald P. Bonica&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ph: 703 886 =
1681</FONT>=20
  <BR><FONT size=3D2>&gt; vBNS =
Engineering&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  page: 1 888 268 8021</FONT> <BR><FONT size=3D2>&gt; Ashburn, =
Va.</FONT>=20
  <BR><FONT size=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>=20
  <BR><FONT size=3D2>&gt; "We are not on Earth to guard a museum, =
but</FONT>=20
  <BR><FONT size=3D2>&gt; to cultivate a flourishing garden of =
life."</FONT>=20
  <BR><FONT=20
  =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  -- Angello Giuseppe Roncalli</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT></P></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_KCEYEv9f0fQZ0LlAYG5zjA)--

Delivery-date: Mon, 18 Feb 2002 07:19:45 -0800
From: "Mina Azad"<[email-masked]>
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-bonica-tunneltrace-02
Date: Mon, 18 Feb 2002 10:16:23 -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_01C1B88F.39E2E610
Content-Type: text/plain;
	charset="iso-8859-1"

Is this not the same tool that was presented in the OAM BOF in IETF 52?
In the BOF, the ADs were to decide on the proper location to progress work
on MPLS related management/maintenance (a.k.a. OAM) tools. Have ADs made a
decision?  
Also, given that the ITU-T draft recommendation Y.1711 "OAM Mechanism for
MPLS Networks" has been consented, what is the rational for standardizing
this tool in isolation?
  
Regards,

Mina Azad

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]
> Sent: Saturday, February 16, 2002 9:14 PM
> To: [email-masked]
> Subject: draft-bonica-tunneltrace-02
> 
> 
> Folks,
> 
> I would like to propose that we adopt 
> draft-bonica-tunneltrace-02 as a WG
> draft.
> 
> Comments?
> 
> ===========================================
> 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."
>                 -- Angello Giuseppe Roncalli
> 
> 
> 

------_=_NextPart_001_01C1B88F.39E2E610
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: draft-bonica-tunneltrace-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Is this not the same tool that was presented in the =
OAM BOF in IETF 52?</FONT>
<BR><FONT SIZE=3D2>In the BOF, the ADs were to decide on the proper =
location to progress work on MPLS related management/maintenance =
(a.k.a. OAM) tools. Have ADs made a decision?&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Also, given that the ITU-T draft recommendation =
Y.1711 &quot;OAM Mechanism for MPLS Networks&quot; has been consented, =
what is the rational for standardizing this tool in =
isolation?</FONT></P>

<P><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Mina Azad</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Ron Bonica [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Saturday, February 16, 2002 9:14 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: draft-bonica-tunneltrace-02</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Folks,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would like to propose that we adopt </FONT>
<BR><FONT SIZE=3D2>&gt; draft-bonica-tunneltrace-02 as a WG</FONT>
<BR><FONT SIZE=3D2>&gt; draft.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Comments?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; Ronald P. =
Bonica&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ph: 703 886 1681</FONT>
<BR><FONT SIZE=3D2>&gt; vBNS =
Engineering&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; page: 1 888 268 =
8021</FONT>
<BR><FONT SIZE=3D2>&gt; Ashburn, Va.</FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;We are not on Earth to guard a museum, =
but</FONT>
<BR><FONT SIZE=3D2>&gt; to cultivate a flourishing garden of =
life.&quot;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Angello Giuseppe =
Roncalli</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1B88F.39E2E610--

Delivery-date: Sat, 16 Feb 2002 18:22:43 -0800
Date: Sat, 16 Feb 2002 21:13:47 -0500
From: Ron Bonica <[email-masked]>
Subject: draft-bonica-tunneltrace-02
To: [email-masked]

Folks,

I would like to propose that we adopt draft-bonica-tunneltrace-02 as a WG
draft.

Comments?

===========================================
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."
                -- Angello Giuseppe Roncalli

Delivery-date: Fri, 15 Feb 2002 06:32:13 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-wdm-00.txt
Date: Wed, 13 Feb 2002 07:08:49 -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		: Link Management Protocol (LMP) for DWDM Optical Line 
                          Systems
	Author(s)	: A. Fredette et al.
	Filename	: draft-ietf-ccamp-lmp-wdm-00.txt
	Pages		: 20
	Date		: 12-Feb-02
	
A suite of protocols is being developed in the IETF to allow 
networks consisting of photonic switches (PXCs), optical 
crossconnects (OXCs), routers, switches, DWDM optical line systems 
(OLSs), and optical add-drop multiplexors (OADMs) to use an MPLS-
based control plane to dynamically provision resources and to 
provide network survivability using protection and restoration 
techniques.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-wdm-00.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-lmp-wdm-00.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-lmp-wdm-00.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-lmp-wdm-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-wdm-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 14 Feb 2002 09:14:58 -0800
From: Hang Liu <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: New draft
Date: Thu, 14 Feb 2002 12:00:35 -0500

Hi.

I think what Adrian said makes sense. With Suggested Label, the resource can
be allocated in parallel along the path. The local operation within the node
to set up a connection can be divided into three phases.
1) Admission control. The NE checks whether resource is available after
receiving the connection request, e.g. RSVP PATH message
2) Reservation. Reserving the resource in the NE, e.g. wavelength or port
3) Allocation or commitment. Setting up the real connection in the NE, e.g.
cross-connect.

With Suggested Label, a node can do admission control and reservation (hope
that the delay for this process is not that large). It then passes the RSVP
PATH with necessary message processing to the downstream node with Suggested
Label. After the PATH message is forwarded to the downstream node, the node
can start setting up the connection within it. In this sense, the connection
setup can be done parallel. Of course, there is also some security issue. We
don't want to have data transmission over the path, for example, in the case
of UNI applications before the destination client agrees to accept the
connection. ResvConf can be used for this security. 

In independent LSP control, each LSR may make an independent decision to
assign a label to a FEC and to advertise the assignment to its neighbors.
This is more similar to conventional IP routing. In optical networks, GMPLS
is used to set up a circuit. Each node sets up the cross connect from an
incoming port/channel (label) to an outgoing port/channel (label) according
to the request in the signaling. One way to speed up this path provisioning
process is that an intermediate node passes the PATH message to the next hop
without doing admission control and reservation. After the PATH message is
passed to the next hop with necessary message processing  (e.g. ERO and HOP
objects encoding, etc), the node can further process the PATH message,
negotiating and assigning port/channel/label with its neighbors, setting up
the cross connect internally after negotiation is down. However this
requires extra signaling between neighbors. Not sure it is worth.

Regards

Hang
Tellium, Inc

-----Original Message-----
From: Rajaraman B [mailto:[email-masked]]
Sent: Thursday, February 14, 2002 10:01 AM
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: New draft

Hi Adrian,
	In which draft they have give like that. I did not find this
sentence in 
GMPLS architecture draft. can you please the specfic draft?

	Another thing, I want to ask you is that why is Independent label 
provisioning not possible in optical network (that is, in GMPLS)? can you 
please explain that?

Regards,
Rajaraman. B

On Thursday 14 February 2002 8:04 pm, you wrote:
> No, I believe I am right.
>
> Section 4 explicitly says "That is to say, the nodes along a lightpath
will
> do their local resource allocation one by one."
>
> This is not a requirement in GMPLS.
>
> Exactly the process described with the PRAO object can already be achieved
> using Suggested Label.
>
> Adrian
> ----- Original Message -----
> From: "Rajaraman B" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, February 13, 2002 1:54 AM
> Subject: Re: New draft
>
> > Hi,
> > I think Mr.Wang Hui has explained the Independent Label Provisioning
> > method explained in MPLS architecture (RFC-3031). But, in RSVP-TE and
> > CR-LDP, we use Ordered Label Provisioning method (started by egress
> > node).
> >
> > So, I think there is a difference in Wang-Hui draft and GMPLS-RSVP-TE-06
> > draft.
> >
> > Regards,
> > Rajaraman. B
> >
> > On Tuesday 12 February 2002 6:42 am, you wrote:
> > > Wang,
> > > Your draft seems to ignore Suggested Label which facilitates (with
> > > suitable implementation details) exactly the function you require.
> > > Regards,
> > > Adrian
> > > ----- Original Message -----
> > > From: "Wang Hui" <[email-masked]>
> > > To: <[email-masked]>
> > > Sent: Sunday, February 10, 2002 5:42 AM
> > > Subject: New draft
> > >
> > > > Hello all,
> > > >
> > > > A new draft named as "Add a 'parallel resource allocation style
> > > > object' to GMPLS signaling - RSVP-TE and CR-LDP"
> > > >
> > > > This draft suggests a new object implemented into GMPLS signaling
set
> > > > in order to provide fast LSP establishing speed.
> > > >
> > > > The URL is :
> > >
> > >
http://www.ietf.org/internet-drafts/draft-hwang-gmpls-signaling-paralle
> > >l-00 .txt
> > >
> > > > All are welcome to have a discussion over it.
> > > > Please send your comments to : [email-masked]
> > > >
> > > > best regards,
> > > > Wang
> > > > --
> > > >  Wang Hui
> > > >  InfoNet Lab, USTC
> > > >  http://mail.ustc.edu.cn/~whui
> > > >  Tel: +86-551-3603634

Delivery-date: Thu, 14 Feb 2002 06:59:33 -0800
From: Rajaraman B <[email-masked]>
Organization: HCL Technologies Ltd
To: "Adrian Farrel" <[email-masked]>
Subject: Re: New draft
Date: Thu, 14 Feb 2002 20:31:17 +0530
Cc: [email-masked]

Hi Adrian,
	In which draft they have give like that. I did not find this sentence in 
GMPLS architecture draft. can you please the specfic draft?

	Another thing, I want to ask you is that why is Independent label 
provisioning not possible in optical network (that is, in GMPLS)? can you 
please explain that?

Regards,
Rajaraman. B

On Thursday 14 February 2002 8:04 pm, you wrote:
> No, I believe I am right.
>
> Section 4 explicitly says "That is to say, the nodes along a lightpath will
> do their local resource allocation one by one."
>
> This is not a requirement in GMPLS.
>
> Exactly the process described with the PRAO object can already be achieved
> using Suggested Label.
>
> Adrian
> ----- Original Message -----
> From: "Rajaraman B" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, February 13, 2002 1:54 AM
> Subject: Re: New draft
>
> > Hi,
> > I think Mr.Wang Hui has explained the Independent Label Provisioning
> > method explained in MPLS architecture (RFC-3031). But, in RSVP-TE and
> > CR-LDP, we use Ordered Label Provisioning method (started by egress
> > node).
> >
> > So, I think there is a difference in Wang-Hui draft and GMPLS-RSVP-TE-06
> > draft.
> >
> > Regards,
> > Rajaraman. B
> >
> > On Tuesday 12 February 2002 6:42 am, you wrote:
> > > Wang,
> > > Your draft seems to ignore Suggested Label which facilitates (with
> > > suitable implementation details) exactly the function you require.
> > > Regards,
> > > Adrian
> > > ----- Original Message -----
> > > From: "Wang Hui" <[email-masked]>
> > > To: <[email-masked]>
> > > Sent: Sunday, February 10, 2002 5:42 AM
> > > Subject: New draft
> > >
> > > > Hello all,
> > > >
> > > > A new draft named as "Add a 'parallel resource allocation style
> > > > object' to GMPLS signaling - RSVP-TE and CR-LDP"
> > > >
> > > > This draft suggests a new object implemented into GMPLS signaling set
> > > > in order to provide fast LSP establishing speed.
> > > >
> > > > The URL is :
> > >
> > > http://www.ietf.org/internet-drafts/draft-hwang-gmpls-signaling-paralle
> > >l-00 .txt
> > >
> > > > All are welcome to have a discussion over it.
> > > > Please send your comments to : [email-masked]
> > > >
> > > > best regards,
> > > > Wang
> > > > --
> > > >  Wang Hui
> > > >  InfoNet Lab, USTC
> > > >  http://mail.ustc.edu.cn/~whui
> > > >  Tel: +86-551-3603634

Envelope-to: [email-masked]
Delivery-date: Thu, 14 Feb 2002 06:38:47 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Rajaraman B" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: New draft
Date: Thu, 14 Feb 2002 09:34:37 -0500

No, I believe I am right.

Section 4 explicitly says "That is to say, the nodes along a lightpath will do
their local resource allocation one by one."

This is not a requirement in GMPLS.

Exactly the process described with the PRAO object can already be achieved using
Suggested Label.

Adrian
----- Original Message -----
From: "Rajaraman B" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 13, 2002 1:54 AM
Subject: Re: New draft

> Hi,
> I think Mr.Wang Hui has explained the Independent Label Provisioning
> method explained in MPLS architecture (RFC-3031). But, in RSVP-TE and CR-LDP,
> we use Ordered Label Provisioning method (started by egress node).
>
> So, I think there is a difference in Wang-Hui draft and GMPLS-RSVP-TE-06
> draft.
>
> Regards,
> Rajaraman. B
>
> On Tuesday 12 February 2002 6:42 am, you wrote:
> > Wang,
> > Your draft seems to ignore Suggested Label which facilitates (with suitable
> > implementation details) exactly the function you require.
> > Regards,
> > Adrian
> > ----- Original Message -----
> > From: "Wang Hui" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Sunday, February 10, 2002 5:42 AM
> > Subject: New draft
> >
> > > Hello all,
> > >
> > > A new draft named as "Add a 'parallel resource allocation style object'
> > > to GMPLS signaling - RSVP-TE and CR-LDP"
> > >
> > > This draft suggests a new object implemented into GMPLS signaling set in
> > > order to provide fast LSP establishing speed.
> > >
> > > The URL is :
> >
> > http://www.ietf.org/internet-drafts/draft-hwang-gmpls-signaling-parallel-00
> >.txt
> >
> > > All are welcome to have a discussion over it.
> > > Please send your comments to : [email-masked]
> > >
> > > best regards,
> > > Wang
> > > --
> > >  Wang Hui
> > >  InfoNet Lab, USTC
> > >  http://mail.ustc.edu.cn/~whui
> > >  Tel: +86-551-3603634

Delivery-date: Wed, 13 Feb 2002 11:41:26 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Cc: RFC Editor <[email-masked]>, Scott Bradner <[email-masked]>
Subject: Long Lists of authors/editors
Date: Wed, 13 Feb 2002 16:38:10 +0100

CCAMP WG,

I just noticed the posting of

  draft-ietf-ccamp-oli-reqts-00.txt
  draft-ietf-ccamp-lmp-wdm-00.txt

You may want to check out a new/recent RFC-Editor policy at: 

   http://www.rfc-editor.org/policy.html

and then change accordingly

Bert 

Delivery-date: Wed, 13 Feb 2002 04:11:35 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-oli-reqts-00.txt
Date: Wed, 13 Feb 2002 07:08:55 -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		: TITLE:  Optical Link Interface Requirements
	Author(s)	: A. Fredette et al.
	Filename	: draft-ietf-ccamp-oli-reqts-00.txt
	Pages		: 13
	Date		: 12-Feb-02
	
The emergence of transparent optical switches, together with a 
movement towards more dynamic, multi-vendor networks, has introduced 
a need for information sharing between optical line systems and 
client devices.  The information that needs to be shared includes 
link status and link properties.  We call this interface the Optical 
Link Interface (OLI).  In this document, we provide high-level 
requirements for the OLI.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-oli-reqts-00.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-oli-reqts-00.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-oli-reqts-00.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-oli-reqts-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-oli-reqts-00.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, 13 Feb 2002 04:11:32 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-wdm-00.txt
Date: Wed, 13 Feb 2002 07:08:49 -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		: Link Management Protocol (LMP) for DWDM Optical Line 
                          Systems
	Author(s)	: A. Fredette et al.
	Filename	: draft-ietf-ccamp-lmp-wdm-00.txt
	Pages		: 20
	Date		: 12-Feb-02
	
A suite of protocols is being developed in the IETF to allow 
networks consisting of photonic switches (PXCs), optical 
crossconnects (OXCs), routers, switches, DWDM optical line systems 
(OLSs), and optical add-drop multiplexors (OADMs) to use an MPLS-
based control plane to dynamically provision resources and to 
provide network survivability using protection and restoration 
techniques.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-wdm-00.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-lmp-wdm-00.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-lmp-wdm-00.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-lmp-wdm-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-wdm-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 12 Feb 2002 22:57:02 -0800
From: Rajaraman B <[email-masked]>
Organization: HCL Technologies Ltd
To: "Adrian Farrel" <[email-masked]>, [email-masked]
Subject: Re: New draft
Date: Wed, 13 Feb 2002 12:24:29 +0530
Cc: [email-masked]

Hi,
	I think Mr.Wang Hui has explained the Independent Label Provisioning 
method explained in MPLS architecture (RFC-3031). But, in RSVP-TE and CR-LDP, 
we use Ordered Label Provisioning method (started by egress node).

	So, I think there is a difference in Wang-Hui draft and GMPLS-RSVP-TE-06 
draft.

Regards,
Rajaraman. B

On Tuesday 12 February 2002 6:42 am, you wrote:
> Wang,
> Your draft seems to ignore Suggested Label which facilitates (with suitable
> implementation details) exactly the function you require.
> Regards,
> Adrian
> ----- Original Message -----
> From: "Wang Hui" <[email-masked]>
> To: <[email-masked]>
> Sent: Sunday, February 10, 2002 5:42 AM
> Subject: New draft
>
> > Hello all,
> >
> > A new draft named as "Add a 'parallel resource allocation style object'
> > to GMPLS signaling - RSVP-TE and CR-LDP"
> >
> > This draft suggests a new object implemented into GMPLS signaling set in
> > order to provide fast LSP establishing speed.
> >
> > The URL is :
>
> http://www.ietf.org/internet-drafts/draft-hwang-gmpls-signaling-parallel-00
>.txt
>
> > All are welcome to have a discussion over it.
> > Please send your comments to : [email-masked]
> >
> > best regards,
> > Wang
> > --
> >  Wang Hui
> >  InfoNet Lab, USTC
> >  http://mail.ustc.edu.cn/~whui
> >  Tel: +86-551-3603634

Envelope-to: [email-masked]
Delivery-date: Mon, 11 Feb 2002 17:15:26 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Wang Hui" <[email-masked]>, <[email-masked]>
Subject: Re: New draft 
Date: Mon, 11 Feb 2002 20:12:22 -0500

Wang,
Your draft seems to ignore Suggested Label which facilitates (with suitable
implementation details) exactly the function you require.
Regards,
Adrian
----- Original Message -----
From: "Wang Hui" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, February 10, 2002 5:42 AM
Subject: New draft

> Hello all,
>
> A new draft named as "Add a 'parallel resource allocation style object' to
> GMPLS signaling - RSVP-TE and CR-LDP"
>
> This draft suggests a new object implemented into GMPLS signaling set in
> order to provide fast LSP establishing speed.
>
> The URL is :
>
http://www.ietf.org/internet-drafts/draft-hwang-gmpls-signaling-parallel-00.txt
>
>
> All are welcome to have a discussion over it.
> Please send your comments to : [email-masked]
>
> best regards,
> Wang
> --
>  Wang Hui
>  InfoNet Lab, USTC
>  http://mail.ustc.edu.cn/~whui
>  Tel: +86-551-3603634
>
>
>

Delivery-date: Sun, 10 Feb 2002 02:55:39 -0800
Date: Sun, 10 Feb 2002 18:42:17 +0800 (CST)
From: Wang Hui <[email-masked]>
To: <[email-masked]>
Subject: New draft 

Hello all,

A new draft named as "Add a 'parallel resource allocation style object' to
GMPLS signaling - RSVP-TE and CR-LDP"

This draft suggests a new object implemented into GMPLS signaling set in
order to provide fast LSP establishing speed.

The URL is :
http://www.ietf.org/internet-drafts/draft-hwang-gmpls-signaling-parallel-00.txt

All are welcome to have a discussion over it.
Please send your comments to : [email-masked]

best regards,
Wang
--
 Wang Hui
 InfoNet Lab, USTC
 http://mail.ustc.edu.cn/~whui
 Tel: +86-551-3603634

Delivery-date: Fri, 08 Feb 2002 07:23:16 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Maarten Vissers <[email-masked]>
Cc: ccamp <[email-masked]>
Subject: RE: SONET/SDH label agreement?
Date: Fri, 8 Feb 2002 16:22:44 +0100 

> ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_sdhgroup.html
(note -  I can't find this document on the IETF web site anymore)

It is under: http://www.ietf.org/IESG/liaison.html
and to be specific: http://www.ietf.org/IESG/LIAISON/ITU-TD44.txt

Or so I think.

Bert

Delivery-date: Fri, 08 Feb 2002 07:04:52 -0800
Cc: ccamp <[email-masked]>, "Wijnen, Bert" <[email-masked]>, Scott Bradner <[email-masked]>
Date: Fri, 08 Feb 2002 16:00:30 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>
Original-CC: ccamp <[email-masked]>, "Wijnen, Bert" <[email-masked]>, Scott Bradner <[email-masked]>
Subject: SONET/SDH label agreement?

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

Vijay, Kireeti,

Almost two months ago we met in a small team to address the issues hindering the
completion of draft-ietf-ccamp-gmpls-sonet-sdh and
draft-ietf-ccamp-gmpls-sonet-sdh-extensions. 
When this meeting ended, I was convinced we had reached agreement on the way to
continue:

- move "Appendix 1 - Signal Type Values Extension For Group Signals" from the
sonet-sdh document to the sonet-sdh-extensions document;

- modify the sonet-sdh document such that the SDH traffic parameters and label
will be used for SONET signals for which there exists an identical SDH signal.
SONET signals for which there is no SDH equivalent will keep using the SONET
specific traffic parameters and label.

Afterwards I noticed that the latter agreement is interpreted in different ways:

A) keep both SONET and SDH specific traffic parameter and label specifications
in the sonet-sdh document, and let the equipment manufacturer and/or operator
choose if the traffic parameters and label for a SONET signal (with identical
SDH signal) will use the SONET specification or the SDH specification. This
results in a "double coding" scheme for SONET signals.

B) modify the sonet-sdh document such that there is one set of traffic
parameters and label for each SONET signal. For those SONET signals with
identical SDH signal (i.e. all SONET signals except VT-3) only the SDH traffic
parameters and label will be specified. For those SONET signals that do not have
an SDH equivalent (i.e. VT-3) the SONET traffic parameters and label will be
specified. This results in a "single coding" scheme for SONET signals.

This dual interpretation is again hindering the completion of the sonet-sdh
document.

Note that interpretation B) sufficiently meets the request from ITU-T SG15 as
laid down in the its communications statement and as such was an acceptable
compromise for me.
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_sdhgroup.html
(note -  I can't find this document on the IETF web site anymore)
Interpretation A) will at the best require two coding schemes to be supported in
each equipment, and at the worst will cause interworking problems. It doesn't
meet the request from ITU-T SG15. If I would have been aware of this
interpretation, I would not have agreed with it.

May I ask you for your understanding/interpretation on this matter.

Regards,

Maarten
--------------AF9BAACEB7071F24B3C34A5C
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;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------AF9BAACEB7071F24B3C34A5C--

Delivery-date: Wed, 06 Feb 2002 00:09:44 -0800
Subject: draft-vasseur-mpls-computation-rsvp-02.txt
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: [email-masked]
Date: Wed, 6 Feb 2002 09:03:53 +0100

Hi,

I have been reiterating some inter-area traffic engineering work and I have
some questions regarding the above mentioned draft. The draft describes an
approach to allow the ingress to obtain a path from a path computation
server (PCS), possibly through relaying to message between different path
computation servers. This raises two questions:

1) resource reservation: Because the Path Computation Requests (PCR) may
need to be relayed between different Path Computation Servers (PCS), it is
possible that some time elapses between the selection of the path and the
actual setup. This can introduce race conditions in the path computation
process. In order to avoid these, it may be appropriate to optionally allow
the Path Computation Client (PCC) to ask for a reservation of the resources
while processing the PCR. When the PCS finds out that it is on the
requested path, it can continue the path setup which was already initiated.
When it isn't, reserved resources can be torn down with the reply message.
This can be achieved by:
- treating the PCR as an ordinary RSVP-TE Path message with additional
objects
- using Resv plus additional objects for a reply without resource
reservation teardown
- using ResvTear plus additional objects for a reply with resource
reservation teardown
This scenario may involve the need to send a path message from a PCS (ABR)
to more than one node. Then a problem arises with the REQUEST_ID because
intermediate nodes can not make the distinction between the path messages
(they have the same SESSION and SENDER_TEMPLATE objects). Two solutions are
feasible:
- use different LSP_IDs for every path message
- put a unique address of the PCS in the sender address
Some suggested modifications to the existing text for the last solution are
provided below

2) multi-stage computation: In a broader context (broader than pure
multi-area TE), PCSs may be used to compute sections of a path going over
different hierarchy levels in a network. Such levels may be introduced by
the use of FA-LSPs. Now, in this case, the specification of the complete
path may involve more than two PCS hops (as is typically the case with
multi-area TE because of the specifics of OSPF and ISIS hierarchy).
Guaranteeing the optimal path will then require the concatenation of
multiple LSP sections and the request for a very large number of path
computations. When setting up the paths at the same time, it can be shown
that the number of setup messages is linear with the number of edge nodes,
and this in each section.

Looking forward to discussion,
Sven.

Suggested text for the role of the PCC and PCS is given below

Path Computation Client (PCC)
1) The Path Computation Request (PCR) message is a Path message with
   - Tunnel_ID: unique identifier
   - Extended_Tunnel_ID: set to the ingress of the tunnel
   - egress address: egress tunnel address
   - sender address: set to an address belonging to the tunnel ingress
(maybe be same as Extended_Tunnel_ID if only one PCR
     is sent.
   - LSP_ID: unique identifier
   The PCC sends a request to one or more PCSs containing:
        a) already specified objects defined in [9] characterizing the
           request, and
        b) new objects defined in the present draft related
           to the request.
   The router alert option may be set in order to reserve resources during
the setup.
2) Upon receiving a positive reply to the PCR
        a) if a single path was requested, the one that is returned will
have been established
        b) if multiple paths were requested, select the desired one(s) and
initiate path setup
3) Upon receiving a negative reply to the PCR
        a) if multiple PCSs were contacted, wait for other replies
        b) else send new request to another PCS (can be suggested in
negative reply)

Path Computation Server (PCS)
1) Upon receiving a PCR
        a) Compute the desired path(s)
        b) If a single path was requested and the PCS is on the optimal
path towards the destination
           - continue path setup by sending Path message to destination
        c) If a single path was requested and the PCS is on the optimal
path towards one or more possible next PCS
           - continue the path setup
           - replace sender address with one of its own addresses and send
Path message to one or more next hop PCSs.
             Note that a different sender address must be chosen for each
other PCS.
        d) If multiple paths were requested and found, send a ResvTear
message containing positive reply (list of paths)
        e) If single path was requested and not found, send a ResvTear
message containing negative reply and possibly a
           suggestion for other PCS

2) Upon receiving a positive reply to the PCR
        a) if a single path was requested, the one that is returned will
have been established
        b) if multiple paths were requested, select the desired one(s),
concatenate and send to PCC

3) Upon receiving a negative reply to the PCR
        a) if multiple PCSs were contacted, wait for other replies
        b) else send new request to another PCS (can be suggested in
negative reply)
        c) if all PCSs give negative reply, send negative reply to PCC

Delivery-date: Tue, 05 Feb 2002 06:55:08 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
Date: Tue, 05 Feb 2002 09:50:24 -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 et al.
	Filename	: draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
	Pages		: 10
	Date		: 04-Feb-02
	
This document specifies encoding of extensions to the OSPF routing
protocol in support of Generalized Multi-Protocol Label Switching
(GMPLS).  The description of the extensions is specified in [GMPLS-
ROUTING].

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-ospf-gmpls-extensions-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: Sun, 03 Feb 2002 21:39:42 -0800
Date: Sun, 3 Feb 2002 21:35:19 -0800 (PST)
From: Pyda Srisuresh <[email-masked]>
Subject: Revised OSPF-TE draft 
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]

Folks,

I posted Rev 2 of the OSPF-TE draft sometime back. It is available
in the draft repositories as draft-srisuresh-ospf-te-02.txt. 

We now have a working implementation of this draft in a packet network.
TE neighbors are now detected through the Options field in Hello/DD
packets. TE-LSA flooding is limited to TE-only neightbors. TE LSAs
are successfully processed into a TE-LSDB for use by a CSPF path 
computation algorithm. I would encourage others to implement and 
deploy the OSPF-TE in a variety of networks. I will be glad to offer 
any help I could with implementation issues. I look forward to
hearing from you.

OSPF-TE is a single unified TE extensions draft, dedicated to
disseminating Traffic Engineering metrics within a single-area 
(or) multi-area  packet networks and non-packet networks (i.e.,
usable in conjunction with MPLS and GMPLS alike). 
Further, the OSPF-TE protocol does not mandate that it be deployed 
in a dedicated TE or a dedicated Non-TE network. The protocol 
adapts itself in a mixed network so the TE nodes are not impacted
by the non-TE traffic and vice-versa, effectively making it SLA
enforceable.

Besides having a working implementation, the draft went through a
number of changes in the text and draft organization. Below are the 
highlights. FYI.

    1. A revised and expanded design motivation section is moved
       forward to section 4 (from section 11 in the previous rev!). 
    2. Transition strategy for implementations currently using
       Opaque LSAs is also moved forward to section 6.
    3. Reordered the sequence in which TE LSAs are listed.
    4. Fixed the error on TE-summary router LSA flooding scope.
    5. Text clean-ups in Abstract, Motiviations, terminology
       and transition-Path sections.
    6. Numerous other clarifications.

Thanks. Have a nice day.

regards,
suresh

=====

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com

Delivery-date: Fri, 01 Feb 2002 01:19:57 -0800
From: "Vinay Vernekar" <[email-masked]>
To: <[email-masked]>
Subject: Doubt regarding the control channel seperation in GMPLS CR-LDP.
Date: Fri, 1 Feb 2002 14:46:36 +0530

This is a multi-part message in MIME format.

------=_NextPartTM-000-e84baf76-16e4-11d6-a217-0000e22173f5
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_006F_01C1AB2F.3FAD0200"

------=_NextPart_000_006F_01C1AB2F.3FAD0200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
I have a couple of doubts regarding the control channel seperation in =
GMPLS CR-LDP (draft-ietf-mpls-generalized-cr-ldp-05.txt). For simplicity =
let me consider a scenario of setting up a uni-directional path between =
two nodes having seperate data channel and control channel and neither =
link bundling nor unnumbered links is being considered.
1) What is the significance of IPv4 next hop address in the Interface ID =
TLV? Is this the next hop address for a Forwarding Equivalence =
Class(FEC) F1?
2) What does the Logical Interface ID in the Interface ID TLV specify? =
Is this the interface ID of the control channel at the downstream LSR? =
If yes how does the upstream node know about it in prior?
3) How does the upstream LSR knows about the data channel id at the =
downstream node, since the draft mentions data channels are specified =
from the view point of the sender of the Mapping message i.e. downstream =
node.

Thanks in advance for your reply.
Regards
Vinay

------=_NextPart_000_006F_01C1AB2F.3FAD0200
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial>Hello,</FONT></DIV>
<DIV><FONT face=3DArial>I have a couple of doubts regarding the control =
channel=20
seperation in GMPLS CR-LDP (draft-ietf-mpls-generalized-cr-ldp-05.txt). =
For=20
simplicity let me consider a scenario of setting up a uni-directional =
path=20
between two nodes having seperate data channel and control channel and =
neither=20
link bundling nor unnumbered links is being considered.</FONT></DIV>
<DIV><FONT face=3DArial>1) What is the significance of IPv4 next hop =
address in=20
the Interface ID TLV? Is this the next hop address for a Forwarding =
Equivalence=20
Class(FEC) F1?</FONT></DIV>
<DIV><FONT face=3DArial>2) What does the Logical Interface ID in the =
Interface ID=20
TLV specify? Is this the interface ID of the control channel at the =
downstream=20
LSR? If yes how does the upstream node know about it in =
prior?</FONT></DIV>
<DIV><FONT face=3DArial>3) How does the upstream LSR knows about the =
data channel=20
id at the downstream node, since the draft&nbsp;mentions data channels =
are=20
specified from the view point of the sender of the Mapping message i.e.=20
downstream node.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial>Thanks in advance for your reply.</FONT></DIV>
<DIV><FONT face=3DArial>Regards</FONT></DIV>
<DIV><FONT face=3DArial>Vinay</FONT><FONT =
face=3DArial></DIV></FONT></BODY></HTML>

------=_NextPart_000_006F_01C1AB2F.3FAD0200--

------=_NextPartTM-000-e84baf76-16e4-11d6-a217-0000e22173f5
Content-Type: text/plain;
	name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_Disclaimer.txt"

**************************Disclaimer************************************

Information contained in this E-MAIL being proprietary to Wipro Limited
is 'privileged' and 'confidential' and intended for use only by the
individual or entity to which it is addressed. You are notified that any
use, copying or dissemination of the information contained in the E-MAIL
in any manner whatsoever is strictly prohibited.

 ********************************************************************

------=_NextPartTM-000-e84baf76-16e4-11d6-a217-0000e22173f5--