Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 19:19:30 -0800 Message-ID: <3C7EF282.F649FF5D@research.att.com> Date: Thu, 28 Feb 2002 22:16:18 -0500 From: Charles Kalmanek MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 18:05:38 -0800 Date: Fri, 01 Mar 2002 11:01:06 +0900 From: Yoshihiko SUEMURA To: ccamp@ops.ietf.org Subject: Re: CCAMP Protection/Restoration Design Team Message-Id: <20020301105643.4E41.Y-SUEMURA@bp.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 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: y-suemura@bp.jp.nec.com Phone: +81 44 856 8109, FAX: +81 44 856 8071 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 17:01:27 -0800 Date: Thu, 28 Feb 2002 19:59:06 -0500 (EST) From: Scott Bradner Message-Id: <200203010059.g210x6r14115@newdev.harvard.edu> To: ccamp@ops.ietf.org, ptmorgan@emea.att.com Subject: Re: IETF & ITU-T Cc: neil.2.harrison@bt.com > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 14:50:32 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105691608@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Morgan, Peter (Engineering)" , "'ccamp@ops.ietf.org'" Subject: RE: IETF & ITU-T Date: Thu, 28 Feb 2002 23:50:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:ptmorgan@emea.att.com] > Sent: Thursday, February 28, 2002 11:16 PM > To: 'ccamp@ops.ietf.org' > Cc: 'neil.2.harrison@bt.com' > 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." > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 14:45:10 -0800 Message-ID: <3C7EB2C0.47F5D2E7@lucent.com> Date: Thu, 28 Feb 2002 15:44:16 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Morgan, Peter (Engineering)" CC: "'ccamp@ops.ietf.org'" , "'neil.2.harrison@bt.com'" Subject: Re: IETF & ITU-T Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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." Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 14:22:18 -0800 Message-ID: <3C607C74DE0F8E4CBC06F74EC0492A90042E5E@gblonmsx01> From: "Morgan, Peter (Engineering)" To: "'ccamp@ops.ietf.org'" Cc: "'neil.2.harrison@bt.com'" Subject: IETF & ITU-T Date: Thu, 28 Feb 2002 22:16:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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." Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 14:16:12 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF1271056915FD@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg Subject: new WG co-chair Date: Thu, 28 Feb 2002 23:13:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 14:08:40 -0800 Message-ID: From: neil.2.harrison@bt.com To: erosen@cisco.com, Shahram_Davari@pmc-sierra.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 22:08:05 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 14:08:36 -0800 Message-ID: From: neil.2.harrison@bt.com To: sjtrowbridge@lucent.com Cc: ccamp@ops.ietf.org, bmoore1@lucent.com Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 22:08:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:sjtrowbridge@lucent.com] > Sent: 28 February 2002 17:28 > To: Shahram Davari > Cc: 'erosen@cisco.com'; 'Randy Bush'; Cuevas, Enrique G, ALASO; > ccamp@ops.ietf.org; 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 14:08:33 -0800 Message-ID: From: neil.2.harrison@bt.com To: swallow@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 22:08:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:swallow@cisco.com] > Sent: 28 February 2002 17:12 > To: Shahram Davari > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org; > swallow@cisco.com > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 14:05:38 -0800 Message-ID: <3C7EA139.2E6CE1A7@att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0D5CD2AFDCD9D8EAE4318B87" Date: Thu, 28 Feb 2002 16:29:29 -0500 From: Luis Aguirre-Torres To: Kireeti Kompella Cc: ccamp-wg 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:kireeti@juniper.net] > Sent: Sunday, February 24, 2002 7:11 PM > To: Wijnen, Bert (Bert) > Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg; > 'sob@harvard.edu' > 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 1)

Luis

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

From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Sunday, February 24, 2002 7:11 PM
To: Wijnen, Bert (Bert)
Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg;
'sob@harvard.edu'
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-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 12:50:19 -0800 Message-ID: From: neil.2.harrison@bt.com To: erosen@cisco.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 20:49:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:erosen@cisco.com] > Sent: 28 February 2002 14:59 > To: Shahram Davari > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > 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. > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 12:50:17 -0800 Message-ID: From: neil.2.harrison@bt.com To: tnadeau@cisco.com, mazad@nortelnetworks.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 20:49:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:tnadeau@cisco.com] > Sent: 28 February 2002 16:53 > To: Mina Azad > Cc: ccamp@ops.ietf.org > 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:mgibson@orchestream.com] > > > Sent: Thursday, February 28, 2002 10:32 AM > > > To: ccamp@ops.ietf.org > > > 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:erosen@cisco.com] > > > Sent: 28 February 2002 14:59 > > > To: Shahram Davari > > > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > > > 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. > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 12:34:39 -0800 Message-Id: <200202282033.PAA25816@erosen-u10.cisco.com> To: Shahram Davari cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 28 Feb 2002 15:33:58 -0500 From: Eric Rosen 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 12:34:36 -0800 Message-ID: From: "Mannie, Eric" To: 'Richard Rabbat' , "'Michael I Mandelberg(Isaac)'" , ccamp@ops.ietf.org Subject: RE: Question re: reference in GMPLS-ARCH Date: Thu, 28 Feb 2002 21:32:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks, noted. Eric -----Original Message----- From: Richard Rabbat [mailto:rabbat@fla.fujitsu.com] Sent: Thursday, February 28, 2002 8:52 PM To: 'Michael I Mandelberg(Isaac)'; ccamp@ops.ietf.org 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Michael I Mandelberg(Isaac) Sent: Thursday, February 28, 2002 11:15 AM To: ccamp@ops.ietf.org 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 12:08:05 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5D1@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 12:07:16 -0800 MIME-Version: 1.0 Content-Type: text/plain 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 11:53:06 -0800 From: "Richard Rabbat" To: "'Michael I Mandelberg\(Isaac\)'" , Subject: RE: Question re: reference in GMPLS-ARCH Date: Thu, 28 Feb 2002 11:52:29 -0800 Message-ID: <002601c1c091$743cd820$623ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Michael I Mandelberg(Isaac) Sent: Thursday, February 28, 2002 11:15 AM To: ccamp@ops.ietf.org 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 Envelope-to: ccamp-data@psg.com 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 Message-ID: <35BD167AAD17F34F84B265D795185567E886A0@OCCLUST03EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C08E.6414756A" Thread-Topic: SONET/SDH label agreement for IETF, ITU-T and OIF Thread-Index: AcG9lAe62DVgqN29So6e9ixOl39Y7gCx01Bw From: "Lazer, Monica A, ALCNS" To: "Kireeti Kompella" , "Wijnen, Bert (Bert)" Cc: "Mannie, Eric" , , , "ccamp-wg" , 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:kireeti@juniper.net] Sent: Sunday, February 24, 2002 7:11 PM To: Wijnen, Bert (Bert) Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu' 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

Definitely = 1.


-----Original=20 Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Se= nt:=20 Sunday, February 24, 2002 7:11 PM
To: Wijnen, Bert (Bert)
Cc: = Mannie,=20 Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu';=20 ccamp-wg;
'sob@harvard.edu'
Subject: RE: SONET/SDH label agreement = for=20 IETF, ITU-T and OIF




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

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

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

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

Here's what I = thought we had=20 agreed:

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

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

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

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

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

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

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

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

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

Thanks,
Kireeti.

------_=_NextPart_001_01C1C08E.6414756A-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 11:18:01 -0800 Message-ID: From: "Michael I Mandelberg(Isaac)" To: ccamp@ops.ietf.org Subject: Question re: reference in GMPLS-ARCH Date: Thu, 28 Feb 2002 14:15:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 10:03:49 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5CD@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Randy Bush'" , Mina Azad Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 10:03:22 -0800 MIME-Version: 1.0 Content-Type: text/plain 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:randy@psg.com] > Sent: Thursday, February 28, 2002 12:11 PM > To: Mina Azad > Cc: ccamp@ops.ietf.org > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 10:00:37 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5CC@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" Cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 09:59:44 -0800 MIME-Version: 1.0 Content-Type: text/plain 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 09:44:02 -0800 Message-Id: <200202281742.MAA17656@erosen-u10.cisco.com> To: Shahram Davari cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 28 Feb 2002 12:42:56 -0500 From: Eric Rosen 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 ... Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 09:28:44 -0800 Message-ID: <3C7E68AA.42CFC7B5@lucent.com> Date: Thu, 28 Feb 2002 10:28:10 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Shahram Davari CC: "'erosen@cisco.com'" , "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org, Brian Moore Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 09:12:50 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mina Azad Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Message-Id: 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: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 09:12:48 -0800 Message-Id: <200202281712.MAA21547@telescope.cisco.com> To: Shahram Davari cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 12:12:27 -0500 From: George Swallow 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 09:06:24 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5CB@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 09:01:50 -0800 MIME-Version: 1.0 Content-Type: text/plain Eric, > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, February 28, 2002 9:59 AM > To: Shahram Davari > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > 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 > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 08:56:08 -0800 Message-Id: <4.3.2.7.2.20020228114948.02c72d28@161.44.167.72> Date: Thu, 28 Feb 2002 11:53:20 -0500 To: "Mina Azad" From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >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:mgibson@orchestream.com] > > Sent: Thursday, February 28, 2002 10:32 AM > > To: ccamp@ops.ietf.org > > 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:erosen@cisco.com] > > Sent: 28 February 2002 14:59 > > To: Shahram Davari > > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > > 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 08:40:44 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401FF2008@zcard0ka.ca.nortel.com> From: "Mina Azad" To: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 11:40:30 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C076.A291C2A0" 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:mgibson@orchestream.com] > Sent: Thursday, February 28, 2002 10:32 AM > To: ccamp@ops.ietf.org > 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:erosen@cisco.com] > Sent: 28 February 2002 14:59 > To: Shahram Davari > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > 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" 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.

Regards,

Mina Azad

> -----Original Message-----
> From: Gibson, Mark [mailto:mgibson@orchestream.com]
> Sent: Thursday, February 28, 2002 10:32 AM
> To: ccamp@ops.ietf.org
> 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:erosen@cisco.com]
> Sent: 28 February 2002 14:59
> To:   Shahram Davari
> Cc:   'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org
> 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 08:39:15 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401FF1FFD@zcard0ka.ca.nortel.com> From: "David Allan" To: "Thomas D. Nadeau" Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 11:38:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C076.667D5BD0" 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: ccamp@ops.ietf.org 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" RE: draft-bonica-tunneltrace-02

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: ccamp@ops.ietf.org
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-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 08:26:43 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401FF1FA9@zcard0ka.ca.nortel.com> From: "David Allan" To: Loa Andersson Cc: erosen@cisco.com, Shahram Davari , "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 11:25:33 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C074.8B602D80" 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:loa.andersson@utfors.se] > Sent: Thursday, February 28, 2002 11:06 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: erosen@cisco.com; Shahram Davari; 'Randy Bush'; Cuevas, Enrique = G, > ALASO; ccamp@ops.ietf.org > 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 loa.andersson@utfors.se > WWW www.utfors.se >=20 >=20 ------_=_NextPart_001_01C1C074.8B602D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-bonica-tunneltrace-02

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.

Dave

> -----Original Message-----
> From: Loa Andersson [mailto:loa.andersson@utfors.se]
> Sent: Thursday, February 28, 2002 11:06 = AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: erosen@cisco.com; Shahram Davari; 'Randy = Bush'; Cuevas, Enrique G,
> ALASO; ccamp@ops.ietf.org
> 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=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           = loa.andersson@utfors.se
> = WWW           &nb= sp; www.utfors.se
>
>

------_=_NextPart_001_01C1C074.8B602D80-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 08:11:44 -0800 Message-Id: <4.3.2.7.2.20020228110911.01f62b98@161.44.167.72> Date: Thu, 28 Feb 2002 11:10:58 -0500 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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:tnadeau@cisco.com] > > Sent: Thursday, February 28, 2002 9:24 AM > > To: Shahram Davari > > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > > 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:randy@research.att.com] > > > > Sent: Thursday, February 28, 2002 8:56 AM > > > > To: Shahram Davari > > > > Cc: Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > > > > 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 08:08:01 -0800 Message-ID: <3C7E557F.10606@utfors.se> Date: Thu, 28 Feb 2002 17:06:23 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: David Allan CC: erosen@cisco.com, Shahram Davari , 'Randy Bush' , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 loa.andersson@utfors.se WWW www.utfors.se Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 07:51:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Loa Andersson Cc: ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Message-Id: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 07:48:13 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5CA@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Randy Bush'" Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 07:47:58 -0800 MIME-Version: 1.0 Content-Type: text/plain > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 07:46:59 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401FF1EB9@zcard0ka.ca.nortel.com> From: "David Allan" To: Loa Andersson Cc: erosen@cisco.com, Shahram Davari , "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 10:46:32 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C06F.181AFFD0" 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:loa.andersson@utfors.se] > Sent: Thursday, February 28, 2002 10:32 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: erosen@cisco.com; Shahram Davari; 'Randy Bush'; Cuevas, Enrique G, > ALASO; ccamp@ops.ietf.org > 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:erosen@cisco.com] > > > Sent: Thursday, February 28, 2002 9:59 AM > > > To: Shahram Davari > > > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > > > 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 loa.andersson@utfors.se > WWW www.utfors.se > > ------_=_NextPart_001_01C1C06F.181AFFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-bonica-tunneltrace-02

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:loa.andersson@utfors.se]
> Sent: Thursday, February 28, 2002 10:32 = AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: erosen@cisco.com; Shahram Davari; 'Randy = Bush'; Cuevas, Enrique G,
> ALASO; ccamp@ops.ietf.org
> 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:erosen@cisco.com]
> >  > Sent: Thursday, February 28, = 2002 9:59 AM
> >  > To: Shahram Davari
> >  > Cc: 'Randy Bush'; Cuevas, = Enrique G, ALASO; ccamp@ops.ietf.org
> >  > 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=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           = loa.andersson@utfors.se
> = WWW           &nb= sp; www.utfors.se
>
>

------_=_NextPart_001_01C1C06F.181AFFD0-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 07:40:44 -0800 Message-ID: <3C7E511F.AB6F1883@cisco.com> Date: Thu, 28 Feb 2002 10:47:43 -0500 From: Srinivasa Datari MIME-Version: 1.0 To: ccamp mailing list , jplang@calient.net CC: rbradfor@cisco.com, muralidb@cisco.com Subject: Link Summary Nack issue Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 07:38:25 -0800 Message-ID: From: "Gibson, Mark" To: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 15:31:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:erosen@cisco.com] Sent: 28 February 2002 14:59 To: Shahram Davari Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 07:32:11 -0800 Message-ID: <3C7E4D5B.7050107@utfors.se> Date: Thu, 28 Feb 2002 16:31:39 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: David Allan CC: erosen@cisco.com, Shahram Davari , 'Randy Bush' , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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:erosen@cisco.com] > > Sent: Thursday, February 28, 2002 9:59 AM > > To: Shahram Davari > > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > > 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 loa.andersson@utfors.se WWW www.utfors.se Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 07:20:09 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Shahram Davari Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Message-Id: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 07:10:20 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401FF1DB6@zcard0ka.ca.nortel.com> From: "David Allan" To: erosen@cisco.com, Shahram Davari Cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 10:09:34 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C069.EE320880" 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:erosen@cisco.com] > Sent: Thursday, February 28, 2002 9:59 AM > To: Shahram Davari > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > 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 RE: draft-bonica-tunneltrace-02

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:erosen@cisco.com]
> Sent: Thursday, February 28, 2002 9:59 = AM
> To: Shahram Davari
> Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; = ccamp@ops.ietf.org
> 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 06:59:15 -0800 Message-Id: <200202281458.JAA08688@erosen-u10.cisco.com> To: Shahram Davari cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 28 Feb 2002 09:58:32 -0500 From: Eric Rosen 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 06:59:12 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5C8@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 06:57:55 -0800 MIME-Version: 1.0 Content-Type: text/plain 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; ccamp@ops.ietf.org > 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:tnadeau@cisco.com] > > Sent: Thursday, February 28, 2002 9:24 AM > > To: Shahram Davari > > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > > 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:randy@research.att.com] > > > > Sent: Thursday, February 28, 2002 8:56 AM > > > > To: Shahram Davari > > > > Cc: Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > > > > 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. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 06:25:46 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5C4@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 06:25:28 -0800 MIME-Version: 1.0 Content-Type: text/plain Please refer to previous emails by me and David Allan. Most of them are listed there. -Shahram > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, February 28, 2002 9:24 AM > To: Shahram Davari > Cc: 'Randy Bush'; Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > 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:randy@research.att.com] > > > Sent: Thursday, February 28, 2002 8:56 AM > > > To: Shahram Davari > > > Cc: Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > > > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 06:24:24 -0800 Message-Id: <4.3.2.7.2.20020228092248.01f0e3e0@161.44.167.72> Date: Thu, 28 Feb 2002 09:23:32 -0500 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >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:randy@research.att.com] > > Sent: Thursday, February 28, 2002 8:56 AM > > To: Shahram Davari > > Cc: Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > > 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 06:17:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Shahram Davari Cc: "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Message-Id: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 06:03:23 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5C3@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Randy Bush'" Cc: "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 06:02:51 -0800 MIME-Version: 1.0 Content-Type: text/plain 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:randy@research.att.com] > Sent: Thursday, February 28, 2002 8:56 AM > To: Shahram Davari > Cc: Cuevas, Enrique G, ALASO; ccamp@ops.ietf.org > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 05:56:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Shahram Davari Cc: "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Message-Id: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 05:55:56 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5C2@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Randy Bush'" , "Cuevas, Enrique G, ALASO" Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 05:54:04 -0800 MIME-Version: 1.0 Content-Type: text/plain 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:randy@research.att.com] > Sent: Wednesday, February 27, 2002 7:45 PM > To: Cuevas, Enrique G, ALASO > Cc: ccamp@ops.ietf.org > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 04:07:36 -0800 Message-ID: From: neil.2.harrison@bt.com To: pingpan@juniper.net Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 28 Feb 2002 12:02:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Feb 2002 04:07:33 -0800 Message-Id: <200202281206.HAA17890@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020227124949.I-D@ietf.org> 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: <20020227124949.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com 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 Message-ID: <28F05913385EAC43AF019413F674A0170B2603@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: WG (rough) consensus) [was RE: WG document status] Thread-Index: AcG/86Vc28sThEIjQUOEN+VWNNJT2wABlgMA From: "Ash, Gerald R (Jerry), ALASO" To: "Wijnen, Bert (Bert)" , "Kireeti Kompella" Cc: "Ash, Gerald R (Jerry), ALASO" , "Ben Mack-Crane" , 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 17:04:13 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105691393@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , "Ash, Gerald R (Jerry), ALASO" Cc: Ben Mack-Crane , ccamp@ops.ietf.org Subject: FW: WG (rough) consensus) [was RE: WG document status] Date: Thu, 28 Feb 2002 02:02:45 +0100 MIME-Version: 1.0 Content-Type: text/plain 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 16:45:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Cuevas, Enrique G, ALASO" Cc: Subject: RE: draft-bonica-tunneltrace-02 Message-Id: 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 Envelope-to: ccamp-data@psg.com 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 Message-ID: <28F05913385EAC43AF019413F674A017015DC441@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-bonica-tunneltrace-02 Thread-Index: AcG9lihrPZWiEo2qTdiKkXk+Q8gdxwCUn/DA From: "Cuevas, Enrique G, ALASO" To: (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 _______________ ecuevas@att.com -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Sunday, February 24, 2002 7:47 PM To: David Allan Cc: neil.2.harrison@bt.com; Ronald.P.Bonica@wcom.com; ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 11:58:10 -0800 Message-ID: From: neil.2.harrison@bt.com To: pingpan@juniper.net Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 27 Feb 2002 19:55:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 10:58:45 -0800 Date: Wed, 27 Feb 2002 10:58:12 -0800 (PST) From: Kireeti Kompella To: "Ash, Gerald R (Jerry), ALASO" cc: Ben Mack-Crane , ccamp@ops.ietf.org Subject: RE: WG document status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 10:48:27 -0800 Message-ID: <3C7D2A49.105@juniper.net> Date: Wed, 27 Feb 2002 10:49:45 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit neil.2.harrison@bt.com 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: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 10:30:31 -0800 Date: Wed, 27 Feb 2002 10:28:51 -0800 (PST) From: Kireeti Kompella Message-Id: <200202271828.KAA24677@kummer.juniper.net> To: ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 09:36:25 -0800 Message-ID: <2135200C183FD5119588009027DE572354DD18@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: Routing drafts Date: Wed, 27 Feb 2002 09:35:37 -0800 MIME-Version: 1.0 Content-Type: text/plain 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:kireeti@juniper.net] Sent: Tuesday, February 26, 2002 9:52 PM To: Bernstein, Greg Cc: ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 09:27:39 -0800 Message-ID: <36EF020032CFD411B7B400508B55E590012BF20B@milan.turinnetworks.com> From: Hai Vodinh To: 'Maarten Vissers' , "Mannie, Eric" Cc: "'Wijnen, Bert (Bert)'" , ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Wed, 27 Feb 2002 09:27:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Kireeti, (1) for me. Regards, Hai -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 09:20:13 -0800 Message-ID: From: neil.2.harrison@bt.com To: pingpan@juniper.net Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 27 Feb 2002 17:18:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 08:47:26 -0800 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624101B8D@OCCLUST02EVS1.ugd.att.com> From: "Brungard, Deborah A, ALASO" To: "'Zhi-Wei Lin'" , "Mannie, Eric" Cc: "Ash, Gerald R (Jerry), ALASO" , Kireeti Kompella , Ben Mack-Crane , ccamp@ops.ietf.org Subject: RE: WG document status Date: Wed, 27 Feb 2002 11:32:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:zwlin@lucent.com] Sent: Wednesday, February 27, 2002 9:18 AM To: Mannie, Eric Cc: Ash, Gerald R (Jerry), ALASO; Kireeti Kompella; Ben Mack-Crane; ccamp@ops.ietf.org; 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:gash@att.com] > Sent: Wednesday, February 27, 2002 2:16 PM > To: Kireeti Kompella; Ben Mack-Crane > Cc: Ash, Gerald R (Jerry), ALASO; ccamp@ops.ietf.org > 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 08:27:14 -0800 Message-ID: <3C7D091F.7090403@juniper.net> Date: Wed, 27 Feb 2002 08:28:15 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: kireeti@juniper.net, Ronald.P.Bonica@wcom.com, ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit neil.2.harrison@bt.com 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 08:02:29 -0800 Message-ID: <3C7D0327.8030501@juniper.net> Date: Wed, 27 Feb 2002 08:02:47 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: loa.andersson@utfors.se, kireeti@juniper.net, Ronald.P.Bonica@wcom.com, ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Neil, neil.2.harrison@bt.com 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 06:22:06 -0800 Cc: "'Wijnen, Bert (Bert)'" , ccamp-wg Message-ID: <3C7C1C90.E37E95C7@lucent.com> Date: Wed, 27 Feb 2002 00:38:56 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" Original-CC: "'Wijnen, Bert (Bert)'" , ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: multipart/mixed; boundary="------------BCCFB865BFD943FA5A3F1034" 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:mvissers@lucent.com 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 06:20:49 -0800 Cc: "'Stephen Trowbridge'" , "Mannie, Eric" , "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , "'Kireeti Kompella'" Message-ID: <3C7C29C6.41C2BCD6@lucent.com> Date: Wed, 27 Feb 2002 01:35:18 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Heiles Juergen Original-CC: "'Stephen Trowbridge'" , "Mannie, Eric" , "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , "'Kireeti Kompella'" Subject: Re: Simple solution to terminate the discussion about SONET versus SDH Content-Type: multipart/mixed; boundary="------------98FC49479DC6DB6A98D55D18" 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:sjtrowbridge@lucent.com] > > Sent: Tuesday, February 26, 2002 4:22 PM > > To: Mannie, Eric > > Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert); > > 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; '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:mvissers@lucent.com 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 06:17:05 -0800 Message-ID: <3C7CEA7D.40302@lucent.com> Date: Wed, 27 Feb 2002 09:17:33 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020204 MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Ash, Gerald R (Jerry), ALASO'" , Kireeti Kompella , Ben Mack-Crane , ccamp@ops.ietf.org, Deborah Brungard Subject: Re: WG document status Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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:gash@att.com] > Sent: Wednesday, February 27, 2002 2:16 PM > To: Kireeti Kompella; Ben Mack-Crane > Cc: Ash, Gerald R (Jerry), ALASO; ccamp@ops.ietf.org > 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 06:13:57 -0800 Message-ID: <3C7C314F.AA13C9D5@lucent.com> Date: Wed, 27 Feb 2002 02:07:27 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status] Content-Type: multipart/mixed; boundary="------------DBCC5E5A8F1CA1DCCC54303B" 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: osama@nortelnetworks.com > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Tuesday, February 26, 2002 8:43 AM > To: Wijnen, Bert (Bert) > Cc: Mannie, Eric; 'Mak, L (Leen)'; ccamp@ops.ietf.org; 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 : dimitri.papadimitriou@alcatel.be > 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:mvissers@lucent.com 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 05:43:05 -0800 Message-ID: From: "Mannie, Eric" To: "'Ash, Gerald R (Jerry), ALASO'" , Kireeti Kompella , Ben Mack-Crane Cc: ccamp@ops.ietf.org Subject: RE: WG document status Date: Wed, 27 Feb 2002 14:40:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:gash@att.com] Sent: Wednesday, February 27, 2002 2:16 PM To: Kireeti Kompella; Ben Mack-Crane Cc: Ash, Gerald R (Jerry), ALASO; ccamp@ops.ietf.org 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 Envelope-to: ccamp-data@psg.com 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 Message-ID: <28F05913385EAC43AF019413F674A017C88806@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: WG dcoument status Thread-Index: AcG/VMv/ghgeBplwQRG+582sQYv2JAAOpbOg From: "Ash, Gerald R (Jerry), ALASO" To: "Kireeti Kompella" , "Ben Mack-Crane" Cc: "Ash, Gerald R (Jerry), ALASO" , 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 04:54:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BF71.683B6B3E" From: Silman Lionel To: "'ccamp@ops.ietf.org'" 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:LionelS@enavis.com ------_=_NextPart_001_01C1BF71.683B6B3E Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Re: SONET/SDH label agreement for IETF, ITU-T and OIF

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:LionelS@enavis.com


------_=_NextPart_001_01C1BF71.683B6B3E-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 04:54:20 -0800 Message-ID: From: neil.2.harrison@bt.com To: loa.andersson@utfors.se Cc: pingpan@juniper.net, kireeti@juniper.net, Ronald.P.Bonica@wcom.com, ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 27 Feb 2002 12:53:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:loa.andersson@utfors.se] > Sent: 27 February 2002 12:28 > To: neil.2.harrison@bt.com > Cc: pingpan@juniper.net; kireeti@juniper.net; > Ronald.P.Bonica@wcom.com; > ccamp@ops.ietf.org > 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 > > neil.2.harrison@bt.com 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:loa.andersson@utfors.se] > >>Sent: 27 February 2002 08:53 > >>To: Ping Pan > >>Cc: 'Kireeti Kompella'; Ronald.P.Bonica@wcom.com; ccamp@ops.ietf.org > >>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:kireeti@juniper.net] > >>>>>Sent: Sunday, February 24, 2002 7:47 PM > >>>>>To: David Allan > >>>>>Cc: neil.2.harrison@bt.com; Ronald.P.Bonica@wcom.com; > >>>>> > >>ccamp@ops.ietf.org > >> > >>>>>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 loa.andersson@utfors.se > >>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 loa.andersson@utfors.se > WWW www.utfors.se > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 04:46:40 -0800 Message-ID: <3C7C9CEF.6552038A@netit.alcatel.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 27 Feb 2002 09:46:39 +0100 From: Gert Grammel To: ccamp@ops.ietf.org CC: Kireeti Kompella 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:kireeti@juniper.net] > Sent: Sunday, February 24, 2002 4:11 PM > To: Wijnen, Bert (Bert) > Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg; > 'sob@harvard.edu' > 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:Gert.Grammel@netit.alcatel.it Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 04:28:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BF5F.B52BBB68" From: Silman Lionel To: ccamp-wg 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:LionelS@enavis.com ------_=_NextPart_001_01C1BF5F.B52BBB68 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Re: SONET/SDH label agreement for IETF, ITU-T and OIF

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:LionelS@enavis.com


------_=_NextPart_001_01C1BF5F.B52BBB68-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 04:28:04 -0800 Message-ID: <3C7CD0BD.5080000@utfors.se> Date: Wed, 27 Feb 2002 13:27:41 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: pingpan@juniper.net, kireeti@juniper.net, Ronald.P.Bonica@wcom.com, ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 neil.2.harrison@bt.com 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:loa.andersson@utfors.se] >>Sent: 27 February 2002 08:53 >>To: Ping Pan >>Cc: 'Kireeti Kompella'; Ronald.P.Bonica@wcom.com; ccamp@ops.ietf.org >>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:kireeti@juniper.net] >>>>>Sent: Sunday, February 24, 2002 7:47 PM >>>>>To: David Allan >>>>>Cc: neil.2.harrison@bt.com; Ronald.P.Bonica@wcom.com; >>>>> >>ccamp@ops.ietf.org >> >>>>>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 loa.andersson@utfors.se >>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 loa.andersson@utfors.se WWW www.utfors.se Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 04:24:21 -0800 Message-Id: <200202271223.HAA17844@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020226130430.I-D@ietf.org> 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: <20020226130430.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 03:51:42 -0800 Message-ID: From: neil.2.harrison@bt.com To: kireeti@juniper.net, dallan@nortelnetworks.com Cc: Ronald.P.Bonica@wcom.com, ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 27 Feb 2002 11:50:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 02:56:23 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF1271056911A4@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kireeti Kompella Cc: ccamp-wg Subject: RE: Routing drafts Date: Wed, 27 Feb 2002 11:55:34 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 02:28:25 -0800 Message-ID: From: neil.2.harrison@bt.com To: loa.andersson@utfors.se, pingpan@juniper.net Cc: kireeti@juniper.net, Ronald.P.Bonica@wcom.com, ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 27 Feb 2002 10:27:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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:loa.andersson@utfors.se] > Sent: 27 February 2002 08:53 > To: Ping Pan > Cc: 'Kireeti Kompella'; Ronald.P.Bonica@wcom.com; ccamp@ops.ietf.org > 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:kireeti@juniper.net] > >>> Sent: Sunday, February 24, 2002 7:47 PM > >>> To: David Allan > >>> Cc: neil.2.harrison@bt.com; Ronald.P.Bonica@wcom.com;=20 > ccamp@ops.ietf.org > >>> 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 loa.andersson@utfors.se > WWW www.utfors.se >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 01:34:41 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105691139@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg Subject: FW: Choices in IETF Protocols Date: Wed, 27 Feb 2002 10:33:45 +0100 MIME-Version: 1.0 Content-Type: text/plain I would like to comment on a piece of an email from Eric > -----Original Message----- > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Sent: Tuesday, February 26, 2002 6:45 PM > To: 'Stephen Trowbridge'; Dimitri.Papadimitriou@alcatel.be > Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; > 'vijay@umbc.edu'; ccamp-wg; > 'sob@harvard.edu'; '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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 01:18:35 -0800 Message-ID: <3C7CA3C5.EF51D034@npd.hcltech.com> Date: Wed, 27 Feb 2002 14:45:49 +0530 From: S Ramesh Organization: HCL Technologies Limited MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: ccamp-wg Subject: Re: LMP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 00:53:09 -0800 Message-ID: <3C7C9E54.9050202@utfors.se> Date: Wed, 27 Feb 2002 09:52:36 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: Ping Pan CC: 'Kireeti Kompella' , Ronald.P.Bonica@wcom.com, ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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:kireeti@juniper.net] >>> Sent: Sunday, February 24, 2002 7:47 PM >>> To: David Allan >>> Cc: neil.2.harrison@bt.com; Ronald.P.Bonica@wcom.com; ccamp@ops.ietf.org >>> 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 loa.andersson@utfors.se WWW www.utfors.se Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 00:29:48 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF12710569104C@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg Subject: LMP Date: Tue, 26 Feb 2002 23:26:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Feb 2002 00:26:40 -0800 Message-ID: From: Heiles Juergen To: "'Mannie, Eric'" , "'Stephen Trowbridge'" Cc: "'mvissers@lucent.com'" , "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , "'Kireeti Kompella'" Subject: RE: Simple solution to terminate the discussion about SONET versu s SDH Date: Wed, 27 Feb 2002 09:22:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:Eric.Mannie@ebone.com] > Sent: Tuesday, February 26, 2002 5:31 PM > To: 'Stephen Trowbridge' > Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert); > 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; '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:sjtrowbridge@lucent.com] > Sent: Tuesday, February 26, 2002 4:22 PM > To: Mannie, Eric > Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert); > 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; '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. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 22:04:30 -0800 Date: Tue, 26 Feb 2002 22:03:22 -0800 (PST) From: Kireeti Kompella To: Ben Mack-Crane cc: ccamp@ops.ietf.org Subject: Re: WG dcoument status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 21:53:08 -0800 Date: Tue, 26 Feb 2002 21:52:21 -0800 (PST) From: Kireeti Kompella To: "Bernstein, Greg" cc: ccamp@ops.ietf.org Subject: RE: Routing drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 21:29:05 -0800 Date: Tue, 26 Feb 2002 21:28:17 -0800 (PST) From: Kireeti Kompella To: Vishal Sharma cc: ccamp@ops.ietf.org, Greg Bernstein , Eric Mannie Subject: RE: WG dcoument status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 21:02:00 -0800 Reply-To: From: "Vishal Sharma" To: "ccamp-wg" Cc: "Wijnen, Bert \(Bert\)" , "Mannie, Eric" Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 23:56:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]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:Eric.Mannie@ebone.com] > > 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:bwijnen@lucent.com] > > 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. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 17:16:02 -0800 Message-ID: <3C7C2DDD.8040009@lucent.com> Date: Tue, 26 Feb 2002 19:52:45 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 16:54:42 -0800 Message-ID: <36EF020032CFD411B7B400508B55E590015E9B9E@milan.turinnetworks.com> From: Dan Guo To: 'Kireeti Kompella' , "Wijnen, Bert (Bert)" Cc: "Mannie, Eric" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 16:51:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 2) -Dan -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Sunday, February 24, 2002 4:11 PM To: Wijnen, Bert (Bert) Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu' 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 16:54:40 -0800 Message-Id: <5.0.2.5.2.20020227094721.02c3bec0@172.19.83.4> Date: Wed, 27 Feb 2002 09:52:39 +0900 To: Kireeti Kompella , "Wijnen, Bert (Bert)" From: Tomohiro Otani Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Cc: "Mannie, Eric" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: otani@kddilabs.jp ------------------------------------ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 16:26:58 -0800 Message-ID: From: "Cheng, Dean" To: 'Kireeti Kompella' , "Wijnen, Bert (Bert)" Cc: "Mannie, Eric" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 16:23:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 2) > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Sunday, February 24, 2002 4:11 PM > To: Wijnen, Bert (Bert) > Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg; > 'sob@harvard.edu' > 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. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 15:31:50 -0800 Message-ID: <3C7C1A89.234ECC5@lucent.com> Date: Tue, 26 Feb 2002 18:30:17 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "1" Yangguang Ayan Banerjee wrote: > > Vote for 2. > > Ayan > > > -----Original Message----- > >From: Wijnen, Bert (Bert) > >[mailto:bwijnen@lucent.com] > >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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 14:08:30 -0800 Message-ID: <3C7C06DA.3040300@lucent.com> Date: Tue, 26 Feb 2002 17:06:18 -0500 From: Siva Sankaranarayanan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 13:36:25 -0800 Message-ID: <3C7BFEF2.4B1CCB11@nayna.com> Date: Tue, 26 Feb 2002 13:32:34 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Kireeti Kompella CC: "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: multipart/mixed; boundary="------------3F2935D6FC685171F786E0E6" 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:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;; fn:Sudheer Dharanikota end:vcard --------------3F2935D6FC685171F786E0E6-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 13:28:25 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC0B9B62@nimbus> From: Ayan Banerjee To: ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 13:27:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Vote for 2. Ayan > -----Original Message----- >From: Wijnen, Bert (Bert) >[mailto:bwijnen@lucent.com] >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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 13:20:28 -0800 Message-ID: <05707214338CD5119BFF0040A5B170D3D59A31@mail3.tellium.com> From: Debanjan Saha To: ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 16:04:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Vote for 2. Debanjan > -----Original Message----- >From: Wijnen, Bert (Bert) >[mailto:bwijnen@lucent.com] >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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 11:11:55 -0800 Message-ID: <3C7BDDFC.4DF76E0E@tellabs.com> Date: Tue, 26 Feb 2002 13:11:56 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: WG dcoument status Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 10:24:32 -0800 Message-Id: <4.3.2.7.2.20020226102921.00b7b498@mira1.cisco.com> Date: Tue, 26 Feb 2002 10:30:06 -0800 To: ccamp-wg From: Suresh Katukam Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Vote for (2) > -----Original Message----- >From: Wijnen, Bert (Bert) >[mailto:bwijnen@lucent.com] >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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 10:24:14 -0800 Message-ID: <3C7BD245.E31632BE@alcatel.be> Date: Tue, 26 Feb 2002 19:21:57 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - IPO NA (Antwerpen) MIME-Version: 1.0 To: Stephen Trowbridge Cc: "Mannie, Eric" , "'Heiles Juergen'" , "'mvissers@lucent.com'" , "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , "'Kireeti Kompella'" Subject: Re: Simple solution to terminate the discussion about SONET versus SDH Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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 > > Dimitri.Papadimitriou@alcatel.be 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:sjtrowbridge@lucent.com] > > > Sent: Tuesday, February 26, 2002 4:22 PM > > > To: Mannie, Eric > > > Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert); > > > 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; '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 : dimitri.papadimitriou@alcatel.be > > 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 : dimitri.papadimitriou@alcatel.be 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 10:16:59 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105691000@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jonathan.sadler@tellabs.com, Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: WG dcoument status Date: Tue, 26 Feb 2002 19:16:38 +0100 MIME-Version: 1.0 Content-Type: text/plain > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 10:16:48 -0800 Message-ID: <3C7BCFE8.AF007BDC@tellabs.com> Date: Tue, 26 Feb 2002 12:11:52 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: WG dcoument status Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: <3C1F67D1.32D01F90@tellabs.com>, <3C1F670C.C51923FC@tellabs.com>, <3C1F6BF5.16151FE6@tellabs.com>, <3C1F6918.4A866073@tellabs.com>, <3C1F6B8F.54CC2ECF@tellabs.com>, and <3C1F6835.D112FABF@tellabs.com>) 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 ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 10:10:22 -0800 Message-ID: <3C7BCFA7.169FCE03@tellabs.com> Date: Tue, 26 Feb 2002 12:10:47 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Routing drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 09:54:46 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105690FF7@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp@ops.ietf.org Subject: RE: draft-ietf-ccamp-lmp-02.txt Date: Tue, 26 Feb 2002 18:54:25 +0100 MIME-Version: 1.0 Content-Type: text/plain 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:bwijnen@lucent.com] > Sent: Tuesday, February 26, 2002 11:55 AM > To: ccamp@ops.ietf.org > Subject: draft-ietf-ccamp-lmp-02.txt > > > From Kireeti's "wg document status" email > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: Monday, February 25, 2002 2:52 AM > > To: ccamp@ops.ietf.org > > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 09:47:36 -0800 Message-ID: From: "Mannie, Eric" To: 'Stephen Trowbridge' , Dimitri.Papadimitriou@alcatel.be Cc: 'Heiles Juergen' , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , 'Kireeti Kompella' Subject: RE: Simple solution to terminate the discussion about SONET versu s SDH Date: Tue, 26 Feb 2002 18:45:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:sjtrowbridge@lucent.com] Sent: Tuesday, February 26, 2002 6:29 PM To: Dimitri.Papadimitriou@alcatel.be Cc: Mannie, Eric; 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert); 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; '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 Dimitri.Papadimitriou@alcatel.be 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:sjtrowbridge@lucent.com] > > Sent: Tuesday, February 26, 2002 4:22 PM > > To: Mannie, Eric > > Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert); > > 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; '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 : dimitri.papadimitriou@alcatel.be > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 09:31:15 -0800 Message-ID: <3C7BC6BE.5070709@juniper.net> Date: Tue, 26 Feb 2002 09:32:46 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: "'Kireeti Kompella'" CC: Ronald.P.Bonica@wcom.com, ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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:kireeti@juniper.net] >>Sent: Sunday, February 24, 2002 7:47 PM >>To: David Allan >>Cc: neil.2.harrison@bt.com; Ronald.P.Bonica@wcom.com; >>ccamp@ops.ietf.org >>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. >> >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 09:29:44 -0800 Message-ID: <3C7BC5E3.DAB650F7@lucent.com> Date: Tue, 26 Feb 2002 10:29:07 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: "Mannie, Eric" , "'Heiles Juergen'" , "'mvissers@lucent.com'" , "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , "'Kireeti Kompella'" Subject: Re: Simple solution to terminate the discussion about SONET versus SDH Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Dimitri.Papadimitriou@alcatel.be 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:sjtrowbridge@lucent.com] > > Sent: Tuesday, February 26, 2002 4:22 PM > > To: Mannie, Eric > > Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert); > > 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; '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 : dimitri.papadimitriou@alcatel.be > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 09:23:52 -0800 Message-ID: <3C7BC4C2.1545E0CC@tellabs.com> Date: Tue, 26 Feb 2002 11:24:18 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com MIME-Version: 1.0 To: Kireeti Kompella CC: "Wijnen, Bert (Bert)" , "Mannie, Eric" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 09:23:45 -0800 Message-ID: <3C7BC4BD.E4AC1F34@tellabs.com> Date: Tue, 26 Feb 2002 11:24:13 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: WG dcoument status Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 09:23:28 -0800 Message-ID: <3FA472EE4C0C1A49BA7D491CA7D39A031BD5E6@srnex01.sd.osicom.com> From: "Zhang, Zhensheng" To: "'Dimitri.Papadimitriou@alcatel.be'" , "Wijnen, Bert (Bert)" Cc: ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 09:22:28 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BEEA.2C67774C" 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 : dimitri.papadimitriou@alcatel.be 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 RE: SONET/SDH label agreement for IETF, ITU-T and OIF

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 : dimitri.papadimitriou@alcatel.be
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html<= /FONT>
Address: Alcatel - Optical NA, Fr. Wellesplein, 1 =
         = B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 = 3434361

------_=_NextPart_001_01C1BEEA.2C67774C-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 09:15:39 -0800 Message-ID: <3C7BC234.6CD630FC@alcatel.be> Date: Tue, 26 Feb 2002 18:13:24 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - IPO NA (Antwerpen) MIME-Version: 1.0 To: "Mannie, Eric" , "'Stephen Trowbridge'" , "'Heiles Juergen'" Cc: "'mvissers@lucent.com'" , "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , "'Kireeti Kompella'" Subject: Re: Simple solution to terminate the discussion about SONET versus SDH Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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:sjtrowbridge@lucent.com] > Sent: Tuesday, February 26, 2002 4:22 PM > To: Mannie, Eric > Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert); > 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; '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 : dimitri.papadimitriou@alcatel.be 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 08:46:17 -0800 Message-ID: <3C7BBB72.54304DC4@lucent.com> Date: Tue, 26 Feb 2002 09:44:34 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Heiles Juergen'" , "'mvissers@lucent.com'" , "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , "'Kireeti Kompella'" Subject: Re: Simple solution to terminate the discussion about SONET versus SDH Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 08:32:29 -0800 Message-ID: From: "Mannie, Eric" To: 'Stephen Trowbridge' Cc: 'Heiles Juergen' , "'mvissers@lucent.com'" , "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , 'Kireeti Kompella' Subject: RE: Simple solution to terminate the discussion about SONET versu s SDH Date: Tue, 26 Feb 2002 17:30:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:sjtrowbridge@lucent.com] Sent: Tuesday, February 26, 2002 4:22 PM To: Mannie, Eric Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert); 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; '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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 08:25:19 -0800 Message-ID: <3C7BB5EA.2EEC7BF7@tellabs.com> Date: Tue, 26 Feb 2002 10:20:58 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: CCAMP Protection/Restoration Design Team Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 08:21:29 -0800 Message-ID: <2135200C183FD5119588009027DE572354DCFD@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: Don Fedyk , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Routing drafts Date: Tue, 26 Feb 2002 08:20:46 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BEE1.8BC929A0" 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:dwfedyk@nortelnetworks.com] Sent: Tuesday, February 26, 2002 6:04 AM To: Bernstein, Greg; Kireeti Kompella; ccamp@ops.ietf.org 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:GregB@ciena.com ] >Sent: Monday, February 25, 2002 8:32 PM >To: Fedyk, Don [BL60:1A00:EXCH]; Kireeti Kompella; ccamp@ops.ietf.org >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:dwfedyk@nortelnetworks.com ] >Sent: Monday, February 25, 2002 4:07 PM >To: Bernstein, Greg; Kireeti Kompella; ccamp@ops.ietf.org >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 RE: Routing drafts

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:dwfedyk@nortelnetworks.com]
Sent: Tuesday, February = 26, 2002 6:04 AM
To: Bernstein, Greg; = Kireeti Kompella; ccamp@ops.ietf.org
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:GregB@ciena.com]
>Sent: Monday, = February 25, 2002 8:32 PM
>To: Fedyk, Don [BL60:1A00:EXCH]; Kireeti Kompella; ccamp@ops.ietf.org =
>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:dwfedyk@nortelnetworks= .com]
>Sent: Monday, = February 25, 2002 4:07 PM
>To: Bernstein, = Greg; Kireeti Kompella; ccamp@ops.ietf.org
>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-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 08:13:20 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC10E201@nimbus> From: John Drake To: 'Bala Rajagopalan' , "'Mannie, Eric '" , "''Wijnen, Bert (Bert)' '" , 'ccamp-wg ' Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 08:12:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 2) -----Original Message----- From: Bala Rajagopalan [mailto:BRaja@tellium.com] 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:bwijnen@lucent.com] 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 08:13:17 -0800 Message-ID: <3C7BB2ED.3149ED98@tellabs.com> Date: Tue, 26 Feb 2002 10:08:14 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Kireeti Kompella , Vijay Gill CC: ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 08:04:52 -0800 Message-ID: <2135200C183FD5119588009027DE572354DCFB@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "Wijnen, Bert (Bert)" , "Mannie, Eric" , ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 08:04:01 -0800 MIME-Version: 1.0 Content-Type: text/plain 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:bwijnen@lucent.com] 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:Eric.Mannie@ebone.com] > 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:bwijnen@lucent.com] > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 07:57:05 -0800 Message-ID: <710197BD5AF9D4119E4400508BCFA136033B27D0@zcard04u.ca.nortel.com> From: "Osama Aboul-Magd" To: "Wijnen, Bert (Bert)" , ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 10:56:38 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BEDE.2C8C64A0" 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: osama@nortelnetworks.com -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 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" RE: SONET/SDH label agreement for IETF, ITU-T and OIF

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: osama@nortelnetworks.com

 -----Original Message-----
From:   Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
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-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 07:55:46 -0800 Message-ID: From: Heiles Juergen To: "'Mannie, Eric'" , "'Wijnen, Bert (Bert)'" , ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 16:54:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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:Eric.Mannie@ebone.com] > 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:bwijnen@lucent.com] > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 07:51:53 -0800 Message-ID: From: Sasha Vainshtein To: "'Mannie, Eric'" , "'Wijnen, Bert (Bert)'" , ccamp-wg 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 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > 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:bwijnen@lucent.com] > 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. > Envelope-to: ccamp-data@psg.com 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 Message-ID: <28F05913385EAC43AF019413F674A0170B25F6@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: SONET/SDH label agreement for IETF, ITU-T and OIF Thread-Index: AcG+1+pLMBLDk2QYSFu61OJF7GHSvgABF6Vg From: "Ash, Gerald R (Jerry), ALASO" To: "Kireeti Kompella" , "Wijnen, Bert (Bert)" Cc: "Ash, Gerald R (Jerry), ALASO" , "ccamp-wg" I support (1) Jerry Ash =20 > PLEASE respond with just (1), (2) or (3), and avoid long diatribes! >=20 > Thanks, > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 07:47:35 -0800 From: ananth.nagarajan@mail.sprint.com Date: Tue, 26 Feb 2002 09:46:56 -0600 Message-Id: Subject: RE: draft-bonica-tunneltrace-02 MIME-Version: 1.0 TO: kireeti@juniper.net CC: ccamp@ops.ietf.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 26 Feb 2002 09:46:56 -0600" Content-Transfer-Encoding: 7bit > > (a) it should be a WG document? Since it is in the "right spirit" :-) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 07:47:32 -0800 Message-ID: From: Heiles Juergen To: "'Stephen Trowbridge'" , "Mannie, Eric" Cc: Heiles Juergen , "'mvissers@lucent.com'" , "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , "'Kireeti Kompella'" Subject: RE: Simple solution to terminate the discussion about SONET versu s SDH Date: Tue, 26 Feb 2002 16:45:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:sjtrowbridge@lucent.com] > Sent: Tuesday, February 26, 2002 4:22 PM > To: Mannie, Eric > Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert); > 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; '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. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 07:26:52 -0800 Message-ID: <3C7BA92C.AFFA6363@lucent.com> Date: Tue, 26 Feb 2002 08:26:36 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Wijnen, Bert (Bert)'" , ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 07:23:13 -0800 Message-ID: <3C7BA832.90CCF443@lucent.com> Date: Tue, 26 Feb 2002 08:22:26 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Heiles Juergen'" , "'mvissers@lucent.com'" , "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , "'Kireeti Kompella'" Subject: Re: Simple solution to terminate the discussion about SONET versus SDH Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 07:10:15 -0800 Message-ID: From: Heiles Juergen To: "'Kireeti Kompella'" , "Wijnen, Bert (Bert)" Cc: "Mannie, Eric" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 16:09:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" I vote 1) Juergen > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, February 25, 2002 1:11 AM > To: Wijnen, Bert (Bert) > Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg; > 'sob@harvard.edu' > 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. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 07:08:27 -0800 Message-ID: From: "Natale, Robert C (Bob)" To: ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 10:08:10 -0500 MIME-Version: 1.0 Content-Type: text/plain 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 07:07:16 -0800 Message-ID: From: "Mannie, Eric" To: "'Wijnen, Bert (Bert)'" , ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 16:05:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:bwijnen@lucent.com] 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 06:54:11 -0800 Message-ID: <3C7BAFBA.D3ED2C04@lucent.com> Date: Tue, 26 Feb 2002 09:54:34 -0600 From: Eve Varma Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 06:46:48 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A5B2@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" , David Allan Cc: neil.2.harrison@bt.com, Ronald.P.Bonica@wcom.com, ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 26 Feb 2002 06:44:41 -0800 MIME-Version: 1.0 Content-Type: text/plain Kireeti, I vote for (b). -Shahram > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Sunday, February 24, 2002 7:47 PM > To: David Allan > Cc: neil.2.harrison@bt.com; Ronald.P.Bonica@wcom.com; > ccamp@ops.ietf.org > 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. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 06:29:12 -0800 Message-ID: <05707214338CD5119BFF0040A5B170D3E81FF0@mail3.tellium.com> From: Bala Rajagopalan To: "'Mannie, Eric '" , "''Wijnen, Bert (Bert)' '" , 'ccamp-wg ' Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 09:15:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:bwijnen@lucent.com] 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 06:18:28 -0800 Message-ID: <3C7B9900.52964CB3@alcatel.be> Date: Tue, 26 Feb 2002 15:17:36 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - IPO NA (Antwerpen) MIME-Version: 1.0 To: Eve Varma Cc: "Wijnen, Bert (Bert)" , "Mannie, Eric" , "'Mak, L (Leen)'" , ccamp@ops.ietf.org, Kireeti Kompella Subject: Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status] Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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 > > Dimitri.Papadimitriou@alcatel.be 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 : dimitri.papadimitriou@alcatel.be > > 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 : dimitri.papadimitriou@alcatel.be 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 06:16:12 -0800 Message-ID: <3C7B9868.92103773@alcatel.be> Date: Tue, 26 Feb 2002 15:15:04 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - IPO NA (Antwerpen) MIME-Version: 1.0 To: Osama Aboul-Magd Cc: "Wijnen, Bert (Bert)" , "Mannie, Eric" , "'Mak, L (Leen)'" , ccamp@ops.ietf.org, Kireeti Kompella Subject: Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status] Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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: osama@nortelnetworks.com > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Tuesday, February 26, 2002 8:43 AM > To: Wijnen, Bert (Bert) > Cc: Mannie, Eric; 'Mak, L (Leen)'; ccamp@ops.ietf.org; 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 : dimitri.papadimitriou@alcatel.be > 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 : dimitri.papadimitriou@alcatel.be 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 06:09:21 -0800 Message-ID: <710197BD5AF9D4119E4400508BCFA136033B2472@zcard04u.ca.nortel.com> From: "Osama Aboul-Magd" To: Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" Cc: "Mannie, Eric" , "'Mak, L (Leen)'" , ccamp@ops.ietf.org, Kireeti Kompella Subject: RE: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument s tatus] Date: Tue, 26 Feb 2002 09:08:45 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BECF.1AC4D720" 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: osama@nortelnetworks.com -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Tuesday, February 26, 2002 8:43 AM To: Wijnen, Bert (Bert) Cc: Mannie, Eric; 'Mak, L (Leen)'; ccamp@ops.ietf.org; 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 : dimitri.papadimitriou@alcatel.be 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 RE: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument = status]

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: osama@nortelnetworks.com

 -----Original Message-----
From:   Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimi= triou@alcatel.be]
Sent:   Tuesday, February 26, 2002 8:43 = AM
To:     Wijnen, Bert = (Bert)
Cc:     Mannie, Eric; 'Mak, L = (Leen)'; ccamp@ops.ietf.org; 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 : dimitri.papadimitriou@alcatel.be
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html<= /FONT>
Address: Alcatel - Optical NA, Fr. Wellesplein, 1 =
         = B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 = 3434361

------_=_NextPart_001_01C1BECF.1AC4D720-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 06:03:52 -0800 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E601792981@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: "Bernstein, Greg" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Routing drafts Date: Tue, 26 Feb 2002 09:03:33 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BECE.6058B050" 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:GregB@ciena.com] >Sent: Monday, February 25, 2002 8:32 PM >To: Fedyk, Don [BL60:1A00:EXCH]; Kireeti Kompella; ccamp@ops.ietf.org >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:dwfedyk@nortelnetworks.com] >Sent: Monday, February 25, 2002 4:07 PM >To: Bernstein, Greg; Kireeti Kompella; ccamp@ops.ietf.org >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" 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:GregB@ciena.com]
>Sent: Monday, February 25, 2002 8:32 PM
>To: Fedyk, Don [BL60:1A00:EXCH]; Kireeti Kompella; ccamp@ops.ietf.org
>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:dwfedyk@nortelnetworks.com]
>Sent: Monday, February 25, 2002 4:07 PM
>To: Bernstein, Greg; Kireeti Kompella; ccamp@ops.ietf.org
>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-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 06:03:50 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105690F21@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp@ops.ietf.org Subject: RE: draft-ietf-ccamp-lmp-02.txt Date: Tue, 26 Feb 2002 15:02:50 +0100 MIME-Version: 1.0 Content-Type: text/plain 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: ccamp@ops.ietf.org > Subject: draft-ietf-ccamp-lmp-02.txt > > > From Kireeti's "wg document status" email > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: Monday, February 25, 2002 2:52 AM > > To: ccamp@ops.ietf.org > > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 05:55:08 -0800 Message-ID: <3C7BA1DB.278DE30C@lucent.com> Date: Tue, 26 Feb 2002 08:55:23 -0600 From: Eve Varma Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: "Wijnen, Bert (Bert)" , "Mannie, Eric" , "'Mak, L (Leen)'" , ccamp@ops.ietf.org, Kireeti Kompella Subject: Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Dimitri.Papadimitriou@alcatel.be 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 : dimitri.papadimitriou@alcatel.be > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 05:45:02 -0800 Message-ID: <3C7B90E5.4EB683F0@alcatel.be> Date: Tue, 26 Feb 2002 14:43:01 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - IPO NA (Antwerpen) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: "Mannie, Eric" , "'Mak, L (Leen)'" , ccamp@ops.ietf.org, Kireeti Kompella Subject: Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status] Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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 : dimitri.papadimitriou@alcatel.be 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 05:36:48 -0800 Message-ID: From: Heiles Juergen To: "'Mannie, Eric'" , Stephen Trowbridge , "'mvissers@lucent.com'" Cc: "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , "'Kireeti Kompella'" Subject: RE: Simple solution to terminate the discussion about SONET versu s SD H Date: Tue, 26 Feb 2002 14:35:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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:Eric.Mannie@ebone.com] > Sent: Tuesday, February 26, 2002 11:17 AM > To: Stephen Trowbridge; 'Heiles Juergen'; 'mvissers@lucent.com' > Cc: Wijnen, Bert (Bert); 'vijay@umbc.edu'; ccamp-wg; > 'sob@harvard.edu'; > '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. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 04:40:20 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105690EAE@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mannie, Eric" , "'Mak, L (Leen)'" , "'Dimitri.Papadimitriou@alcatel.be'" Cc: ccamp@ops.ietf.org Subject: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument statu s] Date: Tue, 26 Feb 2002 13:39:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 04:40:16 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105690EAF@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mannie, Eric" , ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 13:39:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:Eric.Mannie@ebone.com] > 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:bwijnen@lucent.com] > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 04:38:14 -0800 Message-ID: <710197BD5AF9D4119E4400508BCFA136033B22A4@zcard04u.ca.nortel.com> From: "Osama Aboul-Magd" To: Stephen Trowbridge , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: WG dcoument status Date: Tue, 26 Feb 2002 07:37:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BEC2.4951B930" 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: osama@nortelnetworks.com -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Monday, February 25, 2002 4:40 PM To: Kireeti Kompella Cc: ccamp@ops.ietf.org 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 RE: WG dcoument status

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: osama@nortelnetworks.com

 -----Original Message-----
From:   Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
Sent:   Monday, February 25, 2002 4:40 = PM
To:     Kireeti Kompella
Cc:     = ccamp@ops.ietf.org
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-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 04:02:57 -0800 Message-Id: <200202261202.HAA24014@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020225142652.I-D@ietf.org> 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: <20020225142652.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 04:02:56 -0800 Message-Id: <200202261202.HAA24032@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020225142706.I-D@ietf.org> 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: <20020225142706.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 04:02:54 -0800 Message-Id: <200202261202.HAA23978@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020225142631.I-D@ietf.org> 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: <20020225142631.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 03:52:49 -0800 Date: Tue, 26 Feb 2002 13:03:09 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Kireeti Kompella , "Wijnen, Bert (Bert)" Cc: "Thomas D. Nadeau" , Cheenu Srinivasan , Joan Cucchiara , ccamp@ops.ietf.org, Vijay Gill , swallow@cisco.com Subject: RE: GMPLS MIB I-D updates Message-ID: <11545701.1014728589@[192.168.102.79]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline --On Tuesday, January 29, 2002 2:39 PM -0800 Kireeti Kompella 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: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 03:18:11 -0800 Message-ID: From: "Mannie, Eric" To: "'Wijnen, Bert (Bert)'" , ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 12:17:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" (2) for me Eric -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 03:11:01 -0800 Message-ID: From: "Mannie, Eric" To: "'Mak, L (Leen)'" , "'Dimitri.Papadimitriou@alcatel.be'" Cc: ccamp@ops.ietf.org Subject: RE: WG dcoument status Date: Tue, 26 Feb 2002 12:10:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:lmak@lucent.com] Sent: Tuesday, February 26, 2002 11:44 AM To: 'Dimitri.Papadimitriou@alcatel.be' Cc: ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 03:02:53 -0800 Message-ID: <3C7B6B21.D7171E90@alcatel.be> Date: Tue, 26 Feb 2002 12:01:53 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - IPO NA (Antwerpen) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: ccamp-wg Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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 : dimitri.papadimitriou@alcatel.be 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 02:55:06 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105690E03@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp@ops.ietf.org Subject: draft-ietf-ccamp-lmp-02.txt Date: Tue, 26 Feb 2002 11:54:32 +0100 MIME-Version: 1.0 Content-Type: text/plain >From Kireeti's "wg document status" email > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, February 25, 2002 2:52 AM > To: ccamp@ops.ietf.org > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 02:44:12 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127104D070BC@nl0006exch005u.nl.lucent.com> From: "Mak, L (Leen)" To: "'Dimitri.Papadimitriou@alcatel.be'" Cc: ccamp@ops.ietf.org Subject: RE: WG dcoument status Date: Tue, 26 Feb 2002 11:43:38 +0100 MIME-Version: 1.0 Content-Type: text/plain 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 02:32:58 -0800 Message-ID: From: "Mannie, Eric" To: "'Wijnen, Bert (Bert)'" , ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 11:32:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:bwijnen@lucent.com] 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 02:18:38 -0800 Message-ID: From: "Mannie, Eric" To: Stephen Trowbridge , 'Heiles Juergen' , "'mvissers@lucent.com'" Cc: "Wijnen, Bert (Bert)" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" , 'Kireeti Kompella' Subject: Simple solution to terminate the discussion about SONET versus SD H Date: Tue, 26 Feb 2002 11:17:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 01:37:44 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105690DA0@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 10:37:07 +0100 MIME-Version: 1.0 Content-Type: text/plain 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 01:19:59 -0800 Message-ID: From: Heiles Juergen To: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: RE: SDH/SONET extensions Date: Tue, 26 Feb 2002 10:19:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:kireeti@juniper.net] > Sent: Monday, February 25, 2002 5:22 PM > To: ccamp@ops.ietf.org > 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. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 01:15:09 -0800 Date: Tue, 26 Feb 2002 01:13:14 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: CCAMP 53 agenga Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 00:55:04 -0800 Date: Tue, 26 Feb 2002 00:54:51 -0800 (PST) From: Kireeti Kompella To: Stephen Trowbridge cc: ccamp@ops.ietf.org Subject: Re: WG document status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Feb 2002 00:50:56 -0800 Message-ID: From: Sasha Vainshtein To: 'Kireeti Kompella' , "Wijnen, Bert (Bert)" Cc: "Mannie, Eric" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Tue, 26 Feb 2002 10:44:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Kireeti, My two cents is (1). With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, February 25, 2002 2:11 AM > To: Wijnen, Bert (Bert) > Cc: Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; > ccamp-wg; 'sob@harvard.edu' > 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. > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 23:58:15 -0800 Date: Mon, 25 Feb 2002 23:54:30 -0800 (PST) From: Kireeti Kompella To: Stephen Trowbridge cc: "Wijnen, Bert (Bert)" , "Mannie, Eric" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 17:34:17 -0800 Message-ID: <2135200C183FD5119588009027DE572354DCF5@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: Don Fedyk , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Routing drafts Date: Mon, 25 Feb 2002 17:31:35 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BE65.54595700" 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:dwfedyk@nortelnetworks.com] Sent: Monday, February 25, 2002 4:07 PM To: Bernstein, Greg; Kireeti Kompella; ccamp@ops.ietf.org 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 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:dwfedyk@nortelnetworks.com]
Sent: Monday, February = 25, 2002 4:07 PM
To: Bernstein, Greg; = Kireeti Kompella; ccamp@ops.ietf.org
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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 16:07:42 -0800 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60173FD70@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: "Bernstein, Greg" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Routing drafts Date: Mon, 25 Feb 2002 19:07:06 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BE59.86DC8410" 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" 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_01C1BE59.86DC8410-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 15:45:16 -0800 Message-ID: <3C7ACC44.8FAAF86A@alcatel.be> Date: Tue, 26 Feb 2002 00:44:04 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - IPO NA (Antwerpen) MIME-Version: 1.0 To: Stephen Trowbridge Cc: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: WG dcoument status Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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 : dimitri.papadimitriou@alcatel.be 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 Envelope-to: ccamp-data@psg.com 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 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624101B89@OCCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: SONET/SDH label agreement for IETF, ITU-T and OIF Thread-Index: AcG+NtljiZ2cohOKRHK76RH5WB1KDwAFTNTw From: "Brungard, Deborah A, ALASO" To: "Mannie, Eric" , "Stephen Trowbridge" , "Kireeti Kompella" Cc: "Wijnen, Bert (Bert)" , , , "ccamp-wg" , 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:Eric.Mannie@ebone.com] Sent: Monday, February 25, 2002 2:54 PM To: 'Stephen Trowbridge'; Kireeti Kompella Cc: Wijnen, Bert (Bert); 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu' 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:sjtrowbridge@lucent.com] Sent: Monday, February 25, 2002 7:52 PM To: Kireeti Kompella Cc: Wijnen, Bert (Bert); Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu' 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 15:12:33 -0800 Message-ID: <2135200C183FD5119588009027DE572354DCF3@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Routing drafts Date: Mon, 25 Feb 2002 15:11:08 -0800 MIME-Version: 1.0 Content-Type: text/plain 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:kireeti@juniper.net] Sent: Sunday, February 24, 2002 4:55 PM To: ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 13:41:45 -0800 Message-ID: <3C7AAF37.3A837E3@lucent.com> Date: Mon, 25 Feb 2002 14:40:07 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: WG dcoument status Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 11:56:24 -0800 Message-ID: From: "Mannie, Eric" To: 'Stephen Trowbridge' , Kireeti Kompella Cc: "Wijnen, Bert (Bert)" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Mon, 25 Feb 2002 20:53:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:sjtrowbridge@lucent.com] Sent: Monday, February 25, 2002 7:52 PM To: Kireeti Kompella Cc: Wijnen, Bert (Bert); Mannie, Eric; 'mvissers@lucent.com'; 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu' 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 10:53:05 -0800 Message-ID: <3C7A87C3.A74C4174@lucent.com> Date: Mon, 25 Feb 2002 11:51:47 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella CC: "Wijnen, Bert (Bert)" , "Mannie, Eric" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 09:41:05 -0800 Message-ID: From: "Mannie, Eric" To: "'v.sharma@ieee.org'" , Kireeti Kompella , ccamp@ops.ietf.org Cc: Greg Bernstein Subject: RE: WG dcoument status Date: Mon, 25 Feb 2002 18:39:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ... if I remember correctly, this was accepted as a WG document already. Kind regards, Eric -----Original Message----- From: Vishal Sharma [mailto:v.sharma@ieee.org] Sent: Monday, February 25, 2002 6:28 PM To: Kireeti Kompella; ccamp@ops.ietf.org 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Kireeti Kompella > Sent: Sunday, February 24, 2002 8:52 PM > To: ccamp@ops.ietf.org > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 09:31:17 -0800 Reply-To: From: "Vishal Sharma" To: "Kireeti Kompella" , Cc: "Greg Bernstein" , "Eric Mannie" Subject: RE: WG dcoument status Date: Mon, 25 Feb 2002 12:28:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Kireeti Kompella > Sent: Sunday, February 24, 2002 8:52 PM > To: ccamp@ops.ietf.org > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 08:37:56 -0800 Message-ID: From: "Mannie, Eric" To: 'Kireeti Kompella' , "Wijnen, Bert (Bert)" Cc: ccamp@ops.ietf.org Subject: GMPLS implementation report Date: Mon, 25 Feb 2002 17:35:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:kireeti@juniper.net] Sent: Monday, February 25, 2002 5:09 PM To: Wijnen, Bert (Bert) Cc: ccamp@ops.ietf.org 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 08:22:37 -0800 Date: Mon, 25 Feb 2002 08:22:15 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: SDH/SONET extensions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 08:10:01 -0800 Date: Mon, 25 Feb 2002 08:09:14 -0800 (PST) From: Kireeti Kompella To: "Wijnen, Bert (Bert)" cc: ccamp@ops.ietf.org Subject: RE: WG dcoument status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 06:09:34 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF12710559717F@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: WG dcoument status Date: Mon, 25 Feb 2002 15:09:03 +0100 MIME-Version: 1.0 Content-Type: text/plain Thanks Kireeti for posting the status. I have some comments inline asd well. Bert > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, February 25, 2002 2:52 AM > To: ccamp@ops.ietf.org > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Feb 2002 05:45:00 -0800 Message-Id: <4.3.2.7.2.20020225084107.01d714d0@161.44.167.72> Date: Mon, 25 Feb 2002 08:42:02 -0500 To: Kireeti Kompella From: "Thomas D. Nadeau" Subject: RE: draft-bonica-tunneltrace-02 Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 24 Feb 2002 18:26:35 -0800 Date: Sun, 24 Feb 2002 18:25:17 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: CCAMP Protection/Restoration Design Team Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 24 Feb 2002 17:52:52 -0800 Date: Sun, 24 Feb 2002 17:52:08 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: WG dcoument status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 24 Feb 2002 16:55:42 -0800 Date: Sun, 24 Feb 2002 16:55:27 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Routing drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 24 Feb 2002 16:47:17 -0800 Date: Sun, 24 Feb 2002 16:46:38 -0800 (PST) From: Kireeti Kompella To: David Allan cc: neil.2.harrison@bt.com, Ronald.P.Bonica@wcom.com, ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 24 Feb 2002 16:31:28 -0800 Date: Sun, 24 Feb 2002 16:10:36 -0800 (PST) From: Kireeti Kompella To: "Wijnen, Bert (Bert)" cc: "Mannie, Eric" , "'mvissers@lucent.com'" , "'vijay@umbc.edu'" , ccamp-wg , "'sob@harvard.edu'" Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 24 Feb 2002 16:31:25 -0800 Date: Sun, 24 Feb 2002 16:12:42 -0800 (PST) From: Kireeti Kompella To: Adrian Farrel cc: Zhi-Wei Lin , ccamp Subject: Re: question about LDP restart... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: ccamp-data@psg.com Delivery-date: Sat, 23 Feb 2002 07:37:46 -0800 Message-ID: <019b01c1bc7f$9bfb7120$681810ac@movaz.com> From: "Adrian Farrel" To: "Zhi-Wei Lin" , "ccamp" 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" To: "ccamp" 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Feb 2002 09:15:17 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401EB4F30@zcard0ka.ca.nortel.com> From: "David Allan" To: neil.2.harrison@bt.com, Ronald.P.Bonica@wcom.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Fri, 22 Feb 2002 12:11:16 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBC3.F04030C0" 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Thursday, February 21, 2002 3:08 PM To: Ronald.P.Bonica@wcom.com; Allan, David [CAR:NS00:EXCH] Cc: ccamp@ops.ietf.org 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:Ronald.P.Bonica@wcom.com] Sent: 21 February 2002 19:32 To: David Allan Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Hi David, Comments inline...... -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 20, 2002 10:59 AM To: Ron Bonica Cc: ccamp@ops.ietf.org 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" re: draft-bonica-tunneltrace-02
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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Thursday, February 21, 2002 3:08 PM
To: Ronald.P.Bonica@wcom.com; Allan, David [CAR:NS00:EXCH]
Cc: ccamp@ops.ietf.org
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:Ronald.P.Bonica@wcom.com]
Sent: 21 February 2002 19:32
To: David Allan
Cc: ccamp@ops.ietf.org
Subject: RE: draft-bonica-tunneltrace-02

Hi David,
 
Comments inline......
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Wednesday, February 20, 2002 10:59 AM
To: Ron Bonica
Cc: ccamp@ops.ietf.org
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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Feb 2002 08:17:51 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A595@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ron Bonica'" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Fri, 22 Feb 2002 08:17:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Feb 2002 08:13:28 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105596DBD@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Mannie, Eric" , "'mvissers@lucent.com'" , "'kireeti@juniper.net'" , "'vijay@umbc.edu'" Cc: ccamp-wg , "'sob@harvard.edu'" , "'bwijnen@lucent.com'" Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Fri, 22 Feb 2002 17:12:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:Eric.Mannie@ebone.com] > Sent: Friday, February 22, 2002 5:03 PM > To: 'ccamp@ops.ietf.org' > Cc: 'sob@harvard.edu'; 'mvissers@lucent.com'; 'kireeti@juniper.net'; > 'vijay@umbc.edu'; 'bwijnen@lucent.com' > 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:bwijnen@lucent.com] > 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:mvissers@lucent.com] > > 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:otxchange@ftp.itu.int/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 > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Feb 2002 08:06:00 -0800 Message-ID: From: "Mannie, Eric" To: "'ccamp@ops.ietf.org'" Cc: "'sob@harvard.edu'" , "'mvissers@lucent.com'" , "'kireeti@juniper.net'" , "'vijay@umbc.edu'" , "'bwijnen@lucent.com'" Subject: SONET/SDH label agreement for IETF, ITU-T and OIF Date: Fri, 22 Feb 2002 17:02:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:bwijnen@lucent.com] 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:mvissers@lucent.com] > 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:otxchange@ftp.itu.int/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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Feb 2002 06:38:52 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401EB4BCA@zcard0ka.ca.nortel.com> From: "David Allan" To: Ron Bonica Cc: ccamp@ops.ietf.org Subject: FW: draft bonica Date: Fri, 22 Feb 2002 09:36:24 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBAE.4DACD300" 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 >> 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 FW: draft bonica

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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Feb 2002 06:33:29 -0800 Message-ID: <3C7656A3.2040908@lucent.com> Date: Fri, 22 Feb 2002 09:33:07 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020204 MIME-Version: 1.0 To: ccamp Subject: question about LDP restart... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Feb 2002 06:13:33 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF127105596D4B@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , Vijay Gill Cc: ccamp , Maarten Vissers , Scott Bradner Subject: RE: SONET/SDH label agreement? Date: Fri, 22 Feb 2002 15:12:58 +0100 MIME-Version: 1.0 Content-Type: text/plain 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:mvissers@lucent.com] > 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:otxchange@ftp.itu.int/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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Feb 2002 05:55:56 -0800 Date: Fri, 22 Feb 2002 08:48:42 -0500 From: Ron Bonica Subject: RE: draft-bonica-tunneltrace-02 To: Shahram Davari , ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Ooops.... I meant to send this to the list. Ron > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > 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:Ronald.P.Bonica@wcom.com] > > 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:Shahram_Davari@pmc-sierra.com] > > > Sent: Thursday, February 21, 2002 12:14 PM > > > To: Shahram Davari; 'Ron Bonica'; 'ccamp@ops.ietf.org' > > > 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'; ccamp@ops.ietf.org > > > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com] > > > > > Sent: Thursday, February 21, 2002 11:34 AM > > > > > To: Shahram Davari; ccamp@ops.ietf.org > > > > > 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: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org]On > > > > > Behalf Of Shahram Davari > > > > > Sent: Tuesday, February 19, 2002 5:29 PM > > > > > To: ccamp@ops.ietf.org > > > > > 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 > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Feb 2002 00:18:58 -0800 Cc: ccamp , "Wijnen, Bert" , Scott Bradner Message-ID: <3C75FE61.1B3578D2@lucent.com> Date: Fri, 22 Feb 2002 09:16:34 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella , Vijay Gill Original-CC: ccamp , "Wijnen, Bert" , Scott Bradner Subject: Re: SONET/SDH label agreement? Content-Type: multipart/mixed; boundary="------------B45EB8F6C37F38E1E7895B36" 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:otxchange@ftp.itu.int/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:mvissers@lucent.com 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 15:30:21 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A591@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ron Bonica'" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 21 Feb 2002 15:28:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:Ronald.P.Bonica@wcom.com] > Sent: Thursday, February 21, 2002 5:04 PM > To: Shahram Davari; ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Thursday, February 21, 2002 12:03 PM > > To: 'Ron Bonica'; ccamp@ops.ietf.org > > Subject: RE: draft-bonica-tunneltrace-02 > > > > > > Hi Ron, > > > > > > > -----Original Message----- > > > From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com] > > > Sent: Thursday, February 21, 2002 11:34 AM > > > To: Shahram Davari; ccamp@ops.ietf.org > > > 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Shahram Davari > > > Sent: Tuesday, February 19, 2002 5:29 PM > > > To: ccamp@ops.ietf.org > > > 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 > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 14:10:14 -0800 Date: Thu, 21 Feb 2002 17:04:03 -0500 From: Ron Bonica Subject: RE: draft-bonica-tunneltrace-02 To: Shahram Davari , ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, February 21, 2002 12:03 PM > To: 'Ron Bonica'; ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > Hi Ron, > > > > -----Original Message----- > > From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com] > > Sent: Thursday, February 21, 2002 11:34 AM > > To: Shahram Davari; ccamp@ops.ietf.org > > 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Shahram Davari > > > Sent: Tuesday, February 19, 2002 5:29 PM > > > To: ccamp@ops.ietf.org > > > 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 > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 12:09:38 -0800 Message-ID: From: neil.2.harrison@bt.com To: Ronald.P.Bonica@wcom.com, dallan@nortelnetworks.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 21 Feb 2002 20:08:27 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB13.862DB640" 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:Ronald.P.Bonica@wcom.com] Sent: 21 February 2002 19:32 To: David Allan Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Hi David, Comments inline...... -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 20, 2002 10:59 AM To: Ron Bonica Cc: ccamp@ops.ietf.org 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" 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:Ronald.P.Bonica@wcom.com]
Sent: 21 February 2002 19:32
To: David Allan
Cc: ccamp@ops.ietf.org
Subject: RE: draft-bonica-tunneltrace-02

Hi David,
 
Comments inline......
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Wednesday, February 20, 2002 10:59 AM
To: Ron Bonica
Cc: ccamp@ops.ietf.org
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-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 11:36:47 -0800 Date: Thu, 21 Feb 2002 14:31:35 -0500 From: Ron Bonica Subject: RE: draft-bonica-tunneltrace-02 To: David Allan Cc: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_mkxpWJL/oBePvflv+q8ABA)" 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:dallan@nortelnetworks.com] Sent: Wednesday, February 20, 2002 10:59 AM To: Ron Bonica Cc: ccamp@ops.ietf.org 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 re: draft-bonica-tunneltrace-02
Hi=20 David,
 
Comments inline......
-----Original Message-----
From: David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Wednesday, February = 20,=20 2002 10:59 AM
To: Ron Bonica
Cc:=20 ccamp@ops.ietf.org
Subject: re:=20 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=20 really saying that
traceroute only reveals = the current=20 layer/level and reveals no knowledge of nesting of
lower layer/level tunnels or the relationship of the current = level to=20 higher levels?
It doesn't clearly come=20 out.  

This=20 is the case for some tunnel types, but not others. The next two = paragraphs=20 provide examples.

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

1) I think a broader discussion of some of the = security issues=20 needs to be raised. First by
whatever means = a trace=20 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=20 network may be required to
generate a = response to the=20 tracing application. Therefore the tracing application is = required=20
to promiscuously accept responses. A mechanism is = required to=20 authoritatively associate
responses with = requests and=20 discard spurious messages. Further such a mechanism should not = be=20
able to be leveraged for denial of service attacks = (e.g.=20 spurious trace responses forcing lots
of = cryptography,=20 defense against replay attacks etc.).  

Hmm.... good point! I thought about the probed device = authenticating=20 traceProbes, but never considered the possibility that the = probing device=20 might need to authenticate responses. I will add this to the next = draft version. 

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

I am=20 not sure that I understand the comment. Could you restate=20 it?

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

One of=20 our initial requirements was to provide all of the = functionality 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.

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

The=20 former. I will clarify this.

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

Yes.=20 Again, I will clarify this

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

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. 

6) I think are more accurate statement is support = any=20 tunneling technology that is used between
IP = endpoints. Otherwise this is not a sustainable requirement. I am = concerned,=20 for example, that
any intervening L2 or = layer 2 and a=20 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=20 appear to be SOL)  

I am=20 not sure that I agree. Given that the device at the head end of the = L2TP=20 tunnel tells us that there is an L2TP tunnel involved, what = stops us=20 from tracing through it?

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

No.=20 Requirement 4 states that the application will = tell us details about=20 a tunnel. Requirement 7 states that the application can=20 tell us details about tunnels within=20 tunnels. 

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

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.

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

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.

The=20 control and forwarding plane can also diverge when routers are=20 broken.

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

How=20 would you trace through the forwarding plane for tunnel types that do = not=20 support TTL decrement? 

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

Always=20 glad to clarify terminology. 

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

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. 

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

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

my two cents
Dave=20

--Boundary_(ID_mkxpWJL/oBePvflv+q8ABA)-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 11:33:33 -0800 Message-ID: From: neil.2.harrison@bt.com To: randy@psg.com, Shahram_Davari@pmc-sierra.com Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 21 Feb 2002 19:31:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 10:40:12 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A584@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Scott Bradner'" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 21 Feb 2002 10:39:40 -0800 MIME-Version: 1.0 Content-Type: text/plain 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:sob@harvard.edu] > Sent: Thursday, February 21, 2002 1:30 PM > To: ccamp@ops.ietf.org > 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: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 10:30:46 -0800 Date: Thu, 21 Feb 2002 13:30:28 -0500 (EST) From: Scott Bradner Message-Id: <200202211830.g1LIUSB27768@newdev.harvard.edu> To: ccamp@ops.ietf.org 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: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 10:27:46 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A583@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Randy Bush'" Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 21 Feb 2002 10:27:07 -0800 MIME-Version: 1.0 Content-Type: text/plain Hi, > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Thursday, February 21, 2002 1:18 PM > To: Shahram Davari > Cc: ccamp@ops.ietf.org > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 10:19:07 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Shahram Davari Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Message-Id: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 10:14:20 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A582@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Randy Bush'" Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 21 Feb 2002 10:13:52 -0800 MIME-Version: 1.0 Content-Type: text/plain Hi, > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Thursday, February 21, 2002 1:08 PM > To: Shahram Davari > Cc: ccamp@ops.ietf.org > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 10:08:24 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Shahram Davari Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Message-Id: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 10:06:48 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A581@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Randy Bush'" Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 21 Feb 2002 10:05:25 -0800 MIME-Version: 1.0 Content-Type: text/plain Hi Randy, > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Thursday, February 21, 2002 12:23 PM > To: Shahram Davari > Cc: ccamp@ops.ietf.org > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 09:38:20 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401E5AC41@zcard0ka.ca.nortel.com> From: "David Allan" To: Loa Andersson Cc: Ron Bonica , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 21 Feb 2002 12:37:24 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BAFE.6C159DA0" 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:loa.andersson@utfors.se] > Sent: Thursday, February 21, 2002 12:21 PM > To: Allan, David [CAR:NS00:EXCH] > Cc: Ron Bonica; ccamp@ops.ietf.org > 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:loa.andersson@utfors.se] > > > Sent: Wednesday, February 20, 2002 11:31 AM > > > To: Allan, David [CAR:NS00:EXCH] > > > Cc: Ron Bonica; ccamp@ops.ietf.org > > > 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 loa.andersson@utfors.se > > > 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 loa.andersson@utfors.se > WWW www.utfors.se > > ------_=_NextPart_001_01C1BAFE.6C159DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-bonica-tunneltrace-02

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:loa.andersson@utfors.se]
> Sent: Thursday, February 21, 2002 12:21 = PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Ron Bonica; ccamp@ops.ietf.org
> 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:loa.andersson@utfors.se]
> >  > Sent: Wednesday, February 20, = 2002 11:31 AM
> >  > To: Allan, David = [CAR:NS00:EXCH]
> >  > Cc: Ron Bonica; = ccamp@ops.ietf.org
> >  > 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=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           = loa.andersson@utfors.se
> >  > = WWW           &nb= sp; www.utfors.se
> >  >
> >  >
> >  >
> >
>
>
> --
> 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           = loa.andersson@utfors.se
> = WWW           &nb= sp; www.utfors.se
>
>

------_=_NextPart_001_01C1BAFE.6C159DA0-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 09:23:14 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Shahram Davari Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Message-Id: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 09:21:38 -0800 Message-ID: <3C752C71.5020501@utfors.se> Date: Thu, 21 Feb 2002 18:20:49 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: David Allan CC: Ron Bonica , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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:loa.andersson@utfors.se] > > Sent: Wednesday, February 20, 2002 11:31 AM > > To: Allan, David [CAR:NS00:EXCH] > > Cc: Ron Bonica; ccamp@ops.ietf.org > > 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 loa.andersson@utfors.se > > 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 loa.andersson@utfors.se WWW www.utfors.se Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 09:15:13 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A580@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: Shahram Davari , "'Ron Bonica'" , "'ccamp@ops.ietf.org'" Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 21 Feb 2002 09:14:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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'; ccamp@ops.ietf.org > Subject: RE: draft-bonica-tunneltrace-02 > > > Hi Ron, > > > > -----Original Message----- > > From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com] > > Sent: Thursday, February 21, 2002 11:34 AM > > To: Shahram Davari; ccamp@ops.ietf.org > > 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Shahram Davari > > > Sent: Tuesday, February 19, 2002 5:29 PM > > > To: ccamp@ops.ietf.org > > > 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 > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 09:04:16 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A57F@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ron Bonica'" , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 21 Feb 2002 09:03:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Ron, > -----Original Message----- > From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com] > Sent: Thursday, February 21, 2002 11:34 AM > To: Shahram Davari; ccamp@ops.ietf.org > 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Shahram Davari > > Sent: Tuesday, February 19, 2002 5:29 PM > > To: ccamp@ops.ietf.org > > 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 > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 08:43:49 -0800 Date: Thu, 21 Feb 2002 11:34:13 -0500 From: Ron Bonica Subject: RE: draft-bonica-tunneltrace-02 To: Shahram Davari , ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Shahram Davari > Sent: Tuesday, February 19, 2002 5:29 PM > To: ccamp@ops.ietf.org > 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 > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Feb 2002 08:43:46 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A57E@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Scott Bradner'" , dallan@nortelnetworks.com, loa.andersson@utfors.se Cc: ccamp@ops.ietf.org, Ronald.P.Bonica@wcom.com Subject: RE: draft-bonica-tunneltrace-02 Date: Thu, 21 Feb 2002 08:39:31 -0800 MIME-Version: 1.0 Content-Type: text/plain Hi, I don't see path-trace being mentioned in the charter. Yours, -Shahram > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Wednesday, February 20, 2002 6:40 PM > To: dallan@nortelnetworks.com; loa.andersson@utfors.se > Cc: ccamp@ops.ietf.org; Ronald.P.Bonica@wcom.com > 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: ccamp-data@psg.com Delivery-date: Wed, 20 Feb 2002 15:41:55 -0800 Date: Wed, 20 Feb 2002 18:39:55 -0500 (EST) From: Scott Bradner Message-Id: <200202202339.g1KNdtT23585@newdev.harvard.edu> To: dallan@nortelnetworks.com, loa.andersson@utfors.se Subject: Re: draft-bonica-tunneltrace-02 Cc: ccamp@ops.ietf.org, Ronald.P.Bonica@wcom.com > 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: ccamp-data@psg.com Delivery-date: Wed, 20 Feb 2002 14:28:29 -0800 Message-ID: <114DE1AABD7DD41189B600508BAF1271055968F4@nl0006exch005u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Loa Andersson , David Allan Cc: Ron Bonica , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 20 Feb 2002 23:28:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:loa.andersson@utfors.se] > Sent: Wednesday, February 20, 2002 5:31 PM > To: David Allan > Cc: Ron Bonica; ccamp@ops.ietf.org > 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 loa.andersson@utfors.se > WWW www.utfors.se > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Feb 2002 14:27:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "David Allan" Cc: "Cuevas, Enrique G, ALASO" , ccamp@ops.ietf.org, Ron Bonica , Loa Andersson Subject: RE: draft-bonica-tunneltrace-02 Message-Id: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Feb 2002 14:24:24 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401E5A51D@zcard0ka.ca.nortel.com> From: "David Allan" To: Randy Bush , "Cuevas, Enrique G, ALASO" Cc: ccamp@ops.ietf.org, Ron Bonica , Loa Andersson Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 20 Feb 2002 17:23:40 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA5D.3FA753E0" 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:randy@research.att.com] > Sent: Wednesday, February 20, 2002 5:10 PM > To: Cuevas, Enrique G, ALASO > Cc: ccamp@ops.ietf.org; 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 RE: draft-bonica-tunneltrace-02

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:randy@research.att.com= ]
> Sent: Wednesday, February 20, 2002 5:10 = PM
> To: Cuevas, Enrique G, ALASO
> Cc: ccamp@ops.ietf.org; 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Feb 2002 14:10:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Cuevas, Enrique G, ALASO" Cc: , "Ron Bonica" , "Loa Andersson" , "David Allan" Subject: RE: draft-bonica-tunneltrace-02 Message-Id: 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) Envelope-to: ccamp-data@psg.com 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 Message-ID: <28F05913385EAC43AF019413F674A0170148AFB2@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-bonica-tunneltrace-02 Thread-Index: AcG6LLSyRq/YiMzrT6+lQoET4rQ3mgAKZPJw From: "Cuevas, Enrique G, ALASO" To: Cc: "Ron Bonica" , "Loa Andersson" , "David Allan" 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 _______________ ecuevas@att.com Tel. (732)-420-3252 >-----Original Message----- >From: Loa Andersson [mailto:loa.andersson@utfors.se] >Sent: Wednesday, February 20, 2002 11:31 AM >To: David Allan >Cc: Ron Bonica; ccamp@ops.ietf.org >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 loa.andersson@utfors.se >WWW www.utfors.se > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Feb 2002 11:44:43 -0800 Message-Id: <4.3.2.7.2.20020220143854.01d49078@161.44.167.72> Date: Wed, 20 Feb 2002 14:43:28 -0500 To: "David Allan" From: "Thomas D. Nadeau" Subject: re: draft-bonica-tunneltrace-02 Cc: Ron Bonica , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Feb 2002 10:57:04 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401DFC115@zcard0ka.ca.nortel.com> From: "David Allan" To: Loa Andersson Cc: Ron Bonica , ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Wed, 20 Feb 2002 13:54:09 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA3F.FA9ACEC0" 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:loa.andersson@utfors.se] > Sent: Wednesday, February 20, 2002 11:31 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: Ron Bonica; ccamp@ops.ietf.org > 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 loa.andersson@utfors.se > WWW www.utfors.se > > > ------_=_NextPart_001_01C1BA3F.FA9ACEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-bonica-tunneltrace-02

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:loa.andersson@utfors.se]
> Sent: Wednesday, February 20, 2002 11:31 = AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Ron Bonica; ccamp@ops.ietf.org
> 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=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           = loa.andersson@utfors.se
> = WWW           &nb= sp; www.utfors.se
>
>
>

------_=_NextPart_001_01C1BA3F.FA9ACEC0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Feb 2002 08:32:02 -0800 Message-ID: <3C73CF2F.1050902@utfors.se> Date: Wed, 20 Feb 2002 17:30:39 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: David Allan CC: Ron Bonica , ccamp@ops.ietf.org Subject: Re: draft-bonica-tunneltrace-02 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 loa.andersson@utfors.se WWW www.utfors.se Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Feb 2002 08:00:14 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401DFBD8C@zcard0ka.ca.nortel.com> From: "David Allan" To: Ron Bonica Cc: ccamp@ops.ietf.org Subject: re: draft-bonica-tunneltrace-02 Date: Wed, 20 Feb 2002 10:59:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA27.91BF5190" 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 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_01C1BA27.91BF5190-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Feb 2002 07:30:34 -0800 Message-Id: <200202201527.g1KFRdi49769@merlot.juniper.net> To: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-routing-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21077.1014218859.1@juniper.net> Date: Wed, 20 Feb 2002 07:27:39 -0800 From: Yakov Rekhter 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: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: ccamp@ops.ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020219150835.I-D@ietf.org> 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: <20020219150835.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Feb 2002 04:09:16 -0800 Message-Id: <200202201207.HAA27728@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020219150835.I-D@ietf.org> 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: <20020219150835.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Feb 2002 14:40:17 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A577@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Tue, 19 Feb 2002 14:28:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Feb 2002 08:50:48 -0800 Message-ID: <3C712F83.D6D9B77F@utfors.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 18 Feb 2002 17:44:51 +0100 From: Tove Madsen To: ccamp@ops.ietf.org 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 > To: ccamp@ops.ietf.org > > 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:tove.madsen@utfors.se http://www.utfors.se/ Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Feb 2002 08:04:22 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mina Azad Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Message-Id: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Feb 2002 07:46:21 -0800 Date: Mon, 18 Feb 2002 10:41:02 -0500 From: Ron Bonica Subject: RE: draft-bonica-tunneltrace-02 To: Mina Azad Cc: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_KCEYEv9f0fQZ0LlAYG5zjA)" 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:mazad@nortelnetworks.com] Sent: Monday, February 18, 2002 10:16 AM To: Ron Bonica Cc: ccamp@ops.ietf.org 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:Ronald.P.Bonica@wcom.com] > Sent: Saturday, February 16, 2002 9:14 PM > To: ccamp@ops.ietf.org > 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 RE: draft-bonica-tunneltrace-02
Mina,
 
This=20 is a requirements specification, not an implementation. Many tools might = satisfy=20 the requirements specified by this draft.
 
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.
 
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;=20 Ron
 
-----Original Message-----
From: Mina Azad=20 [mailto:mazad@nortelnetworks.com]
Sent: Monday, February 18, = 2002=20 10:16 AM
To: Ron Bonica
Cc:=20 ccamp@ops.ietf.org
Subject: RE:=20 draft-bonica-tunneltrace-02

Is this not the same tool that was presented in the = OAM BOF in=20 IETF 52?
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? 

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?

 
Regards, =

Mina Azad


> -----Original Message-----
>=20 From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com<= /A>]=20
> Sent: Saturday, February 16, 2002 9:14 = PM=20
> To: ccamp@ops.ietf.org
>=20 Subject: draft-bonica-tunneltrace-02
>=20
>
> = Folks,=20
>
> I would like to = propose=20 that we adopt
> = draft-bonica-tunneltrace-02 as a=20 WG
> draft.
>=20
> Comments?
>=20
>=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
>=20 Ronald P. Bonica       Ph: 703 886 = 1681=20
> vBNS = Engineering      =20 page: 1 888 268 8021
> Ashburn, = Va.=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=20
> "We are not on Earth to guard a museum, = but=20
> to cultivate a flourishing garden of = life."=20
>          =       =20 -- Angello Giuseppe Roncalli
> =
>
> =

--Boundary_(ID_KCEYEv9f0fQZ0LlAYG5zjA)-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Feb 2002 07:19:45 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD3401D967F8@zcard0ka.ca.nortel.com> From: "Mina Azad" To: Ron Bonica Cc: ccamp@ops.ietf.org Subject: RE: draft-bonica-tunneltrace-02 Date: Mon, 18 Feb 2002 10:16:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B88F.39E2E610" 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:Ronald.P.Bonica@wcom.com] > Sent: Saturday, February 16, 2002 9:14 PM > To: ccamp@ops.ietf.org > 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 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:Ronald.P.Bonica@wcom.com= ]
> Sent: Saturday, February 16, 2002 9:14 = PM
> To: ccamp@ops.ietf.org
> Subject: draft-bonica-tunneltrace-02
>
>
> Folks,
>
> I would like to propose that we adopt
> draft-bonica-tunneltrace-02 as a WG
> draft.
>
> Comments?
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Ronald P. = Bonica       Ph: 703 886 1681
> vBNS = Engineering       page: 1 888 268 = 8021
> Ashburn, Va.
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> "We are not on Earth to guard a museum, = but
> to cultivate a flourishing garden of = life."
>          = ;       -- Angello Giuseppe = Roncalli
>
>
>

------_=_NextPart_001_01C1B88F.39E2E610-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 16 Feb 2002 18:22:43 -0800 Date: Sat, 16 Feb 2002 21:13:47 -0500 From: Ron Bonica Subject: draft-bonica-tunneltrace-02 To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Feb 2002 06:32:13 -0800 Message-Id: <200202131208.HAA28576@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020212143951.I-D@ietf.org> 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: <20020212143951.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Feb 2002 09:14:58 -0800 Message-ID: <05707214338CD5119BFF0040A5B170D318167C@mail3.tellium.com> From: Hang Liu To: "'brajaram@npd.hcltech.com'" , "'afarrel@movaz.com'" , "'whui@mail.ustc.edu.cn'" Cc: ccamp@ops.ietf.org Subject: RE: New draft Date: Thu, 14 Feb 2002 12:00:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:brajaram@npd.hcltech.com] Sent: Thursday, February 14, 2002 10:01 AM To: Adrian Farrel Cc: ccamp@ops.ietf.org 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" > To: "Adrian Farrel" ; > Cc: > 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" > > > To: > > > 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 : whui@mail.ustc.edu.cn > > > > > > > > best regards, > > > > Wang > > > > -- > > > > Wang Hui > > > > InfoNet Lab, USTC > > > > http://mail.ustc.edu.cn/~whui > > > > Tel: +86-551-3603634 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Feb 2002 06:59:33 -0800 Message-Id: <200202141451.g1EEp3T00467@mailnpd.hcltech.com> Content-Type: text/plain; charset="iso-8859-1" From: Rajaraman B Organization: HCL Technologies Ltd To: "Adrian Farrel" Subject: Re: New draft Date: Thu, 14 Feb 2002 20:31:17 +0530 Cc: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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" > To: "Adrian Farrel" ; > Cc: > 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" > > > To: > > > 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 : whui@mail.ustc.edu.cn > > > > > > > > best regards, > > > > Wang > > > > -- > > > > Wang Hui > > > > InfoNet Lab, USTC > > > > http://mail.ustc.edu.cn/~whui > > > > Tel: +86-551-3603634 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Feb 2002 06:38:47 -0800 Message-ID: <016b01c1b564$bae82e60$681810ac@movaz.com> From: "Adrian Farrel" To: "Rajaraman B" , Cc: 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" To: "Adrian Farrel" ; Cc: 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" > > To: > > 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 : whui@mail.ustc.edu.cn > > > > > > best regards, > > > Wang > > > -- > > > Wang Hui > > > InfoNet Lab, USTC > > > http://mail.ustc.edu.cn/~whui > > > Tel: +86-551-3603634 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Feb 2002 11:41:26 -0800 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0E7E7CA6@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg Cc: RFC Editor , Scott Bradner Subject: Long Lists of authors/editors Date: Wed, 13 Feb 2002 16:38:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Feb 2002 04:11:35 -0800 Message-Id: <200202131208.HAA28592@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020212144008.I-D@ietf.org> 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: <20020212144008.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Feb 2002 04:11:32 -0800 Message-Id: <200202131208.HAA28576@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020212143951.I-D@ietf.org> 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: <20020212143951.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Feb 2002 22:57:02 -0800 Message-Id: <200202130644.g1D6iLT32077@mailnpd.hcltech.com> Content-Type: text/plain; charset="iso-8859-1" From: Rajaraman B Organization: HCL Technologies Ltd To: "Adrian Farrel" , whui@mail.ustc.edu.cn Subject: Re: New draft Date: Wed, 13 Feb 2002 12:24:29 +0530 Cc: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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" > To: > 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 : whui@mail.ustc.edu.cn > > > > best regards, > > Wang > > -- > > Wang Hui > > InfoNet Lab, USTC > > http://mail.ustc.edu.cn/~whui > > Tel: +86-551-3603634 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Feb 2002 17:15:26 -0800 Message-ID: <009f01c1b362$537f8ec0$681810ac@movaz.com> From: "Adrian Farrel" To: "Wang Hui" , 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" To: 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 : whui@mail.ustc.edu.cn > > best regards, > Wang > -- > Wang Hui > InfoNet Lab, USTC > http://mail.ustc.edu.cn/~whui > Tel: +86-551-3603634 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 10 Feb 2002 02:55:39 -0800 Date: Sun, 10 Feb 2002 18:42:17 +0800 (CST) From: Wang Hui To: Subject: New draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 : whui@mail.ustc.edu.cn best regards, Wang -- Wang Hui InfoNet Lab, USTC http://mail.ustc.edu.cn/~whui Tel: +86-551-3603634 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Feb 2002 07:23:16 -0800 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0E734902@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Maarten Vissers Cc: ccamp Subject: RE: SONET/SDH label agreement? Date: Fri, 8 Feb 2002 16:22:44 +0100 MIME-Version: 1.0 Content-Type: text/plain > ftp://sg15opticalt:otxchange@ftp.itu.int/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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Feb 2002 07:04:52 -0800 Cc: ccamp , "Wijnen, Bert" , Scott Bradner Message-ID: <3C63E80E.9BFE0A7F@lucent.com> Date: Fri, 08 Feb 2002 16:00:30 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella , Vijay Gill Original-CC: ccamp , "Wijnen, Bert" , Scott Bradner Subject: SONET/SDH label agreement? Content-Type: multipart/mixed; boundary="------------AF9BAACEB7071F24B3C34A5C" 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:otxchange@ftp.itu.int/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:mvissers@lucent.com 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Feb 2002 00:09:44 -0800 Subject: draft-vasseur-mpls-computation-rsvp-02.txt To: ccamp@ops.ietf.org Cc: jpv@cisco.com, cei@cisco.com, raymond_zhang@infonet.com, nadim_constantine@infonet.com, xavier.vinet@equant.com, satoru@japan-telecom.co.jp, Cheng-Yin.Lee@alcatel.com, gash@att.com Message-ID: From: sven.van_den_bosch@alcatel.be Date: Wed, 6 Feb 2002 09:03:53 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Feb 2002 06:55:08 -0800 Message-Id: <200202051450.JAA01597@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020204133939.I-D@ietf.org> 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: <20020204133939.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 03 Feb 2002 21:39:42 -0800 Message-ID: <20020204053519.53230.qmail@web13801.mail.yahoo.com> Date: Sun, 3 Feb 2002 21:35:19 -0800 (PST) From: Pyda Srisuresh Subject: Revised OSPF-TE draft To: OSPF@DISCUSS.MICROSOFT.COM Cc: te-wg@ops.ietf.org, ccamp@ops.ietf.org, paul.joseph@vivacenetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Feb 2002 01:19:57 -0800 Message-ID: <007201c1ab01$26411140$b1dca8c0@alc.wipinfo.soft.net> From: "Vinay Vernekar" To: Subject: Doubt regarding the control channel seperation in GMPLS CR-LDP. Date: Fri, 1 Feb 2002 14:46:36 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e84baf76-16e4-11d6-a217-0000e22173f5" 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
Hello,
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.
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?
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?
3) How does the upstream LSR knows about the = data channel=20 id at the downstream node, since the draft mentions data channels = are=20 specified from the view point of the sender of the Mapping message i.e.=20 downstream node.
 
Thanks in advance for your reply.
Regards
Vinay
------=_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--