Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Apr 2003 03:23:11 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C1044@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: FW: draft-ietf-ccamp-lmp-08.txt Date: Wed, 30 Apr 2003 05:20:31 +0200 MIME-Version: 1.0 Content-Type: text/plain More IESG comments Thanks, Bert -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: woensdag 30 april 2003 3:32 To: iesg@ietf.org; iesg-secretary@ietf.org Subject: draft-ietf-ccamp-lmp-08.txt In section 3.2.1, there is a recommendation for setting the default values for the HelloInterval to 150ms and the HelloDeadInterval to 500ms. The text seems to indicate that the same default is used when you pass the traffic over an IP network as when you are directly connected. This seems low in the presence of a multi-hop IP network, as you seem likely to end up in Degraded state unnecessarily. Language indicating how to judge a deviation from this default would be very useful. The draft does not seem to be clear on what happens if a TestStatusSuccess or TestStatusFailure message is lost in flight; the current language could be read to indicate that the same TestStatusAck message would be sent in both cases (5.0, just above 5.1) In section 8, Graceful Restart, it is not clear whether Multicast discovery is re-done on interfaces which have had Interface_Ids discovered through that method, or whether these are also assumed to remain stable. In section 12.1, how are bits which are currently reserved later assigned? Notes: In the introduction, paragraph 2 the use of "neighboring" is non-trivially different from the usual, so defining it would be a good idea. The first SHOULD occurs before the Terminology definition. In LMP overview the statement "All LMP packest are run over UDP with an LMP port number [except in some cases]" would be better if "Except in for test messages, which may be limited by the transport mechanism to in-band messaging, all LMP..." In section 3. there is a requirement for a unique 32-bit non-zero integer, but no specification for how to ensure uniqueness. In Section 3.0, is a unicast source address used for the multicast packet? In section 3.1, the nodes MAY continue to retransmit Config messages both when Node_Ids are equal and when a ConfigNack with unacceptable alternate values is received. Some justification for *why*it would seems useful. In Section 3.2.1, it notes that "if other methods are used to indicate bi-directional control channel connectivity", but there are no pointers to other methods; if none are currently specified, it might be useful to change the language to indicate that. Is the Verify_Id monotonically increasing, or random? In 6.0, "procedure can be used to rapidly isolate link failures" seems to mean data link failures, and it might be better to be more precise. In Section 7, the statement "Note that the 32-bit Message_Id value MAY wrap" does not need an RFC 2119 MAY, since it is a statement of fact, not an interoperability point. In 11.3.1, there is a ligatured ae in the text for Down: Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2003 21:53:59 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C1038@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: FW: draft-ietf-ccamp-lmp-08 Date: Tue, 29 Apr 2003 23:52:00 +0200 MIME-Version: 1.0 Content-Type: text/plain More IESG review comments Thanks, Bert -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: dinsdag 29 april 2003 23:14 To: iesg-secretary@ietf.org Cc: iesg@ietf.org Subject: draft-ietf-ccamp-lmp-08 Section 16.1 says: o Security mechanism should provide for well defined key management schemes. The key management schemes should be well analyzed to be cryptographically secure. The key management schemes should be scalable. I think that automated key management SHOULD be provided. Section 16.2 recommends the use of AH in tunnel mode. I would greatly prefer ESP in tunnel mode, even if confidentiality is not turned on. In my opinion, ESP with integrity-only security associations is better. In section 16.2, the term "crypto channel" is not clear. Usually, it means "IPsec security association." Yet, sometimes it refers to both the IKE SA as well as the IPsec SA. I think that IKE SA and IPsec SA can be used. In section 16.2, please change "man-in-the middle attacks" to "man-in-the-middle attacks." Section 16.2 says: Digital signature based authentication is not prone to such problems. It is recommended using digital signature based authentication mechanism where possible. If pre-shared key based authentication is required, then aggressive mode SHOULD be used. IKE pre-shared authentication key values SHOULD be protected in a manner similar to the user's account password. Please change "recommended" to upper case. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2003 19:26:47 +0000 Date: Tue, 29 Apr 2003 12:25:28 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org cc: sob@harvard.edu, "Wijnen, Bert (Bert)" , "Ron Bonica (E-mail)" , "" , Kireeti Kompella Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Message-ID: <20030429121108.M6900@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Okay, this thread seems to be going nowhere. I will formulate a liaison statement in reply to T1X1 regarding draft-ietf-ccamp-lmp-test-sonet-sdh and post it to this list. In response, I would like folks to state (preferably publicly) whether they think that the reply is reasonable [ship it], or *explicit text* for changes. No theoretical arguments, we can do those in the ITU-T Q.14/15 interim meeting. If we cannot achieve rough consensus within a week of my posting the liaison (ETA, this weekend), I will throw up my hands and pass the buck to the Liaison Coordinator and the ADs. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2003 16:45:27 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC9724D1@nimbus> From: John Drake To: 'Jonathan Sadler' Cc: "Brungard, Deborah A, ALABS" , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, George Newsome , Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Tue, 29 Apr 2003 09:43:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" See below. >From my perspective, the LMP Test procedure using the trace correlation transport mechanism can be used to support the exchange of control plane identifiers in G.7714.1 networks and the G.7714.1 Neighbor Discovery message cannot be used to support the LMP Test procedure with the intrusive Jx transport mechanisms. This is pretty much what I have said all along and I am now done with this thread. > -----Original Message----- > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > Sent: Tuesday, April 29, 2003 1:47 PM > To: John Drake > Cc: Brungard, Deborah A, ALABS; Stephen Trowbridge; > Jonathan.Lang@RinconNetworks.com; George Newsome; > Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); > zinin@psg.com > Subject: Re: Proposed response to the Liaison Statement on LMP Link > Verification > > > John - > > See inline... > > Jonathan Sadler > 0 1 2 3 4 5 6 > 0123456789012345678901234567890123456789012345678901234567890123456789 > > John Drake wrote: > > > Jonathan Sadler wrote: > > > John Drake wrote: > > > > Jonathan Sadler wrote: > > > > > John Drake wrote: > > > > > >> The liaison from T1X1 asked if it is necessary for two > > > > > >> totally independent message formats to exist for the > > > > > >> in-band case as the function being performed by both > > > > > >> G.7714.1 and the Jx Test Message Connetivity > > > > > >> Verification approach defined in lmp-test-sonet-sdh > > > > > >> is the same. > > > > > >> > > > > > > JD: I don't think that is correct. The LMP Test > > > > > > procedure is used to exchange the GMPLS identifiers > > > > > > for a given data link. Since the GMPLS identifiers > > > > > > may not be globally unique, it is necessary to qualify > > > > > > them with a Verify ID, which identifies the particular > > > > > > Test procedure the identifiers are associated with. > > > > > > G.7714.1 is used to exchange the transport level > > > > > > identifiers for a given link. > > > > > > > > > > G.7714.1 shows that the exchange of control plane > > > > > identifiers (e.g. GMPLS TE-Link IDs) is done as a part > > > > > of service capability exchange process which comes after > > > > > the neighbor has been discovered. This was separated > > > > > from the neighbor discovery mechanism to allow the > > > > > neighbor discovery function to be used by things other > > > > > than the control plane (i.e. management systems). > > > > > > > > > > It should be noted that Appendix III of G.7714.1 suggests > > > > > a way to use LMP's trace correlation mechanism to > > > > > accomplish this, which then dovetails into the rest of > > > > > LMPs processes. > > > > > > > > JD: Your original statement, to which I responded, was: > > > > "as the function being performed by both G.7714.1 and the > > > > Jx Test Message Connetivity Verification approach defined > > > > in lmp-test-sonet-sdh is the same." What you're now saying > > > > is that there is a neighbor discovery piece to G.7714.1 > > > > which has no equivalent in the LMP Test procedures, followed > > > > by the LMP Test procedure using the trace correlation > > > > tranport mechanism. > > > > > > I tend to look things from a functional decomposition > > > perspective, and not at the specific bits/bytes. > > > > > > The goal being sought is: > > > - determination that a link exists > > > - determination that it is not miswired > > > - exchange of control plane names for the endpoints > > > of that link > > > > > > Two in-band methods exist that accomplish this goal for a > > > SONET/SDH link. They are: > > > draft-ietf-ccamp-lmp-test-sonet-sdh > > > and > > > G.7714.1 (including Appendix III) > > > > JD: What you're glossing over here is that fact that according > > to your previous e-mail, Appendix III of G.7714.1 is actually > > the LMP Test procedure using the trace correlation transport > > mechanism. So, even in G.7714.1 as it currently exists, the > > only way to exchange control plane identifiers is the LMP Test > > procedure. > > Remember, the subject for discussion here is the message sent > in-band in the Jx trace bytes. The use of the LMP Test > procedure in Appendix III is limited to the trace correlation > method, which is sent over the DCN. JD: And that is because the Neighbor Discovery message does not contain sufficient information (i.e., Verify ID) to be used for exchanging control plane identifiers, which was my original point. > > > > Both methods describe message formats that intrusively use > > > the Jx strings. While the formats are different, the > > > function accomplished is identical. > > > > JD: As I mentioned previously, neighbor discovery in G.7714.1 > > has no LMP equivalent. Exchange of control plane identifiers > > uses the LMP Test procedure in both cases. > > Incorrect assertion. Both the neighbor discovery method in > G.7714.1 and intrusive Jx messages defined in lmp-test-sonet-sdh > achieve goals 1 and 2. JD: No, the intrusive Jx messages defined in the LMP Test procedure accomplish goals 1, 2, and 3 simultaneously. > > Goal 3 was identified by G.7714 to be technology independent, > and therefore something that should be carried over the DCN. JD: That's fine. This was the point I made to Rajender last week. Just don't claim that the Neighbor Discovery message can be used to support the LMP Test procedure with the intrusive Jx transport mechanisms, because, as I have pointed out on numerous occasions, it doesn't contain the necessary information. > > Jx does not need to be involved in mechanism that accomplishes > Goal 3. This is why it does not appear in the Jx message format. JD: As mentioned above, the LMP Test procedure using the intrusive Jx transport mechanisms accomplishes goal 1, 2, and 3 simultaneously. If you don't want to do this in G.7714.1 networks, that is your choice. > > > > ============================================================ > 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, 29 Apr 2003 15:53:03 +0000 Message-ID: <3EAEE4B4.64D510E7@tellabs.com> Date: Tue, 29 Apr 2003 15:46:44 -0500 From: Jonathan Sadler MIME-Version: 1.0 To: John Drake CC: "Brungard, Deborah A, ALABS" , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, George Newsome , Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verification Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John - See inline... Jonathan Sadler 0 1 2 3 4 5 6 0123456789012345678901234567890123456789012345678901234567890123456789 John Drake wrote: > Jonathan Sadler wrote: > > John Drake wrote: > > > Jonathan Sadler wrote: > > > > John Drake wrote: > > > > >> The liaison from T1X1 asked if it is necessary for two > > > > >> totally independent message formats to exist for the > > > > >> in-band case as the function being performed by both > > > > >> G.7714.1 and the Jx Test Message Connetivity > > > > >> Verification approach defined in lmp-test-sonet-sdh > > > > >> is the same. > > > > >> > > > > > JD: I don't think that is correct. The LMP Test > > > > > procedure is used to exchange the GMPLS identifiers > > > > > for a given data link. Since the GMPLS identifiers > > > > > may not be globally unique, it is necessary to qualify > > > > > them with a Verify ID, which identifies the particular > > > > > Test procedure the identifiers are associated with. > > > > > G.7714.1 is used to exchange the transport level > > > > > identifiers for a given link. > > > > > > > > G.7714.1 shows that the exchange of control plane > > > > identifiers (e.g. GMPLS TE-Link IDs) is done as a part > > > > of service capability exchange process which comes after > > > > the neighbor has been discovered. This was separated > > > > from the neighbor discovery mechanism to allow the > > > > neighbor discovery function to be used by things other > > > > than the control plane (i.e. management systems). > > > > > > > > It should be noted that Appendix III of G.7714.1 suggests > > > > a way to use LMP's trace correlation mechanism to > > > > accomplish this, which then dovetails into the rest of > > > > LMPs processes. > > > > > > JD: Your original statement, to which I responded, was: > > > "as the function being performed by both G.7714.1 and the > > > Jx Test Message Connetivity Verification approach defined > > > in lmp-test-sonet-sdh is the same." What you're now saying > > > is that there is a neighbor discovery piece to G.7714.1 > > > which has no equivalent in the LMP Test procedures, followed > > > by the LMP Test procedure using the trace correlation > > > tranport mechanism. > > > > I tend to look things from a functional decomposition > > perspective, and not at the specific bits/bytes. > > > > The goal being sought is: > > - determination that a link exists > > - determination that it is not miswired > > - exchange of control plane names for the endpoints > > of that link > > > > Two in-band methods exist that accomplish this goal for a > > SONET/SDH link. They are: > > draft-ietf-ccamp-lmp-test-sonet-sdh > > and > > G.7714.1 (including Appendix III) > > JD: What you're glossing over here is that fact that according > to your previous e-mail, Appendix III of G.7714.1 is actually > the LMP Test procedure using the trace correlation transport > mechanism. So, even in G.7714.1 as it currently exists, the > only way to exchange control plane identifiers is the LMP Test > procedure. Remember, the subject for discussion here is the message sent in-band in the Jx trace bytes. The use of the LMP Test procedure in Appendix III is limited to the trace correlation method, which is sent over the DCN. > > Both methods describe message formats that intrusively use > > the Jx strings. While the formats are different, the > > function accomplished is identical. > > JD: As I mentioned previously, neighbor discovery in G.7714.1 > has no LMP equivalent. Exchange of control plane identifiers > uses the LMP Test procedure in both cases. Incorrect assertion. Both the neighbor discovery method in G.7714.1 and intrusive Jx messages defined in lmp-test-sonet-sdh achieve goals 1 and 2. Goal 3 was identified by G.7714 to be technology independent, and therefore something that should be carried over the DCN. Jx does not need to be involved in mechanism that accomplishes Goal 3. This is why it does not appear in the Jx message format. ============================================================ 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, 29 Apr 2003 11:44:09 +0000 Message-Id: <200304291139.HAA12903@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-architecture-06.txt Date: Tue, 29 Apr 2003 07:39:24 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching Architecture Author(s) : E. Mannie Filename : draft-ietf-ccamp-gmpls-architecture-06.txt Pages : 57 Date : 2003-4-28 Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-06.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-architecture-06.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-architecture-06.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: <2003-4-28123853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-architecture-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-28123853.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2003 04:37:46 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C0D2F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: FW: Evaluation: draft-ietf-ccamp-lmp - Link Management Protocol ( LMP) to Proposed Standard Date: Tue, 29 Apr 2003 06:36:53 +0200 MIME-Version: 1.0 Content-Type: text/plain Issues from IESG review -----Original Message----- From: Steven M. Bellovin [mailto:smb@research.att.com] Sent: dinsdag 29 april 2003 4:38 I'm not sure how much the ccamp and forces people talk, but isn't this sentence: the control channel MUST terminate on the same two nodes that the TE link spans. incorrect with remote control elements? 16.2: The IPsec selectors are all SHOULDs -- what are the MUSTs? Setting the port number to 0 means that all UDP traffic between those nodes is protected -- is that right? I though the document spoke of an LMP port. The channel identifer is part of the payload, not the IP or UDP headers, and thus can't be a selector. IKE is listed as a SHOULD, not a MUST, but the requirements mandate replay detection. You can't do that with manual keying. (The requirements also mandate support for manual keying.) If replay protection is needed, either IKE must be required, or an application-specific replay protection mechanism must be defined. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2003 03:57:18 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C0D1A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Ron Bonica , ccamp@ops.ietf.org, bwijnen@lucent.com Subject: RE: draft-ietf-ccamp-tracereq-01.txt Date: Tue, 29 Apr 2003 05:54:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks... busy with other things now. Will check early next week. Pls ping me if I do not answer by say Wed next week. Thanks, Bert > -----Original Message----- > From: Ron Bonica [mailto:Ronald.P.Bonica@mci.com] > Sent: maandag 28 april 2003 18:58 > To: ccamp@ops.ietf.org; bwijnen@lucent.com > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > Bert, > > I have spun a new version of draft-ietf-ccamp-tracereq. It is > available at > http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-02.txt. > Please take a > look. > > If you think that this version addresses the IESG concerns, I > will post send > it to the draft editor. > > Ron > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Ron Bonica > > Sent: Monday, April 21, 2003 5:51 PM > > To: ccamp@ops.ietf.org; bwijnen@lucent.com > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > > > > Bert, > > > > Sorry to have taken so long to respond. I have been away on > vacation. > > > > Comments inline..... > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Wijnen, Bert (Bert) > > > Sent: Wednesday, April 16, 2003 9:30 AM > > > To: Ccamp-wg (E-mail) > > > Subject: FW: draft-ietf-ccamp-tracereq-01.txt > > > > > > > > > Please consider these comments and let me know if they > > > wrrant some additional text in the ID. > > > > > > Thanks, > > > Bert > > > > > > >***** o Tracing Requirements for Generic Tunnels (None) > > > > > > > > Token: Wijnen, Bert > > > > Note: New revision Addresses comments. > > > > Now on IESG agenda for April 17th > > > > Responsible: Bert > > > > > > 1. this document looks like it might be the union of all the > > > "i want it to do " requests. an important part of > > > requirements documents is knowing what to not require. > > > do they have any? > > > > This document specifies requirements for a new protocol. It > specifies > > requirements, primarily, by detailing the required capabilities of > > applications that will use this protocol. The application > may implement > > some subset of those capabilities. It may also implement a > superset of > > the required capabilities. However, protocol designers are > not required > > to consider the additional capabilities when designing the protocol. > > > > I can add some text to this effect. > > > > > 2. i am concerned about the security stuff that they've buried in > > > their requirements. nothing definite. it seems unwieldy. but > > > then, so many security things do... > > > > Can you be more specific? Is there any particular requirement that > > you feel cannot be implemented? > > > > > 3. section 4.1 and 4.2 seem to be worded with a particular > > > implementation in mind. requirements documents ought not > > > specify solutions (eg, 4.2 talks about udp, why can't i use > > > icmp?) > > > > Section 4 provides a few protocol requirements, stated as such. In > > particular, Section 4.1 states that the new protocol will consist of > > probes and responses, and that each probe/response pair will reveal > > information regarding a network hop. (In this respect, the > new protocol > > will resemble TRACEROUTE). > > > > Had I remembered to include an application requirement to > support partial > > traces through broken paths, this requirement would have > made much more > > sense! > > I will fix this. > > > > Section 4.2 requires that the protocol be implemented over > UDP. I included > > this > > section primarily to rule out implmentations that were _not_ > > acceptable. For > > example, > > ICMP should not be used, because carrying MPLS information > over ICMP would > > constitute > > a layer violation. TCP should not be used, because this would > > conflict with > > the protocol's > > requirement for statelessness. Tunnel specific mechanisms > should not be > > used, because > > this would conflict with the requirement for generality. > > > > This leaves UDP and IP as the two most resonable candidates. > > > > I can add some words indicating how we arrived at this decision. > > > > > 4. justification of requirements might be nice. > > > > > > > I can add a sentence or two after each requirement. > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2003 03:57:11 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C0D1F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: CCAMP WG Last Call for Overlay document Date: Tue, 29 Apr 2003 05:54:30 +0200 MIME-Version: 1.0 Content-Type: text/plain Kireeti, you write: > In the previous Last Call, many folks replied to me personally. It is > in general preferable to reply to the list, in the interest of a more > open and accountable IETF process. If you do wish to reply privately, > include at least one of the chairs and one of the ADs. Could we also have a summary of what sort of comments you got and from what sort of people? How many? And may I urge those people to go public with their comments? If you do not want to reveal your identity, then pls send them to the ADs. We can promise confidentiality if you do ask for it. Thanks, Bert > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: zaterdag 26 april 2003 5:06 > To: ccamp@ops.ietf.org > Subject: Re: CCAMP WG Last Call for Overlay document > > > > > On Sun, 23 Mar 2003, Kireeti Kompella wrote: > ... > > As there were no comments suggesting > > changes, and several private emails reinforcing the support > in the room, > > Ron and I will forward this document to the IESG for an > IETF Last Call. > > Okay, I have been corrected -- there were a few comments, mostly > editorial in nature. I suggest that the authors respin the doc, and > when they do, we will have a one week Last Call. > > In the previous Last Call, many folks replied to me personally. It is > in general preferable to reply to the list, in the interest of a more > open and accountable IETF process. If you do wish to reply privately, > include at least one of the chairs and one of the ADs. > > Thanks, > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Apr 2003 21:57:35 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC9724CA@nimbus> From: John Drake To: 'Jonathan Sadler' Cc: "Brungard, Deborah A, ALABS" , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, George Newsome , Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Mon, 28 Apr 2003 14:56:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > Sent: Monday, April 28, 2003 3:08 PM > To: John Drake > Cc: Brungard, Deborah A, ALABS; Stephen Trowbridge; > Jonathan.Lang@RinconNetworks.com; George Newsome; > Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); > zinin@psg.com > Subject: Re: Proposed response to the Liaison Statement on LMP Link > Verifi cation > > > John - > > See inline... > > Jonathan Sadler > > John Drake wrote: > > > Jonathan Sadler wrote: > > > John Drake wrote: > > > >> The liaison from T1X1 asked if it is necessary for two totally > > > >> independent message formats to exist for the in-band > case as the > > > >> function being performed by both G.7714.1 and the Jx > Test Message > > > >> Connetivity Verification approach defined in > lmp-test-sonet-sdh is > > > >> the same. > > > >> > > > > JD: I don't think that is correct. The LMP Test > procedure is used > > > > to exchange the GMPLS identifiers for a given data > link. Since the > > > > GMPLS identifiers may not be globally unique, it is necessary to > > > > qualify them with a Verify ID, which identifies the > particular Test > > > > procedure the identifiers are associated with. > G.7714.1 is used to > > > > exchange the transport level identifiers for a given link. > > > > > > G.7714.1 shows that the exchange of control plane > identifiers (e.g. > > > GMPLS TE-Link IDs) is done as a part of service > capability exchange > > > process which comes after the neighbor has been > discovered. This was > > > separated from the neighbor discovery mechanism to allow > the neighbor > > > discovery function to be used by things other than the > control plane > > > (i.e. management systems). > > > > > > It should be noted that Appendix III of G.7714.1 suggests > a way to use > > > LMP's trace correlation mechanism to accomplish this, which then > > > dovetails into the rest of LMPs processes. > > > > JD: Your original statement, to which I responded, was: > "as the function > > being performed by both G.7714.1 and the Jx Test Message > Connetivity Veri- > > fication approach defined in lmp-test-sonet-sdh is the > same." What you're > > now saying is that there is a neighbor discovery piece to > G.7714.1 which > > has no equivalent in the LMP Test procedures, followed by > the LMP Test pro- > > cedure using the trace correlation tranport mechanism. > > I tend to look things from a functional decomposition > perspective, and not at > the specific bits/bytes. > > The goal being sought is: > - determination that a link exists > - determination that it is not miswired > - exchange of control plane names for the endpoints of that link > > Two in-band methods exist that accomplish this goal for a > SONET/SDH link. They > are: > draft-ietf-ccamp-lmp-test-sonet-sdh > and > G.7714.1 (including Appendix III) JD: What you're glossing over here is that fact that according to your previous e-mail, Appendix III of G.7714.1 is actually the LMP Test procedure using the trace correlation transport mechanism. So, even in G.7714.1 as it currently exists, the only way to exchange control plane identifiers is the LMP Test procedure. > > Both methods describe message formats that intrusively use > the Jx strings. > While the formats are different, the function accomplished is > identical. JD: As I mentioned previously, neighbor discovery in G.7714.1 has no LMP equivalent. Exchange of control plane identifiers uses the LMP Test procedure in both cases. > > > So, in spite of what the G.7714.1 proponents have been > saying, there doesn't > > appear to be any functional overlap between the neighbor > discovery piece > > of G.7714.1 and the LMP Test Procedure. > > Not certain how you can say this given the above. > > The fact that G.7714.1 took into account that neighbor > discovery can be used in > the absence of the control plane, and therefore uses > transport plane identifiers > in the Jx message format, doesn't change its functional > equivalence when it is > used to support the control plane. > > And if you don't want to maintain a control-plane namespace > separate from the > transport-plane namespace, G.7714.1 does not proclude the > namespace mapping > function being as simple as: > f(x) = x JD: Control plane identifiers have different requirements from transport plane identifiers, which you implicitly acknowledged by using LMP in G.7714.1 to exchange control plane identifiers Snipped ... Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Apr 2003 17:11:28 +0000 Message-ID: <3EADA651.B8E83E73@tellabs.com> Date: Mon, 28 Apr 2003 17:08:17 -0500 From: Jonathan Sadler MIME-Version: 1.0 To: John Drake CC: "Brungard, Deborah A, ALABS" , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, George Newsome , Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John - See inline... Jonathan Sadler John Drake wrote: > Jonathan Sadler wrote: > > John Drake wrote: > > >> The liaison from T1X1 asked if it is necessary for two totally > > >> independent message formats to exist for the in-band case as the > > >> function being performed by both G.7714.1 and the Jx Test Message > > >> Connetivity Verification approach defined in lmp-test-sonet-sdh is > > >> the same. > > >> > > > JD: I don't think that is correct. The LMP Test procedure is used > > > to exchange the GMPLS identifiers for a given data link. Since the > > > GMPLS identifiers may not be globally unique, it is necessary to > > > qualify them with a Verify ID, which identifies the particular Test > > > procedure the identifiers are associated with. G.7714.1 is used to > > > exchange the transport level identifiers for a given link. > > > > G.7714.1 shows that the exchange of control plane identifiers (e.g. > > GMPLS TE-Link IDs) is done as a part of service capability exchange > > process which comes after the neighbor has been discovered. This was > > separated from the neighbor discovery mechanism to allow the neighbor > > discovery function to be used by things other than the control plane > > (i.e. management systems). > > > > It should be noted that Appendix III of G.7714.1 suggests a way to use > > LMP's trace correlation mechanism to accomplish this, which then > > dovetails into the rest of LMPs processes. > > JD: Your original statement, to which I responded, was: "as the function > being performed by both G.7714.1 and the Jx Test Message Connetivity Veri- > fication approach defined in lmp-test-sonet-sdh is the same." What you're > now saying is that there is a neighbor discovery piece to G.7714.1 which > has no equivalent in the LMP Test procedures, followed by the LMP Test pro- > cedure using the trace correlation tranport mechanism. I tend to look things from a functional decomposition perspective, and not at the specific bits/bytes. The goal being sought is: - determination that a link exists - determination that it is not miswired - exchange of control plane names for the endpoints of that link Two in-band methods exist that accomplish this goal for a SONET/SDH link. They are: draft-ietf-ccamp-lmp-test-sonet-sdh and G.7714.1 (including Appendix III) Both methods describe message formats that intrusively use the Jx strings. While the formats are different, the function accomplished is identical. > So, in spite of what the G.7714.1 proponents have been saying, there doesn't > appear to be any functional overlap between the neighbor discovery piece > of G.7714.1 and the LMP Test Procedure. Not certain how you can say this given the above. The fact that G.7714.1 took into account that neighbor discovery can be used in the absence of the control plane, and therefore uses transport plane identifiers in the Jx message format, doesn't change its functional equivalence when it is used to support the control plane. And if you don't want to maintain a control-plane namespace separate from the transport-plane namespace, G.7714.1 does not proclude the namespace mapping function being as simple as: f(x) = x > > >> Only the in-band issue needs to be discussed. > > >> > > >> Jonathan Sadler > > >> > > >> PS. I couldn't help but respond to Deborah's attempt to clarify: > > >> > > >> "Brungard, Deborah A, ALABS" wrote: > > >> > db: Note, to clarify, G7714.1 requires all new G7714.1-aware > > >> > transport equipment, both terminations and intermediate > > >> equipment. > > >> > > >> This is untrue. The G.7714.1 formats are consistant with the > > >> capability required in G.707, making hardware changes unnecessary. > > >> The design of the message format was done with remoting of the > > >> Discovery Agent in mind -- allowing for non-G.7714.1-aware > > transport > > >> equipment to be a part of an overall system that does indeed use > > >> G.7714.1 formats. > > >> > > > > > > JD: I saw an e-mail yesterday from Maarten Vissers yesterday sent > > > to one of the T1X1 mailing lists indicating the exact opposite. I > > > have asked him to re-post it here. > > > > > I am aware of the e-mail that you are referencing. > > > > If you read the message completely, you will find that he was actually > > challenging the statement in the liaison from T1X1.5 which says > > equipment changes will be necessary to support G.7714.1 > > methods. He goes > > on to state that the G.7714.1 process can attach (via an "application > > switch") to the MI_TxTI interface (which is an Equipment Mangement > > Function (EMF) to hardware interface) to send the G.7714.1 > > message, and > > attach to the MI_AcTI signal to monitor for incoming G.7714.1 > > messages. > > > > Of course this switch is only necessary if the TTI being monitored (by > > the NIM) is using a non-G.7714.1 (i.e. G.831/T1.269) format message. > > > > (For those interested in deciphering this alphabet soup, you can find > > definitions in G.7710, G.798 and G.806.) > > JD: I read it differently, but I will leave it to you folks figure out > how to try and make G.7714.1 actually work. In the spirit of the IETF -- running code does exist. And it didn't require any hardware changes... ============================================================ 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: Mon, 28 Apr 2003 16:59:28 +0000 Date: Mon, 28 Apr 2003 12:57:47 -0400 From: Ron Bonica Subject: RE: draft-ietf-ccamp-tracereq-01.txt To: ccamp@ops.ietf.org, bwijnen@lucent.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Bert, I have spun a new version of draft-ietf-ccamp-tracereq. It is available at http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-02.txt. Please take a look. If you think that this version addresses the IESG concerns, I will post send it to the draft editor. Ron > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Ron Bonica > Sent: Monday, April 21, 2003 5:51 PM > To: ccamp@ops.ietf.org; bwijnen@lucent.com > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > Bert, > > Sorry to have taken so long to respond. I have been away on vacation. > > Comments inline..... > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Wijnen, Bert (Bert) > > Sent: Wednesday, April 16, 2003 9:30 AM > > To: Ccamp-wg (E-mail) > > Subject: FW: draft-ietf-ccamp-tracereq-01.txt > > > > > > Please consider these comments and let me know if they > > wrrant some additional text in the ID. > > > > Thanks, > > Bert > > > > >***** o Tracing Requirements for Generic Tunnels (None) > > > > > > Token: Wijnen, Bert > > > Note: New revision Addresses comments. > > > Now on IESG agenda for April 17th > > > Responsible: Bert > > > > 1. this document looks like it might be the union of all the > > "i want it to do " requests. an important part of > > requirements documents is knowing what to not require. > > do they have any? > > This document specifies requirements for a new protocol. It specifies > requirements, primarily, by detailing the required capabilities of > applications that will use this protocol. The application may implement > some subset of those capabilities. It may also implement a superset of > the required capabilities. However, protocol designers are not required > to consider the additional capabilities when designing the protocol. > > I can add some text to this effect. > > > 2. i am concerned about the security stuff that they've buried in > > their requirements. nothing definite. it seems unwieldy. but > > then, so many security things do... > > Can you be more specific? Is there any particular requirement that > you feel cannot be implemented? > > > 3. section 4.1 and 4.2 seem to be worded with a particular > > implementation in mind. requirements documents ought not > > specify solutions (eg, 4.2 talks about udp, why can't i use > > icmp?) > > Section 4 provides a few protocol requirements, stated as such. In > particular, Section 4.1 states that the new protocol will consist of > probes and responses, and that each probe/response pair will reveal > information regarding a network hop. (In this respect, the new protocol > will resemble TRACEROUTE). > > Had I remembered to include an application requirement to support partial > traces through broken paths, this requirement would have made much more > sense! > I will fix this. > > Section 4.2 requires that the protocol be implemented over UDP. I included > this > section primarily to rule out implmentations that were _not_ > acceptable. For > example, > ICMP should not be used, because carrying MPLS information over ICMP would > constitute > a layer violation. TCP should not be used, because this would > conflict with > the protocol's > requirement for statelessness. Tunnel specific mechanisms should not be > used, because > this would conflict with the requirement for generality. > > This leaves UDP and IP as the two most resonable candidates. > > I can add some words indicating how we arrived at this decision. > > > 4. justification of requirements might be nice. > > > > I can add a sentence or two after each requirement. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Apr 2003 15:32:23 +0000 Message-ID: <3EAD4939.4020202@ieee.org> Date: Mon, 28 Apr 2003 11:31:05 -0400 From: George Newsome 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: "Brungard, Deborah A, ALABS" CC: Jonathan Sadler , John Drake , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verific ation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brungard, Deborah A, ALABS wrote: > Hi Jonathan, > > You missed most of the discussion, one can not take vacations from > the ccamp exploder;-) > Its a good job that the whole thread is stored isn't it :-) >.............. > > The liaison from T1X1 asked: 2. Determination of whether it would be > possible to use the identical message formats in the subject draft > as in G.7714.1 for the connectivity verification function. 3. > Determination of whether it would be possible to use the same > overall structure (distinguishing character, 4 bit message type, 80 > bit message body) if a different message format or information > content is required. > > The answer from the LMP authors: As the LMP message content is > control information, use of printable characters is not an > appropriate requirement and it is an inappropriate constraint. And > the LMP messages can not use the G7714.1 structure. This answer is > not simply a statement, it is a rationale for the choices. We do > not require Corba to use printable messages, is that considered a > "statement" or a choice? Ask your Corba developers. > The answer suggests that only printable chars can be used to construct the identifiers, and that is simply not true. This simply confuses the message content with the form of the message on the wire - they are very different. Printable chars is merely a coding to provide a better match to the available Jx channel, (which actually starts at a provisioning system.) > To support a liaison response in a timely manner, let's focus on > specific wording changes. I still have not seen any suggested > wording changes on the liaison response as proposed. > Its hard to agree on specific words when the intent of the liaison does not seem to be agreed. Regards George Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Apr 2003 14:58:16 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed response to the Liaison Statement on LMP Link Verific ation Date: Mon, 28 Apr 2003 10:54:40 -0400 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA685@OCCLUST02EVS1.ugd.att.com> Thread-Topic: Proposed response to the Liaison Statement on LMP Link Verific ation Thread-Index: AcMLfIYu+SkQEnEiS72TN6rv5HHXwwCE+Q/w From: "Brungard, Deborah A, ALABS" To: "Jonathan Sadler" , "John Drake" Cc: "Stephen Trowbridge" , , "George Newsome" , , "Wijnen, Bert (Bert)" , , , "Ron Bonica (E-mail)" , Hi Jonathan, You missed most of the discussion, one can not take vacations from the = ccamp exploder;-) I had recommended focusing on the liaison response, and re-focusing the = other discussion to other threads. Example, most of the email exchange = is focused on understanding G7714.1 and LMP. There's a ccamp draft on = this: draft-aboulmagd-ccamp-transort-lmp. As the draft has not generated = any comments on the list, it's surprising the amount of discussion. The liaison from T1X1 asked: 2. Determination of whether it would be possible to use the identical = message formats in the subject draft as in G.7714.1 for the connectivity = verification function. =20 3. Determination of whether it would be possible to use the same overall = structure (distinguishing character, 4 bit message type, 80 bit message = body) if a different message format or information content is required. The answer from the LMP authors: As the LMP message content is control information, use of printable = characters is not an appropriate requirement and it is an inappropriate = constraint. And the LMP messages can not use the G7714.1 structure. This = answer is not simply a statement, it is a rationale for the choices. We = do not require Corba to use printable messages, is that considered a = "statement" or a choice? Ask your Corba developers. To support a liaison response in a timely manner, let's focus on = specific wording changes. I still have not seen any suggested wording = changes on the liaison response as proposed. And discussion on the equipment implementation should be on the Q9 = exploder. Deborah (t1x15 hatless) -----Original Message----- From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] Sent: Friday, April 25, 2003 11:43 PM To: John Drake Cc: Brungard, Deborah A, ALABS; Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; George Newsome; Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verific ation John Drake wrote: >> The liaison from T1X1 asked if it is necessary for two totally >> independent message formats to exist for the in-band case as the >> function being performed by both G.7714.1 and the Jx Test Message >> Connetivity Verification approach defined in lmp-test-sonet-sdh is >> the same. >> > JD: I don't think that is correct. The LMP Test procedure is used > to exchange the GMPLS identifiers for a given data link. Since the > GMPLS identifiers may not be globally unique, it is necessary to > qualify them with a Verify ID, which identifies the particular Test > procedure the identifiers are associated with. G.7714.1 is used to > exchange the transport level identifiers for a given link. > G.7714.1 shows that the exchange of control plane identifiers (e.g. GMPLS TE-Link IDs) is done as a part of service capability exchange process which comes after the neighbor has been discovered. This was separated from the neighbor discovery mechanism to allow the neighbor discovery function to be used by things other than the control plane (i.e. management systems). It should be noted that Appendix III of G.7714.1 suggests a way to use LMP's trace correlation mechanism to accomplish this, which then dovetails into the rest of LMPs processes. >> Only the in-band issue needs to be discussed. >> >> Jonathan Sadler >> >> PS. I couldn't help but respond to Deborah's attempt to clarify: >> >> "Brungard, Deborah A, ALABS" wrote: >> > db: Note, to clarify, G7714.1 requires all new G7714.1-aware >> > transport equipment, both terminations and intermediate >> equipment. >> >> This is untrue. The G.7714.1 formats are consistant with the >> capability required in G.707, making hardware changes unnecessary. >> The design of the message format was done with remoting of the >> Discovery Agent in mind -- allowing for non-G.7714.1-aware transport >> equipment to be a part of an overall system that does indeed use >> G.7714.1 formats. >> > > JD: I saw an e-mail yesterday from Maarten Vissers yesterday sent > to one of the T1X1 mailing lists indicating the exact opposite. I > have asked him to re-post it here. > I am aware of the e-mail that you are referencing. If you read the message completely, you will find that he was actually challenging the statement in the liaison from T1X1.5 which says equipment changes will be necessary to support G.7714.1 methods. He goes on to state that the G.7714.1 process can attach (via an "application switch") to the MI_TxTI interface (which is an Equipment Mangement Function (EMF) to hardware interface) to send the G.7714.1 message, and attach to the MI_AcTI signal to monitor for incoming G.7714.1 messages. Of course this switch is only necessary if the TTI being monitored (by the NIM) is using a non-G.7714.1 (i.e. G.831/T1.269) format message. (For those interested in deciphering this alphabet soup, you can find definitions in G.7710, G.798 and G.806.) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged=20 and confidential and protected from disclosure. If the=20 reader of this message is not the intended recipient, or an=20 employee or agent responsible for delivering this message to=20 the intended recipient, you are hereby notified that any=20 reproduction, dissemination or distribution of this=20 communication is strictly prohibited. If you have received=20 this communication in error, please notify us immediately by=20 replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 26 Apr 2003 03:07:06 +0000 Date: Fri, 25 Apr 2003 20:05:46 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Re: CCAMP WG Last Call for Overlay document Message-ID: <20030425195041.L91414@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > On Sun, 23 Mar 2003, Kireeti Kompella wrote: ... > As there were no comments suggesting > changes, and several private emails reinforcing the support in the room, > Ron and I will forward this document to the IESG for an IETF Last Call. Okay, I have been corrected -- there were a few comments, mostly editorial in nature. I suggest that the authors respin the doc, and when they do, we will have a one week Last Call. In the previous Last Call, many folks replied to me personally. It is in general preferable to reply to the list, in the interest of a more open and accountable IETF process. If you do wish to reply privately, include at least one of the chairs and one of the ADs. Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Apr 2003 23:31:52 +0000 Message-ID: <3EA9C6E5.5080505@alcatel.be> Date: Sat, 26 Apr 2003 01:38:13 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Jonathan Sadler Cc: John Drake , "Brungard, Deborah A, ALABS" , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, George Newsome , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verific ation Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed jonathan, see in-line... Jonathan Sadler wrote: > John Drake wrote: > > >>>The liaison from T1X1 asked if it is necessary for two totally >>>independent message formats to exist for the in-band case as the >>>function being performed by both G.7714.1 and the Jx Test Message >>>Connetivity Verification approach defined in lmp-test-sonet-sdh is >>>the same. >>> >> >>JD: I don't think that is correct. The LMP Test procedure is used >>to exchange the GMPLS identifiers for a given data link. Since the >>GMPLS identifiers may not be globally unique, it is necessary to >>qualify them with a Verify ID, which identifies the particular Test >>procedure the identifiers are associated with. G.7714.1 is used to >>exchange the transport level identifiers for a given link. >> > > > G.7714.1 shows that the exchange of control plane identifiers (e.g. > GMPLS TE-Link IDs) is done as a part of service capability exchange > process which comes after the neighbor has been discovered. This was > separated from the neighbor discovery mechanism to allow the neighbor > discovery function to be used by things other than the control plane > (i.e. management systems). > > It should be noted that Appendix III of G.7714.1 suggests a way to use > LMP's trace correlation mechanism to accomplish this, which then > dovetails into the rest of LMPs processes. let's be clear, G.7714.1 can make use of LMP for its out-of-band response message - but this does not make G.7714.1 a control plane application (instead of LMP the response can be transported over TL1 for instance ;-) also please keep in mind that this is not equivalent to the method described by john here above - you do not have a "verify id" exchange in this process since you do not negotiate through BeginVerify/Ack the test message exchange >>>Only the in-band issue needs to be discussed. >>> >>>Jonathan Sadler >>> >>>PS. I couldn't help but respond to Deborah's attempt to clarify: >>> >>>"Brungard, Deborah A, ALABS" wrote: >>> > db: Note, to clarify, G7714.1 requires all new G7714.1-aware >>> > transport equipment, both terminations and intermediate >>>equipment. >>> >>>This is untrue. The G.7714.1 formats are consistant with the >>>capability required in G.707, making hardware changes unnecessary. >>>The design of the message format was done with remoting of the >>>Discovery Agent in mind -- allowing for non-G.7714.1-aware transport >>>equipment to be a part of an overall system that does indeed use >>>G.7714.1 formats. >>> >> >>JD: I saw an e-mail yesterday from Maarten Vissers yesterday sent >>to one of the T1X1 mailing lists indicating the exact opposite. I >>have asked him to re-post it here. >> > > I am aware of the e-mail that you are referencing. > > If you read the message completely, you will find that he was actually > challenging the statement in the liaison from T1X1.5 which says > equipment changes will be necessary to support G.7714.1 methods. He goes > on to state that the G.7714.1 process can attach (via an "application > switch") to the MI_TxTI interface (which is an Equipment Mangement > Function (EMF) to hardware interface) to send the G.7714.1 message, and > attach to the MI_AcTI signal to monitor for incoming G.7714.1 messages. > > Of course this switch is only necessary if the TTI being monitored (by > the NIM) is using a non-G.7714.1 (i.e. G.831/T1.269) format message. i thought this was what G.7714.1 claimed to deliver from the rigth beginning ? and now we see this is not the case ? in brief i think what you say here is that G.7714.1 is not backward compatible with G.831 ? > (For those interested in deciphering this alphabet soup, you can find > definitions in G.7710, G.798 and G.806.) once again, this means that the method developed by the itu does not seem to be ready since in order to avoid the hardware change a "soft-switch" has to be defined now please keep in mind that the t1x1 liaison "proposes if possible" and let the door open for the ietf community to select the process this community think relevant for its control plane applications > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Apr 2003 23:25:04 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC9724C7@nimbus> From: John Drake To: 'Jonathan Sadler' Cc: "Brungard, Deborah A, ALABS" , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, George Newsome , Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi c ation Date: Fri, 25 Apr 2003 16:24:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > Sent: Friday, April 25, 2003 8:43 PM > To: John Drake > Cc: Brungard, Deborah A, ALABS; Stephen Trowbridge; > Jonathan.Lang@RinconNetworks.com; George Newsome; > Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); > zinin@psg.com > Subject: Re: Proposed response to the Liaison Statement on LMP Link > Verific ation > > > John Drake wrote: > > >> The liaison from T1X1 asked if it is necessary for two totally > >> independent message formats to exist for the in-band case as the > >> function being performed by both G.7714.1 and the Jx Test Message > >> Connetivity Verification approach defined in lmp-test-sonet-sdh is > >> the same. > >> > > JD: I don't think that is correct. The LMP Test procedure is used > > to exchange the GMPLS identifiers for a given data link. Since the > > GMPLS identifiers may not be globally unique, it is necessary to > > qualify them with a Verify ID, which identifies the particular Test > > procedure the identifiers are associated with. G.7714.1 is used to > > exchange the transport level identifiers for a given link. > > > > G.7714.1 shows that the exchange of control plane identifiers (e.g. > GMPLS TE-Link IDs) is done as a part of service capability exchange > process which comes after the neighbor has been discovered. This was > separated from the neighbor discovery mechanism to allow the neighbor > discovery function to be used by things other than the control plane > (i.e. management systems). > > It should be noted that Appendix III of G.7714.1 suggests a way to use > LMP's trace correlation mechanism to accomplish this, which then > dovetails into the rest of LMPs processes. JD: Your original statement, to which I responded, was: "as the function being performed by both G.7714.1 and the Jx Test Message Connetivity Veri- fication approach defined in lmp-test-sonet-sdh is the same." What you're now saying is that there is a neighbor discovery piece to G.7714.1 which has no equivalent in the LMP Test procedures, followed by the LMP Test pro- cedure using the trace correlation tranport mechanism. So, in spite of what the G.7714.1 proponents have been saying, there doesn't appear to be any functional overlap between the neighbor discovery piece of G.7714.1 and the LMP Test Procedure. > > >> Only the in-band issue needs to be discussed. > >> > >> Jonathan Sadler > >> > >> PS. I couldn't help but respond to Deborah's attempt to clarify: > >> > >> "Brungard, Deborah A, ALABS" wrote: > >> > db: Note, to clarify, G7714.1 requires all new G7714.1-aware > >> > transport equipment, both terminations and intermediate > >> equipment. > >> > >> This is untrue. The G.7714.1 formats are consistant with the > >> capability required in G.707, making hardware changes unnecessary. > >> The design of the message format was done with remoting of the > >> Discovery Agent in mind -- allowing for non-G.7714.1-aware > transport > >> equipment to be a part of an overall system that does indeed use > >> G.7714.1 formats. > >> > > > > JD: I saw an e-mail yesterday from Maarten Vissers yesterday sent > > to one of the T1X1 mailing lists indicating the exact opposite. I > > have asked him to re-post it here. > > > I am aware of the e-mail that you are referencing. > > If you read the message completely, you will find that he was actually > challenging the statement in the liaison from T1X1.5 which says > equipment changes will be necessary to support G.7714.1 > methods. He goes > on to state that the G.7714.1 process can attach (via an "application > switch") to the MI_TxTI interface (which is an Equipment Mangement > Function (EMF) to hardware interface) to send the G.7714.1 > message, and > attach to the MI_AcTI signal to monitor for incoming G.7714.1 > messages. > > Of course this switch is only necessary if the TTI being monitored (by > the NIM) is using a non-G.7714.1 (i.e. G.831/T1.269) format message. > > (For those interested in deciphering this alphabet soup, you can find > definitions in G.7710, G.798 and G.806.) JD: I read it differently, but I will leave it to you folks figure out how to try and make G.7714.1 actually work. > > > ============================================================ > 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: Fri, 25 Apr 2003 22:48:29 +0000 Message-ID: <3EAA0050.CFCBED6B@tellabs.com> Date: Fri, 25 Apr 2003 22:43:12 -0500 From: Jonathan Sadler MIME-Version: 1.0 To: John Drake CC: "Brungard, Deborah A, ALABS" , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, George Newsome , Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verific ation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Drake wrote: >> The liaison from T1X1 asked if it is necessary for two totally >> independent message formats to exist for the in-band case as the >> function being performed by both G.7714.1 and the Jx Test Message >> Connetivity Verification approach defined in lmp-test-sonet-sdh is >> the same. >> > JD: I don't think that is correct. The LMP Test procedure is used > to exchange the GMPLS identifiers for a given data link. Since the > GMPLS identifiers may not be globally unique, it is necessary to > qualify them with a Verify ID, which identifies the particular Test > procedure the identifiers are associated with. G.7714.1 is used to > exchange the transport level identifiers for a given link. > G.7714.1 shows that the exchange of control plane identifiers (e.g. GMPLS TE-Link IDs) is done as a part of service capability exchange process which comes after the neighbor has been discovered. This was separated from the neighbor discovery mechanism to allow the neighbor discovery function to be used by things other than the control plane (i.e. management systems). It should be noted that Appendix III of G.7714.1 suggests a way to use LMP's trace correlation mechanism to accomplish this, which then dovetails into the rest of LMPs processes. >> Only the in-band issue needs to be discussed. >> >> Jonathan Sadler >> >> PS. I couldn't help but respond to Deborah's attempt to clarify: >> >> "Brungard, Deborah A, ALABS" wrote: >> > db: Note, to clarify, G7714.1 requires all new G7714.1-aware >> > transport equipment, both terminations and intermediate >> equipment. >> >> This is untrue. The G.7714.1 formats are consistant with the >> capability required in G.707, making hardware changes unnecessary. >> The design of the message format was done with remoting of the >> Discovery Agent in mind -- allowing for non-G.7714.1-aware transport >> equipment to be a part of an overall system that does indeed use >> G.7714.1 formats. >> > > JD: I saw an e-mail yesterday from Maarten Vissers yesterday sent > to one of the T1X1 mailing lists indicating the exact opposite. I > have asked him to re-post it here. > I am aware of the e-mail that you are referencing. If you read the message completely, you will find that he was actually challenging the statement in the liaison from T1X1.5 which says equipment changes will be necessary to support G.7714.1 methods. He goes on to state that the G.7714.1 process can attach (via an "application switch") to the MI_TxTI interface (which is an Equipment Mangement Function (EMF) to hardware interface) to send the G.7714.1 message, and attach to the MI_AcTI signal to monitor for incoming G.7714.1 messages. Of course this switch is only necessary if the TTI being monitored (by the NIM) is using a non-G.7714.1 (i.e. G.831/T1.269) format message. (For those interested in deciphering this alphabet soup, you can find definitions in G.7710, G.798 and G.806.) ============================================================ 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: Fri, 25 Apr 2003 21:45:17 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC9724C5@nimbus> From: John Drake To: 'Jonathan Sadler' , "Brungard, Deborah A, ALABS" Cc: Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, George Newsome , Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Fri, 25 Apr 2003 14:44:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Comments inline > -----Original Message----- > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > Sent: Friday, April 25, 2003 1:49 PM > To: Brungard, Deborah A, ALABS > Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; George > Newsome; Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); > zinin@psg.com > Subject: Re: Proposed response to the Liaison Statement on LMP Link > Verification > > > I see the discussion as being broken down as follows: > - What should be sent in-band to identify a CP-link > - What could be sent out-of-band to identify a CP-link > (through trace correlation) > > G.7714.1 deals only with the in-band approach. lmp-test-sonet-sdh > deals with both approaches. > > The out-of-band case handled by lmp-test-sonet-sdh is out of scope > for G.7714.1 -- what two consenting systems, management or otherwise, > exchange across their DCNs is out of scope for G.7714.1. > > The liaison from T1X1 asked if it is necessary for two totally > independent message formats to exist for the in-band case as the > function being performed by both G.7714.1 and the Jx Test Message > Connetivity Verification approach defined in lmp-test-sonet-sdh is > the same. JD: I don't think that is correct. The LMP Test procedure is used to exchange the GMPLS identifiers for a given data link. Since the GMPLS identifiers may not be globally unique, it is necessary to qualify them with a Verify ID, which identifies the particular Test procedure the identifiers are associated with. G.7714.1 is used to exchange the transport level identifiers for a given link. > > Only the in-band issue needs to be discussed. > > Jonathan Sadler > > PS. I couldn't help but respond to Deborah's attempt to clarify: > > "Brungard, Deborah A, ALABS" wrote: > > db: Note, to clarify, G7714.1 requires all new G7714.1-aware > > transport equipment, both terminations and intermediate equipment. > > This is untrue. The G.7714.1 formats are consistant with the > capability required in G.707, making hardware changes unnecessary. > The design of the message format was done with remoting of the > Discovery Agent in mind -- allowing for non-G.7714.1-aware transport > equipment to be a part of an overall system that does indeed use > G.7714.1 formats. JD: I saw an e-mail yesterday from Maarten Vissers yesterday sent to one of the T1X1 mailing lists indicating the exact opposite. I have asked him to re-post it here. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Apr 2003 20:52:15 +0000 Message-ID: <3EA99F34.3060700@tellabs.com> Date: Fri, 25 Apr 2003 15:48:52 -0500 From: Jonathan Sadler User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.2.1) Gecko/20030107 MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, George Newsome , Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verification Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I see the discussion as being broken down as follows: - What should be sent in-band to identify a CP-link - What could be sent out-of-band to identify a CP-link (through trace correlation) G.7714.1 deals only with the in-band approach. lmp-test-sonet-sdh deals with both approaches. The out-of-band case handled by lmp-test-sonet-sdh is out of scope for G.7714.1 -- what two consenting systems, management or otherwise, exchange across their DCNs is out of scope for G.7714.1. The liaison from T1X1 asked if it is necessary for two totally independent message formats to exist for the in-band case as the function being performed by both G.7714.1 and the Jx Test Message Connetivity Verification approach defined in lmp-test-sonet-sdh is the same. Only the in-band issue needs to be discussed. Jonathan Sadler PS. I couldn't help but respond to Deborah's attempt to clarify: "Brungard, Deborah A, ALABS" wrote: > db: Note, to clarify, G7714.1 requires all new G7714.1-aware > transport equipment, both terminations and intermediate equipment. This is untrue. The G.7714.1 formats are consistant with the capability required in G.707, making hardware changes unnecessary. The design of the message format was done with remoting of the Discovery Agent in mind -- allowing for non-G.7714.1-aware transport equipment to be a part of an overall system that does indeed use G.7714.1 formats. Compare this with the intrusive Jx Test Message formats defined by lmp-test-sonet-sdh. The behavior of a legacy element that recieves this non-printable string is unknown, let alone how to configure (using TL1) the TTI to be validated by a NIM. > And for operators, "turning-off" of legacy intermediate NIMs is not > an option (proposed in G7714.1), G.7714.1 also states that how the message formats defined in G.7714.1 interact with functions such as NIM is for future study as turning off these functions may not be necessary. Indeed, turning off NIM is unnecessary if the NIM is using a G.7714.1 message format for the TTI. > as the investment in intermediate NIMs is not for 24/7 > entertainment of our field staff. G7714.1 does not "peacefully > coexist". Nor do the intrusive Jx Test Message formats defined by draft-ietf-ccamp-lmp-test-sonet-sdh. Further, it is impossible to provision the resulting non-printable string to be used for the TTI making these formats impossible to use with legacy NIMs. > One ITU operator suggested using a different byte than Jx based > on this concern with G7714.1. > > Whereas, LMP requires GMPLS-aware transport equipment. I'm not certain if this is a benefit as the intrusive Jx Test Message formats defined by lmp-test-sonet-sdh restrict the deployment of GMPLS to only new equipment. Use of a byte other than Jx for this function yields the same situation. Given the amount of SONET/SDH equipment already deployed, the business models necessary for Telcos to be profitable, and the current CAPEX spending environment, limiting GMPLS to new equipment deployments will not aid in the rapid deployment of GMPLS. However, if the protocols allow for the GMPLS control plane to be external from a LEGACY element, there is a better chance for rapid GMPLS deployment. > And LMP provides two options depending on support by legacy > equipment (in-band, correlation). Two comments: 1) Only in-band signals can guarantee the proper identification of a CP-link. 2) The correlation method defined by lmp-test-sonet-sdh is not precluded by G.7714.1 -- what two consenting systems exchange across their DCNs is out of scope for G.7714.1 > For either G7714.1 or GMPLS LMP, an operator chooses equipment > configurations/options based on their application. New > applications/new equipment (no free lunch;-)). Incorrect assertion -- see above. > No different from today's operations. And the two options > (in-band, correlated) provided by LMP support two different > use scenarios, including use of legacy NIMs. As discussed > for G7714.1, Q9 needs to evaluate the equipment support > scenarios. ============================================================ 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: Fri, 25 Apr 2003 17:56:43 +0000 Date: Fri, 25 Apr 2003 10:55:34 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Re: CCAMP WG Last Call for Overlay document Message-ID: <20030425104914.D89335@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi All, On Sun, 23 Mar 2003, Kireeti Kompella wrote: > There was reasonable support for draft-ietf-ccamp-gmpls-overlay-01 > at the meeting. So, this is a two-week WG Last Call for this doc. > It is my understanding that this is targeted as Proposed Standard. ... > The Last Call ends Sunday April 6, 2003 at midnight PDT. This Last Call has (way) ended. As there were no comments suggesting changes, and several private emails reinforcing the support in the room, Ron and I will forward this document to the IESG for an IETF Last Call. Thanks to an alert CCAMP participant for reminding the chairs! Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Apr 2003 16:54:35 +0000 Message-ID: <3EA9691C.2000302@alcatel.be> Date: Fri, 25 Apr 2003 18:58:04 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: "Ccamp-wg (E-mail)" Cc: "Wijnen, Bert (Bert)" , Dimitrios Pendarakis , "Steven M. Bellovin" Subject: Re: draft-ietf-ccamp-gmpls-architecture Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed ccamp'ers, after the received iesg comments, a respin of the gmpls architecture i-d is under submission, the following changes have been provided: - grammatical and other editorial changes - new short paragraph on lmp development (randy's comment) as previously proposed on this list - revisited security section (i'd like to thank here, steve and dimitrios for their precious help) thanks, - dimitri. Wijnen, Bert (Bert) wrote: > Steve thanks for the input/review. > > Dimitrios and Dimitri, if the two of you could respind the > draft (by Thursday at the latest) to try and address Steves > (and other, as posted to the list) comments, then I can > put it back on IESG agenda for next week. > > Thanks, > Bert > > >>-----Original Message----- >>From: Steven M. Bellovin [mailto:smb@research.att.com] >>Sent: dinsdag 22 april 2003 18:31 >>To: Dimitrios Pendarakis >>Cc: 'Wijnen, Bert (Bert)'; Ccamp-wg (E-mail); zinin@psg.com >>Subject: Re: draft-ietf-ccamp-gmpls-architecture >> >> >>In message >><05707214338CD5119BFF0040A5B170D30347EEDB@mail3.tellium.com>, Dimitr >>ios Pendarakis writes: >> >>>Bert, >>> >>>Comments on the issues brought up by Steve: >>>i) The risk of attackers being able to inject and/or snoop on >>> (control) traffic depends on both the physical characteristics >>> of the control link and whether the interface is an inter- or >>> intra-domain one. For example, an in-band, in-fiber control >>> channel over SONET/SDH overhead bytes is, in general, considered >>> less vulnerable than an out-of-band IP network. >> >>Similarly, however, >> >>> most carriers seem to consider control links that are not within >>> their control (intra-domain) less secure. >>> >>> Proposed resolution: Add statement in the document stressing the >>> dependency on control link physical characteristics. >> >>And delete the text about intra-domain versus inter-domain -- that's >>not relevant here. >> >> >>>ii) Difference between authentication and authorization. I believe >>> authorization falls in the category of what is commonly called >>> "policy control". Steve is right about pointing this out, as well >>> as the implications of appropriate policy controls to increase >>> security and limit the impact of attacks. >>> >>> Proposed resolution: Expand on the difference, add >> >>references for >> >>> policy control (rap WG?) and Steve's comment. I can provide some >>> updated text for this, as well as (i). >> >>I don't think that that's right. The issue is who has the right to, >>say, allocate or reallocate lambdas between given pairs of switches. >>Note that there are two very different questions here: how to >>represent, on the wire, the resources that are available to a given >>party, and how to make more complex decisions, such as a limit on the >>total bandwidth available to some party in the presence of contention >>for certain resources. Simple policies -- "party A, >>identified by the >>following mechanism, may request N megabits/sec" are simple. >>But what >>about requests for enough different lambdas that a given waveband of >>the desired capacity is not available? >> >>You can't solve this broader problem here; that's the sort of thing I >>would like in some follow-on document. But this document needs to >>sketch the problem in enough detail that implementors are >>aware of it. >>(In some sense, the solution doesn't require >>interoperability. Control >>elements will receive request and match them against the >>local security >>policy. My goal for this document is that the requirement be spelled >>out clearly enough that people will understand the need. >> >>>iii) Need for a (broader) security architecture. Clearly, a >> >>small section >> >>> in the architecture document can not claim to address >> >>all security >> >>> issues. I recall that there have been some individual >> >>draft submissions >> >>> in the past regarding security requirements. >> >>Additionally, other bodies >> >>> such as the OIF have carried more work on securing intra-domain >>> interfaces for transport networks; some of that work >> >>could hopefully be >> >>> useful in this discussion. While much of the additional >> >>work involves >> >>> using profiles of existing IP security mechanisms in the >> >>ccamp context, >> >>> I can see benefits in terms of pursuing this further, >> >>especially since >> >>> it would help alleviate one of the concerns that >> >>carriers considering >> >>> deployment of GMPLS or similar solutions have. >>> >>>Thanks, >>>Dimitris >>> >>> >>>-----Original Message----- >>>From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >>>Sent: Wednesday, April 16, 2003 12:38 PM >>>To: Ccamp-wg (E-mail) >>>Cc: Steve Bellovin (E-mail) >>>Subject: FW: draft-ietf-ccamp-gmpls-architecture >>> >>> >>>Comments on the document from IESG. I think we need an answer >>>to the serious comment made by Steve >>> >>>-----Original Message----- >>>From: Steve Bellovin [mailto:smb@research.att.com] >>>Sent: woensdag 16 april 2003 18:20 >>>To: iesg-secretary@ietf.org >>>Cc: iesg@ietf.org >>>Subject: draft-ietf-ccamp-gmpls-architecture >>> >>> >>>Nit: section 4 says >>> >>> Re-using existing IP routing protocols allows for non-PSC >> >>layers to >> >>> take advantages of all the valuable developments that took place >>> since years for IP routing, >>> >>>which isn't grammatically correct. >>> >>>Serious issue: >>> >>>The Security Considerations section hints at, but doesn't follow >>>through with, the difference between authentication and >> >>authorization. >> >>>The requirement for cryptographic authentication or encryption >>>depends on the risk of attackers being able to inject and/or snoop >>>on traffic. This may or may not be correlated with intra-domain vs. >>>inter-domain GMPLS. The physical characteristics and exposure of the >>>link matter more; there may be additional exposure since it >> >>appears that >> >>>the control plane link may be more than one hop long. >>> >>>The authorization question is what resources a given node may request >>>of another. This may indeed be differ for inter-domain and >> >>intra-domain >> >>>GMPLS. On the other hand, imposing such limits even internally helps >>>guard against spreading break-ins, and has useful effects with regard >>>to configuration errors. >>> >>>The more important question raised by this latter point is whether or >>>not a security architecture is needed that specifies what sorts of >>>restrictions can be applied. I don't know the answer to >> >>that one; clearly, >> >>>though, implementors are going to have to decide. >>> >>> >>>************************************************************* >> >>********* >> >>>This email and any files transmitted with it are >> >>confidential and intended sol >> >>>ely for the use of the individual or entity to whom they are >> >>addressed. Any re >> >>>view, retransmission or other use of this communication by >> >>any person or entit >> >>>y other than the intended recipient is prohibited. If you >> >>believe that you hav >> >>>e received this email in error please notify the sender by >> >>return electronic m >> >>>ail and delete all copies of this communication. >>>************************************************************* >> >>********* >> >> >> --Steve Bellovin, http://www.research.att.com/~smb (me) >> http://www.wilyhacker.com (2nd edition of >>"Firewalls" book) >> >> > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Apr 2003 16:14:24 +0000 Message-ID: <3EA80CF7.7060609@alcatel.be> Date: Thu, 24 Apr 2003 18:12:39 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: "Razdan, Rajender" Cc: "'John Drake'" , "'George Newsome'" , "Brungard, Deborah A, ALABS" , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed rajender, i start to have strong issues with your assertions "it would seem common-sense to avoid having to support two different message formats, especially if it can be avoided." does it first make sense... let's see 1) how can you position yourself as an individual and say the ITU-T will jeopardize its transport plane application to carry control plane information for LMP ? this when you know perfectly well that nothing will be done on control plane discovery for ASON (that LMP intent and delivers today) until the next ITU-T chicago meeting ! 2) how can you tell us *now* adapt you format when you have reject during the G.7714.1 discussions *any LMP input* using the argument that a Verify_ID was useless in the scope of a data plane application ! - inferring thus that LMP was clearly intended to deliver a control plane application - does it has suddenly become something else (or does it change on demand)? 3) how can you claim "just change your format" and things will work while you know perfectly well that all assumptions made on the current G.7714.1 format are currently under discussion at Q9 in order to make it workable - ie without changing either all hardware or all management procedures - ... then we can think if it can be avoided (but since so far you ask to adapt LMP to something that doesn't exist so i wonder if it make sense ?) note: then definitelly you should re-read the bootstrap i-d (it does not say you have to use the G.7714.1 message format you * completely * mis-understand the intent of this document) thanks, - dimitri. Razdan, Rajender wrote: > John, > > I don't think anyone out here is stipulating that deployment of > GMPLS is gated by the deployment of G.7714.1. Your suggestion below > amounts to saying that we will use the LMP discovery trace byte > pattern for discovery purposes in GMPLS and change to G.7714.1 > pattern when dealing with systems where G.7714.1 is deployed. But > that is precisely what I'm arguing against the need for doing. As > I said in one of my earlier emails, it would seem common-sense to > avoid having to support two different message formats, especially > if it can be avoided. > > So let me re-paraphrase my original question, which I have yet to > see anyone answer: Is there anything about the G.7714.1 discovery > trace message that makes it unsuitable for your discovery protocol > within LMP? If not, I don't see what problem there is in changing > the LMP trace message format to match that of G.7714.1. It seems > to me that an earnest attempt to match these formats has already > been undertaken in the LMP bootstrap draft document. So what then > is the problem with doing the same for the LMP trace draft document? > > Rajender > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Thursday, April 24, 2003 9:50 AM > To: 'George Newsome'; Brungard, Deborah A, ALABS > Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; > Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); > zinin@psg.com > Subject: RE: Proposed response to the Liaison Statement on LMP Link > Verifi cation > > > George, > > The LMP test procedure is used to exchange GMPLS control plane identifiers > in support of > subsequent RSVP-TE signalling and it will be needed in networks that don't > support G.7714.1, > such as legacy SDH/SONET networks. I.e., I don't think one can stipulate > that deployment > of GMPLS is gated by the deployment of G.7714.1. > > It should also be noted that if the trace correlation transport > mechanism is > used in a > network in which G.7714.1 is deployed, then G.7714.1 will be supported > transparently; i.e., > the G.7714.1 bit pattern will be used as the correlating bit pattern. > > Thanks, > > John > > > -----Original Message----- > > From: George Newsome [mailto:gnewsome@ieee.org] > > Sent: Wednesday, April 23, 2003 9:24 AM > > To: Brungard, Deborah A, ALABS > > Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; > > Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); > > ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); > > zinin@psg.com > > Subject: Re: Proposed response to the Liaison Statement on LMP Link > > Verification > > > > > > Deborah, > > > > I've snipped the earlier stuff to reduce the length of this thread. > > > > Brungard, Deborah A, ALABS wrote: > > > > > I support the liaison response as proposed by Jonathan. It may be > > > helpful to add further clarification on the lmp-test format choice. > > > - suggest instead of saying "not restricted to printable characters" > > > which implies a choice of character/format, say "LMP needs > > to support > > > use of various types of control plane identifiers and control plane > > > information, this information is not restricted to the use > > of printable > > > characters. In addition, the LMP message structures can not > > be supported > > > > > > Had you forgotten that G.7714.1 also supports various > > identifiers, and > > those identifiers are also not restricted to the printable set. Its > > coding that creates the printable set. LMP messages can also > > be passed > > as printable chars after coding. > > > > It would help if you were clear about which messages and why. What I > > read is just another statement that says that LMP is different. > > > > > > > by the G7714.1 format". And on the use of a format distinguishing > > > character, "LMP uses a prior negotiation before use, the > > in-band is not > > > used in parallel with other Jx applications. The > > correlation procedure > > > will be used." > > > > > > > This is not a reason that LMP must be different - just a > > statement that > > it is. > > > > > > > There seems to be three discussion threads (all related to > > lmp-test): > > > - confusion on lmp-test and G7714.1 as providing procedures for the > > > "same purpose" > > > > > > Its really hard for me to see how the purpose of the inband > > message is > > different, even if the whole application is subtly different. > > > > > > > We discussed this both in T1X1 and ITU-T Q14. Both the T1X1 liaison > > > and the ITU-T Q14 liaison clearly identify the two procedures as > > > different applications. And the ITU-T Q14 liaison states > > "The control > > > plane protocol specific format is outside of the scope of > > G.7714.1. We > > > invite IETF to propose the message format suitable to exchange these > > > information elements." I don't view this thread of discussion as > > > > > > You will recall that this was NOT about the Jx inband messages, but > > about the out of band exchanges that take place after the inband > > exchanges. This has nothing to do with our current discussion > > about the > > Jx bytes and the use of a single format for those few messages. > > > > > > > impacting the liaison. Suggest continuing this discussion > > on transport > > > plane discovery vs. control plane discovery on the ITU exploders as > > > Q12/Q14 have already identified a related work item. > > > - confusion on why the G7714.1 format can not be used for lmp-test > > > > > > > > > See my above suggestion. And note, many of today's management > > > interfaces (Corba) are not constrained by TL1/printability. > > Performance, > > > etc need to be considered. > > > > > > It is very unfortuanate that you didn't bring this up at the > > proper time > > in Q14. The fact is that all the information needed is able > > to be passed > > in the printable set, and you agreed to it together with the > > rest of us. > > > > > > > - equipment functionality/configurations/impact on legacy > > > Again, this was identified in the T1X1 liaison. It doesn't impact > > > lmp-test (if we model the scope of lmp-test as similar to > > G7714.1, which > > > also does not address these topics). Suggest moving this > > discussion to > > > the ITU exploders (discussion on G7714.1 equipment impacts > > just kicked > > > off this morning). > > > > > > And I could not resist some comments (refer to db below), though I > > > will move on to the ITU exploder to continue ;-) > > > > > > Regards > > > > George > > > > > > > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Apr 2003 15:29:40 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97249E@nimbus> From: John Drake To: "'Razdan, Rajender'" , 'George Newsome' , "Brungard, Deborah A, ALABS" Cc: Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Thu, 24 Apr 2003 08:27:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30A76.14750D60" 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_01C30A76.14750D60 Content-Type: text/plain; charset="iso-8859-1" Raj, I don't think I was suggesting what you thought I was suggesting. My point was simply that when using the trace correlation transport mechanism, the Jx bytes are opaque from a GMPLS perspective. Wrt your original question, does G.7714.1 carry the LMP Test procedure Verify ID? Thanks, John -----Original Message----- From: Razdan, Rajender [mailto:RRazdan@ciena.com] Sent: Thursday, April 24, 2003 7:44 AM To: John Drake; 'George Newsome'; Brungard, Deborah A, ALABS Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation John, I don't think anyone out here is stipulating that deployment of GMPLS is gated by the deployment of G.7714.1. Your suggestion below amounts to saying that we will use the LMP discovery trace byte pattern for discovery purposes in GMPLS and change to G.7714.1 pattern when dealing with systems where G.7714.1 is deployed. But that is precisely what I'm arguing against the need for doing. As I said in one of my earlier emails, it would seem common-sense to avoid having to support two different message formats, especially if it can be avoided. So let me re-paraphrase my original question, which I have yet to see anyone answer: Is there anything about the G.7714.1 discovery trace message that makes it unsuitable for your discovery protocol within LMP? If not, I don't see what problem there is in changing the LMP trace message format to match that of G.7714.1. It seems to me that an earnest attempt to match these formats has already been undertaken in the LMP bootstrap draft document. So what then is the problem with doing the same for the LMP trace draft document? Rajender -----Original Message----- From: John Drake [ mailto:jdrake@calient.net ] Sent: Thursday, April 24, 2003 9:50 AM To: 'George Newsome'; Brungard, Deborah A, ALABS Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation George, The LMP test procedure is used to exchange GMPLS control plane identifiers in support of subsequent RSVP-TE signalling and it will be needed in networks that don't support G.7714.1, such as legacy SDH/SONET networks. I.e., I don't think one can stipulate that deployment of GMPLS is gated by the deployment of G.7714.1. It should also be noted that if the trace correlation transport mechanism is used in a network in which G.7714.1 is deployed, then G.7714.1 will be supported transparently; i.e., the G.7714.1 bit pattern will be used as the correlating bit pattern. Thanks, John > -----Original Message----- > From: George Newsome [ mailto:gnewsome@ieee.org ] > Sent: Wednesday, April 23, 2003 9:24 AM > To: Brungard, Deborah A, ALABS > Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; > Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); > zinin@psg.com > Subject: Re: Proposed response to the Liaison Statement on LMP Link > Verification > > > Deborah, > > I've snipped the earlier stuff to reduce the length of this thread. > > Brungard, Deborah A, ALABS wrote: > > > I support the liaison response as proposed by Jonathan. It may be > > helpful to add further clarification on the lmp-test format choice. > > - suggest instead of saying "not restricted to printable characters" > > which implies a choice of character/format, say "LMP needs > to support > > use of various types of control plane identifiers and control plane > > information, this information is not restricted to the use > of printable > > characters. In addition, the LMP message structures can not > be supported > > > Had you forgotten that G.7714.1 also supports various > identifiers, and > those identifiers are also not restricted to the printable set. Its > coding that creates the printable set. LMP messages can also > be passed > as printable chars after coding. > > It would help if you were clear about which messages and why. What I > read is just another statement that says that LMP is different. > > > > by the G7714.1 format". And on the use of a format distinguishing > > character, "LMP uses a prior negotiation before use, the > in-band is not > > used in parallel with other Jx applications. The > correlation procedure > > will be used." > > > > This is not a reason that LMP must be different - just a > statement that > it is. > > > > There seems to be three discussion threads (all related to > lmp-test): > > - confusion on lmp-test and G7714.1 as providing procedures for the > > "same purpose" > > > Its really hard for me to see how the purpose of the inband > message is > different, even if the whole application is subtly different. > > > > We discussed this both in T1X1 and ITU-T Q14. Both the T1X1 liaison > > and the ITU-T Q14 liaison clearly identify the two procedures as > > different applications. And the ITU-T Q14 liaison states > "The control > > plane protocol specific format is outside of the scope of > G.7714.1. We > > invite IETF to propose the message format suitable to exchange these > > information elements." I don't view this thread of discussion as > > > You will recall that this was NOT about the Jx inband messages, but > about the out of band exchanges that take place after the inband > exchanges. This has nothing to do with our current discussion > about the > Jx bytes and the use of a single format for those few messages. > > > > impacting the liaison. Suggest continuing this discussion > on transport > > plane discovery vs. control plane discovery on the ITU exploders as > > Q12/Q14 have already identified a related work item. > > - confusion on why the G7714.1 format can not be used for lmp-test > > > > > See my above suggestion. And note, many of today's management > > interfaces (Corba) are not constrained by TL1/printability. > Performance, > > etc need to be considered. > > > It is very unfortuanate that you didn't bring this up at the > proper time > in Q14. The fact is that all the information needed is able > to be passed > in the printable set, and you agreed to it together with the > rest of us. > > > > - equipment functionality/configurations/impact on legacy > > Again, this was identified in the T1X1 liaison. It doesn't impact > > lmp-test (if we model the scope of lmp-test as similar to > G7714.1, which > > also does not address these topics). Suggest moving this > discussion to > > the ITU exploders (discussion on G7714.1 equipment impacts > just kicked > > off this morning). > > > > And I could not resist some comments (refer to db below), though I > > will move on to the ITU exploder to continue ;-) > > > Regards > > George > > > > ------_=_NextPart_001_01C30A76.14750D60 Content-Type: text/html; charset="iso-8859-1" RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Raj,
 
I don't think I was suggesting what you thought I was suggesting.  My point was simply
that when using  the trace correlation transport mechanism, the Jx bytes are opaque
from a GMPLS perspective.
 
Wrt your original question, does G.7714.1 carry the LMP Test procedure Verify ID?
 
Thanks,
 
John
-----Original Message-----
From: Razdan, Rajender [mailto:RRazdan@ciena.com]
Sent: Thursday, April 24, 2003 7:44 AM
To: John Drake; 'George Newsome'; Brungard, Deborah A, ALABS
Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); zinin@psg.com
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation

John,

   I don't think anyone out here is stipulating that deployment of
GMPLS is gated by the deployment of G.7714.1. Your suggestion below
amounts to saying that we will use the LMP discovery trace byte
pattern for discovery purposes in GMPLS and change to G.7714.1
pattern when dealing with systems where G.7714.1 is deployed. But
that is precisely what I'm arguing against the need for doing. As
I said in one of my earlier emails, it would seem common-sense to
avoid having to support two different message formats, especially
if it can be avoided.

  So let me re-paraphrase my original question, which I have yet to
see anyone answer: Is there anything about the G.7714.1 discovery
trace message that makes it unsuitable for your discovery protocol
within LMP? If not, I don't see what problem there is in changing
the LMP trace message format to match that of G.7714.1. It seems
to me that an earnest attempt to match these formats has already
been undertaken in the LMP bootstrap draft document. So what then
is the problem with doing the same for the LMP trace draft document?

Rajender

-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Thursday, April 24, 2003 9:50 AM
To: 'George Newsome'; Brungard, Deborah A, ALABS
Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com;
Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert);
ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail);
zinin@psg.com
Subject: RE: Proposed response to the Liaison Statement on LMP Link
Verifi cation


George,

The LMP test procedure is used to exchange GMPLS control plane identifiers
in support of
subsequent RSVP-TE signalling and it will be needed in networks that don't
support G.7714.1,
such as legacy SDH/SONET networks.  I.e., I don't think one can stipulate
that deployment
of GMPLS is gated by the deployment of G.7714.1.

It should also be noted that if the trace correlation transport mechanism is
used in a
network in which G.7714.1 is deployed, then G.7714.1 will be supported
transparently;  i.e.,
the G.7714.1 bit pattern will be used as the correlating bit pattern.

Thanks,

John

> -----Original Message-----
> From: George Newsome [mailto:gnewsome@ieee.org]
> Sent: Wednesday, April 23, 2003 9:24 AM
> To: Brungard, Deborah A, ALABS
> Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com;
> Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert);
> ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail);
> zinin@psg.com
> Subject: Re: Proposed response to the Liaison Statement on LMP Link
> Verification
>
>
> Deborah,
>
> I've snipped the earlier stuff to reduce the length of this thread.
>
> Brungard, Deborah A, ALABS wrote:
>
> > I support the liaison response as proposed by Jonathan. It may be
> > helpful to add further clarification on the lmp-test format choice.
> > - suggest instead of saying "not restricted to printable characters"
> > which implies a choice of character/format, say "LMP needs
> to support
> > use of various types of control plane identifiers and control plane
> > information, this information is not restricted to the use
> of printable
> > characters. In addition, the LMP message structures can not
> be supported
>
>
> Had you forgotten that G.7714.1 also supports various
> identifiers, and
> those identifiers are also not restricted to the printable set. Its
> coding that creates the printable set. LMP messages can also
> be passed
> as printable chars after coding.
>
> It would help if you were clear about which messages and why. What I
> read is just another statement that says that LMP is different.
>
>
> > by the G7714.1 format". And on the use of a format distinguishing
> > character, "LMP uses a prior negotiation before use, the
> in-band is not
> > used in parallel with other Jx applications. The
> correlation procedure
> > will be used."
> >
>
> This is not a reason that LMP must be different - just a
> statement that
> it is.
>
>
> > There seems to be three discussion threads (all related to
> lmp-test):
> > - confusion on lmp-test and G7714.1 as providing procedures for the
> > "same purpose"
>
>
> Its really hard for me to see how the purpose of the inband
> message is
> different, even if the whole application is subtly different.
>
>
> > We discussed this both in T1X1 and ITU-T Q14. Both the T1X1 liaison
> > and the ITU-T Q14 liaison clearly identify the two procedures as
> > different applications. And the ITU-T Q14 liaison states
> "The control
> > plane protocol specific format is outside of the scope of
> G.7714.1. We
> > invite IETF to propose the message format suitable to exchange these
> > information elements." I don't view this thread of discussion as
>
>
> You will recall that this was NOT about the Jx inband messages, but
> about the out of band exchanges that take place after the inband
> exchanges. This has nothing to do with our current discussion
> about the
> Jx bytes and the use of a single format for those few messages.
>
>
> > impacting the liaison. Suggest continuing this discussion
> on transport
> > plane discovery vs. control plane discovery on the ITU exploders as
> > Q12/Q14 have already identified a related work item.
> > - confusion on why the G7714.1 format can not be used for lmp-test
>
>
>
> > See my above suggestion. And note, many of today's management
> > interfaces (Corba) are not constrained by TL1/printability.
> Performance,
> > etc need to be considered.
>
>
> It is very unfortuanate that you didn't bring this up at the
> proper time
> in Q14. The fact is that all the information needed is able
> to be passed
> in the printable set, and you agreed to it together with the
> rest of us.
>
>
> > - equipment functionality/configurations/impact on legacy
> > Again, this was identified in the T1X1 liaison. It doesn't impact
> > lmp-test (if we model the scope of lmp-test as similar to
> G7714.1, which
> > also does not address these topics). Suggest moving this
> discussion to
> > the ITU exploders (discussion on G7714.1 equipment impacts
> just kicked
> > off this morning).
> >
> > And I could not resist some comments (refer to db below), though I
> > will move on to the ITU exploder to continue ;-)
>
>
> Regards
>
>       George
>
>
>
>

------_=_NextPart_001_01C30A76.14750D60-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Apr 2003 14:44:54 +0000 Message-ID: <9A1A304A69213E4E9CC08614134C7F7C5357F0@w2k04exg02.ciena.com> From: "Razdan, Rajender" To: 'John Drake' , 'George Newsome' , "Brungard, Deborah A, ALABS" Cc: Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Thu, 24 Apr 2003 10:43:49 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30A6F.EAA86D20" 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_01C30A6F.EAA86D20 Content-Type: text/plain; charset="iso-8859-1" John, I don't think anyone out here is stipulating that deployment of GMPLS is gated by the deployment of G.7714.1. Your suggestion below amounts to saying that we will use the LMP discovery trace byte pattern for discovery purposes in GMPLS and change to G.7714.1 pattern when dealing with systems where G.7714.1 is deployed. But that is precisely what I'm arguing against the need for doing. As I said in one of my earlier emails, it would seem common-sense to avoid having to support two different message formats, especially if it can be avoided. So let me re-paraphrase my original question, which I have yet to see anyone answer: Is there anything about the G.7714.1 discovery trace message that makes it unsuitable for your discovery protocol within LMP? If not, I don't see what problem there is in changing the LMP trace message format to match that of G.7714.1. It seems to me that an earnest attempt to match these formats has already been undertaken in the LMP bootstrap draft document. So what then is the problem with doing the same for the LMP trace draft document? Rajender -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Thursday, April 24, 2003 9:50 AM To: 'George Newsome'; Brungard, Deborah A, ALABS Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation George, The LMP test procedure is used to exchange GMPLS control plane identifiers in support of subsequent RSVP-TE signalling and it will be needed in networks that don't support G.7714.1, such as legacy SDH/SONET networks. I.e., I don't think one can stipulate that deployment of GMPLS is gated by the deployment of G.7714.1. It should also be noted that if the trace correlation transport mechanism is used in a network in which G.7714.1 is deployed, then G.7714.1 will be supported transparently; i.e., the G.7714.1 bit pattern will be used as the correlating bit pattern. Thanks, John > -----Original Message----- > From: George Newsome [mailto:gnewsome@ieee.org] > Sent: Wednesday, April 23, 2003 9:24 AM > To: Brungard, Deborah A, ALABS > Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; > Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); > zinin@psg.com > Subject: Re: Proposed response to the Liaison Statement on LMP Link > Verification > > > Deborah, > > I've snipped the earlier stuff to reduce the length of this thread. > > Brungard, Deborah A, ALABS wrote: > > > I support the liaison response as proposed by Jonathan. It may be > > helpful to add further clarification on the lmp-test format choice. > > - suggest instead of saying "not restricted to printable characters" > > which implies a choice of character/format, say "LMP needs > to support > > use of various types of control plane identifiers and control plane > > information, this information is not restricted to the use > of printable > > characters. In addition, the LMP message structures can not > be supported > > > Had you forgotten that G.7714.1 also supports various > identifiers, and > those identifiers are also not restricted to the printable set. Its > coding that creates the printable set. LMP messages can also > be passed > as printable chars after coding. > > It would help if you were clear about which messages and why. What I > read is just another statement that says that LMP is different. > > > > by the G7714.1 format". And on the use of a format distinguishing > > character, "LMP uses a prior negotiation before use, the > in-band is not > > used in parallel with other Jx applications. The > correlation procedure > > will be used." > > > > This is not a reason that LMP must be different - just a > statement that > it is. > > > > There seems to be three discussion threads (all related to > lmp-test): > > - confusion on lmp-test and G7714.1 as providing procedures for the > > "same purpose" > > > Its really hard for me to see how the purpose of the inband > message is > different, even if the whole application is subtly different. > > > > We discussed this both in T1X1 and ITU-T Q14. Both the T1X1 liaison > > and the ITU-T Q14 liaison clearly identify the two procedures as > > different applications. And the ITU-T Q14 liaison states > "The control > > plane protocol specific format is outside of the scope of > G.7714.1. We > > invite IETF to propose the message format suitable to exchange these > > information elements." I don't view this thread of discussion as > > > You will recall that this was NOT about the Jx inband messages, but > about the out of band exchanges that take place after the inband > exchanges. This has nothing to do with our current discussion > about the > Jx bytes and the use of a single format for those few messages. > > > > impacting the liaison. Suggest continuing this discussion > on transport > > plane discovery vs. control plane discovery on the ITU exploders as > > Q12/Q14 have already identified a related work item. > > - confusion on why the G7714.1 format can not be used for lmp-test > > > > > See my above suggestion. And note, many of today's management > > interfaces (Corba) are not constrained by TL1/printability. > Performance, > > etc need to be considered. > > > It is very unfortuanate that you didn't bring this up at the > proper time > in Q14. The fact is that all the information needed is able > to be passed > in the printable set, and you agreed to it together with the > rest of us. > > > > - equipment functionality/configurations/impact on legacy > > Again, this was identified in the T1X1 liaison. It doesn't impact > > lmp-test (if we model the scope of lmp-test as similar to > G7714.1, which > > also does not address these topics). Suggest moving this > discussion to > > the ITU exploders (discussion on G7714.1 equipment impacts > just kicked > > off this morning). > > > > And I could not resist some comments (refer to db below), though I > > will move on to the ITU exploder to continue ;-) > > > Regards > > George > > > > ------_=_NextPart_001_01C30A6F.EAA86D20 Content-Type: text/html; charset="iso-8859-1" RE: Proposed response to the Liaison Statement on LMP Link Verifi cation

John,

   I don't think anyone out here is stipulating that deployment of
GMPLS is gated by the deployment of G.7714.1. Your suggestion below
amounts to saying that we will use the LMP discovery trace byte
pattern for discovery purposes in GMPLS and change to G.7714.1
pattern when dealing with systems where G.7714.1 is deployed. But
that is precisely what I'm arguing against the need for doing. As
I said in one of my earlier emails, it would seem common-sense to
avoid having to support two different message formats, especially
if it can be avoided.

  So let me re-paraphrase my original question, which I have yet to
see anyone answer: Is there anything about the G.7714.1 discovery
trace message that makes it unsuitable for your discovery protocol
within LMP? If not, I don't see what problem there is in changing
the LMP trace message format to match that of G.7714.1. It seems
to me that an earnest attempt to match these formats has already
been undertaken in the LMP bootstrap draft document. So what then
is the problem with doing the same for the LMP trace draft document?

Rajender

-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Thursday, April 24, 2003 9:50 AM
To: 'George Newsome'; Brungard, Deborah A, ALABS
Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com;
Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert);
ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail);
zinin@psg.com
Subject: RE: Proposed response to the Liaison Statement on LMP Link
Verifi cation


George,

The LMP test procedure is used to exchange GMPLS control plane identifiers
in support of
subsequent RSVP-TE signalling and it will be needed in networks that don't
support G.7714.1,
such as legacy SDH/SONET networks.  I.e., I don't think one can stipulate
that deployment
of GMPLS is gated by the deployment of G.7714.1.

It should also be noted that if the trace correlation transport mechanism is
used in a
network in which G.7714.1 is deployed, then G.7714.1 will be supported
transparently;  i.e.,
the G.7714.1 bit pattern will be used as the correlating bit pattern.

Thanks,

John

> -----Original Message-----
> From: George Newsome [mailto:gnewsome@ieee.org]
> Sent: Wednesday, April 23, 2003 9:24 AM
> To: Brungard, Deborah A, ALABS
> Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com;
> Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert);
> ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail);
> zinin@psg.com
> Subject: Re: Proposed response to the Liaison Statement on LMP Link
> Verification
>
>
> Deborah,
>
> I've snipped the earlier stuff to reduce the length of this thread.
>
> Brungard, Deborah A, ALABS wrote:
>
> > I support the liaison response as proposed by Jonathan. It may be
> > helpful to add further clarification on the lmp-test format choice.
> > - suggest instead of saying "not restricted to printable characters"
> > which implies a choice of character/format, say "LMP needs
> to support
> > use of various types of control plane identifiers and control plane
> > information, this information is not restricted to the use
> of printable
> > characters. In addition, the LMP message structures can not
> be supported
>
>
> Had you forgotten that G.7714.1 also supports various
> identifiers, and
> those identifiers are also not restricted to the printable set. Its
> coding that creates the printable set. LMP messages can also
> be passed
> as printable chars after coding.
>
> It would help if you were clear about which messages and why. What I
> read is just another statement that says that LMP is different.
>
>
> > by the G7714.1 format". And on the use of a format distinguishing
> > character, "LMP uses a prior negotiation before use, the
> in-band is not
> > used in parallel with other Jx applications. The
> correlation procedure
> > will be used."
> >
>
> This is not a reason that LMP must be different - just a
> statement that
> it is.
>
>
> > There seems to be three discussion threads (all related to
> lmp-test):
> > - confusion on lmp-test and G7714.1 as providing procedures for the
> > "same purpose"
>
>
> Its really hard for me to see how the purpose of the inband
> message is
> different, even if the whole application is subtly different.
>
>
> > We discussed this both in T1X1 and ITU-T Q14. Both the T1X1 liaison
> > and the ITU-T Q14 liaison clearly identify the two procedures as
> > different applications. And the ITU-T Q14 liaison states
> "The control
> > plane protocol specific format is outside of the scope of
> G.7714.1. We
> > invite IETF to propose the message format suitable to exchange these
> > information elements." I don't view this thread of discussion as
>
>
> You will recall that this was NOT about the Jx inband messages, but
> about the out of band exchanges that take place after the inband
> exchanges. This has nothing to do with our current discussion
> about the
> Jx bytes and the use of a single format for those few messages.
>
>
> > impacting the liaison. Suggest continuing this discussion
> on transport
> > plane discovery vs. control plane discovery on the ITU exploders as
> > Q12/Q14 have already identified a related work item.
> > - confusion on why the G7714.1 format can not be used for lmp-test
>
>
>
> > See my above suggestion. And note, many of today's management
> > interfaces (Corba) are not constrained by TL1/printability.
> Performance,
> > etc need to be considered.
>
>
> It is very unfortuanate that you didn't bring this up at the
> proper time
> in Q14. The fact is that all the information needed is able
> to be passed
> in the printable set, and you agreed to it together with the
> rest of us.
>
>
> > - equipment functionality/configurations/impact on legacy
> > Again, this was identified in the T1X1 liaison. It doesn't impact
> > lmp-test (if we model the scope of lmp-test as similar to
> G7714.1, which
> > also does not address these topics). Suggest moving this
> discussion to
> > the ITU exploders (discussion on G7714.1 equipment impacts
> just kicked
> > off this morning).
> >
> > And I could not resist some comments (refer to db below), though I
> > will move on to the ITU exploder to continue ;-)
>
>
> Regards
>
>       George
>
>
>
>

------_=_NextPart_001_01C30A6F.EAA86D20-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Apr 2003 13:53:02 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972498@nimbus> From: John Drake To: 'George Newsome' , "Brungard, Deborah A, ALABS" Cc: Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Thu, 24 Apr 2003 06:49:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" George, The LMP test procedure is used to exchange GMPLS control plane identifiers in support of subsequent RSVP-TE signalling and it will be needed in networks that don't support G.7714.1, such as legacy SDH/SONET networks. I.e., I don't think one can stipulate that deployment of GMPLS is gated by the deployment of G.7714.1. It should also be noted that if the trace correlation transport mechanism is used in a network in which G.7714.1 is deployed, then G.7714.1 will be supported transparently; i.e., the G.7714.1 bit pattern will be used as the correlating bit pattern. Thanks, John > -----Original Message----- > From: George Newsome [mailto:gnewsome@ieee.org] > Sent: Wednesday, April 23, 2003 9:24 AM > To: Brungard, Deborah A, ALABS > Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; > Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert); > ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail); > zinin@psg.com > Subject: Re: Proposed response to the Liaison Statement on LMP Link > Verification > > > Deborah, > > I've snipped the earlier stuff to reduce the length of this thread. > > Brungard, Deborah A, ALABS wrote: > > > I support the liaison response as proposed by Jonathan. It may be > > helpful to add further clarification on the lmp-test format choice. > > - suggest instead of saying "not restricted to printable characters" > > which implies a choice of character/format, say "LMP needs > to support > > use of various types of control plane identifiers and control plane > > information, this information is not restricted to the use > of printable > > characters. In addition, the LMP message structures can not > be supported > > > Had you forgotten that G.7714.1 also supports various > identifiers, and > those identifiers are also not restricted to the printable set. Its > coding that creates the printable set. LMP messages can also > be passed > as printable chars after coding. > > It would help if you were clear about which messages and why. What I > read is just another statement that says that LMP is different. > > > > by the G7714.1 format". And on the use of a format distinguishing > > character, "LMP uses a prior negotiation before use, the > in-band is not > > used in parallel with other Jx applications. The > correlation procedure > > will be used." > > > > This is not a reason that LMP must be different - just a > statement that > it is. > > > > There seems to be three discussion threads (all related to > lmp-test): > > - confusion on lmp-test and G7714.1 as providing procedures for the > > "same purpose" > > > Its really hard for me to see how the purpose of the inband > message is > different, even if the whole application is subtly different. > > > > We discussed this both in T1X1 and ITU-T Q14. Both the T1X1 liaison > > and the ITU-T Q14 liaison clearly identify the two procedures as > > different applications. And the ITU-T Q14 liaison states > "The control > > plane protocol specific format is outside of the scope of > G.7714.1. We > > invite IETF to propose the message format suitable to exchange these > > information elements." I don't view this thread of discussion as > > > You will recall that this was NOT about the Jx inband messages, but > about the out of band exchanges that take place after the inband > exchanges. This has nothing to do with our current discussion > about the > Jx bytes and the use of a single format for those few messages. > > > > impacting the liaison. Suggest continuing this discussion > on transport > > plane discovery vs. control plane discovery on the ITU exploders as > > Q12/Q14 have already identified a related work item. > > - confusion on why the G7714.1 format can not be used for lmp-test > > > > > See my above suggestion. And note, many of today's management > > interfaces (Corba) are not constrained by TL1/printability. > Performance, > > etc need to be considered. > > > It is very unfortuanate that you didn't bring this up at the > proper time > in Q14. The fact is that all the information needed is able > to be passed > in the printable set, and you agreed to it together with the > rest of us. > > > > - equipment functionality/configurations/impact on legacy > > Again, this was identified in the T1X1 liaison. It doesn't impact > > lmp-test (if we model the scope of lmp-test as similar to > G7714.1, which > > also does not address these topics). Suggest moving this > discussion to > > the ITU exploders (discussion on G7714.1 equipment impacts > just kicked > > off this morning). > > > > And I could not resist some comments (refer to db below), though I > > will move on to the ITU exploder to continue ;-) > > > Regards > > George > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Apr 2003 16:27:58 +0000 Message-ID: <3EA6BE17.80305@ieee.org> Date: Wed, 23 Apr 2003 12:23:51 -0400 From: George Newsome 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: "Brungard, Deborah A, ALABS" CC: Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verification Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Deborah, I've snipped the earlier stuff to reduce the length of this thread. Brungard, Deborah A, ALABS wrote: > I support the liaison response as proposed by Jonathan. It may be > helpful to add further clarification on the lmp-test format choice. > - suggest instead of saying "not restricted to printable characters" > which implies a choice of character/format, say "LMP needs to support > use of various types of control plane identifiers and control plane > information, this information is not restricted to the use of printable > characters. In addition, the LMP message structures can not be supported Had you forgotten that G.7714.1 also supports various identifiers, and those identifiers are also not restricted to the printable set. Its coding that creates the printable set. LMP messages can also be passed as printable chars after coding. It would help if you were clear about which messages and why. What I read is just another statement that says that LMP is different. > by the G7714.1 format". And on the use of a format distinguishing > character, "LMP uses a prior negotiation before use, the in-band is not > used in parallel with other Jx applications. The correlation procedure > will be used." > This is not a reason that LMP must be different - just a statement that it is. > There seems to be three discussion threads (all related to lmp-test): > - confusion on lmp-test and G7714.1 as providing procedures for the > "same purpose" Its really hard for me to see how the purpose of the inband message is different, even if the whole application is subtly different. > We discussed this both in T1X1 and ITU-T Q14. Both the T1X1 liaison > and the ITU-T Q14 liaison clearly identify the two procedures as > different applications. And the ITU-T Q14 liaison states "The control > plane protocol specific format is outside of the scope of G.7714.1. We > invite IETF to propose the message format suitable to exchange these > information elements." I don't view this thread of discussion as You will recall that this was NOT about the Jx inband messages, but about the out of band exchanges that take place after the inband exchanges. This has nothing to do with our current discussion about the Jx bytes and the use of a single format for those few messages. > impacting the liaison. Suggest continuing this discussion on transport > plane discovery vs. control plane discovery on the ITU exploders as > Q12/Q14 have already identified a related work item. > - confusion on why the G7714.1 format can not be used for lmp-test > See my above suggestion. And note, many of today's management > interfaces (Corba) are not constrained by TL1/printability. Performance, > etc need to be considered. It is very unfortuanate that you didn't bring this up at the proper time in Q14. The fact is that all the information needed is able to be passed in the printable set, and you agreed to it together with the rest of us. > - equipment functionality/configurations/impact on legacy > Again, this was identified in the T1X1 liaison. It doesn't impact > lmp-test (if we model the scope of lmp-test as similar to G7714.1, which > also does not address these topics). Suggest moving this discussion to > the ITU exploders (discussion on G7714.1 equipment impacts just kicked > off this morning). > > And I could not resist some comments (refer to db below), though I > will move on to the ITU exploder to continue ;-) Regards George Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Apr 2003 16:04:59 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972486@nimbus> From: John Drake To: 'Dieter Beller' Cc: "'Brungard, Deborah A, ALABS'" , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, George Newsome , Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Wed, 23 Apr 2003 09:04:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" snipped ... > > JD: I just wanted to second Deborah's comment. The LMP > test procedure > > is used to exchange GMPLS control plane identifiers for the > purpose of > > LSP signalling. If the trace correlation transport > mechanism is used, > > the existing SDH/SONET transport plane Jx bit pattern is > transported in > > the LMP Test procedure messages, i.e., in the GMPLS control > plane. This > > allows two nodes, node 1 and node 2, to build the following > association: > > > > {Node 1's GMPLS ID and Jx bit pattern for link x, Node 2's > GMPLS ID and > > and Jx bit pattern for link x} > > > > When you are saying that LMP is used to set up the proper TTI > (Jx pattern) between each pair of neighboring nodes along a path > during the LSP/connectionestablishement process (in your words: > LSP signalling), this should in my opinion be done via signaling > (e.g. RSVP) JD: No, that's not what I'm saying. The Jx patterns are there on a given link between a pair of GMPLS nodes. Those nodes exchange the Jx patterns using the LMP Test procedures in order to understand each other's GMPLS IDs for that link as part of that link's GMPLS initialization. These IDs are then used during RSVP processing to establish the control and data planes for a given LSP. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Apr 2003 15:44:53 +0000 Message-ID: <3EA6B484.7070407@alcatel.de> Date: Wed, 23 Apr 2003 17:43:00 +0200 From: Dieter Beller Organization: Alcatel SEL AG, OND Stuttgart, Germany User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) Gecko/20030401 MIME-Version: 1.0 To: John Drake CC: "'Brungard, Deborah A, ALABS'" , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com, George Newsome , Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please find my comment in-line. Dieter John Drake wrote: > Snipped ... > > >>- To what extent do we wish to deploy this kind of technology over >> existing SONET/SDH networks? I think that many operators >>are interested >> in deploying ASON/GMPLS technology over a portion of the capacity of >> their existing transport networks. As a result, it is useful to look >> at what is required for "peaceful coexistance" of this >>technology with >> other traffic. This is what has motivated in G.7714.1 to use the >> "distinguishing character" so that various termination and >>NIM functions >> can tell the difference between a message used for >>discovery/connectivity >> verification and a normal trace identifier. I am not convinced by >> arguments such as "you will never see these in the same network" or >> "the specific scenario is such that the wrong TT function or NIM >> function will never see this message". You can never quite tell how >> someone will connect things or use a particular feature, >>and it seems >> like a far more robust approach to choose a format where it >>is always >> possible to distinguish between the various possible uses >>of the same >> bytes. >> >>db: Note, to clarify, G7714.1 requires all new G7714.1-aware >>transport equipment, both terminations and intermediate >>equipment. And for operators, "turning-off" of legacy >>intermediate NIMs is not an option (proposed in G7714.1), as >>the investment in intermediate NIMs is not for 24/7 >>entertainment of our field staff. G7714.1 does not >>"peacefully coexist". One ITU operator suggested using a >>different byte than Jx based on this concern with G7714.1. >>Whereas, LMP requires GMPLS-aware transport equipment. And >>LMP provides two options depending on support by legacy >>equipment (in-band, correlation). For either G7714.1 or GMPLS >>LMP, an operator chooses equipment configurations/options >>based on their application. New applications/new equipment >>(no free lunch;-)). No different from today's operations. And >>the two options (in-band, correlated) provided by LMP support >>two different use scenarios, including use of legacy NIMs. As >>discussed for G7714.1, Q9 needs to evaluate the equipment >>support scenarios. >>---end of comment--- >> > > > > JD: I just wanted to second Deborah's comment. The LMP test procedure > is used to exchange GMPLS control plane identifiers for the purpose of > LSP signalling. If the trace correlation transport mechanism is used, > the existing SDH/SONET transport plane Jx bit pattern is transported in > the LMP Test procedure messages, i.e., in the GMPLS control plane. This > allows two nodes, node 1 and node 2, to build the following association: > > {Node 1's GMPLS ID and Jx bit pattern for link x, Node 2's GMPLS ID and > and Jx bit pattern for link x} > When you are saying that LMP is used to set up the proper TTI (Jx pattern) between each pair of neighboring nodes along a path during the LSP/connectionestablishement process (in your words: LSP signalling), this should in my opinion be done via signaling (e.g. RSVP) > This means that it is 100% compatible with existing SDH/SONET equipment, > which is not a claim that G.7714.1 can make. Note also that this is clearly > spelled out in the draft and has been mentioned in e-mail several times. > May I kindly remind you that G.7714.1's scope is layer adjacency discovery. Setting up the TTI along a path is outside the scope of G.7714.1. Discovery is used to determine the relationships of link end points (CP-to-CP relationships) between two adjacent nodes - depending on the chosen architecture it may also be possible to determine the related date-plane-to-control-plane relationships (if the Discovery Agent and the Connection Controler conincide on both sides of the link which is a special case - sorry for using the ASON terminology here) > Thanks, > > John Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Apr 2003 15:04:47 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972481@nimbus> From: John Drake To: "'Brungard, Deborah A, ALABS'" , Stephen Trowbridge , Jonathan.Lang@RinconNetworks.com Cc: George Newsome , Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" , zinin@psg.com Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation Date: Wed, 23 Apr 2003 08:03:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Snipped ... > - To what extent do we wish to deploy this kind of technology over > existing SONET/SDH networks? I think that many operators > are interested > in deploying ASON/GMPLS technology over a portion of the capacity of > their existing transport networks. As a result, it is useful to look > at what is required for "peaceful coexistance" of this > technology with > other traffic. This is what has motivated in G.7714.1 to use the > "distinguishing character" so that various termination and > NIM functions > can tell the difference between a message used for > discovery/connectivity > verification and a normal trace identifier. I am not convinced by > arguments such as "you will never see these in the same network" or > "the specific scenario is such that the wrong TT function or NIM > function will never see this message". You can never quite tell how > someone will connect things or use a particular feature, > and it seems > like a far more robust approach to choose a format where it > is always > possible to distinguish between the various possible uses > of the same > bytes. > > db: Note, to clarify, G7714.1 requires all new G7714.1-aware > transport equipment, both terminations and intermediate > equipment. And for operators, "turning-off" of legacy > intermediate NIMs is not an option (proposed in G7714.1), as > the investment in intermediate NIMs is not for 24/7 > entertainment of our field staff. G7714.1 does not > "peacefully coexist". One ITU operator suggested using a > different byte than Jx based on this concern with G7714.1. > Whereas, LMP requires GMPLS-aware transport equipment. And > LMP provides two options depending on support by legacy > equipment (in-band, correlation). For either G7714.1 or GMPLS > LMP, an operator chooses equipment configurations/options > based on their application. New applications/new equipment > (no free lunch;-)). No different from today's operations. And > the two options (in-band, correlated) provided by LMP support > two different use scenarios, including use of legacy NIMs. As > discussed for G7714.1, Q9 needs to evaluate the equipment > support scenarios. > ---end of comment--- > JD: I just wanted to second Deborah's comment. The LMP test procedure is used to exchange GMPLS control plane identifiers for the purpose of LSP signalling. If the trace correlation transport mechanism is used, the existing SDH/SONET transport plane Jx bit pattern is transported in the LMP Test procedure messages, i.e., in the GMPLS control plane. This allows two nodes, node 1 and node 2, to build the following association: {Node 1's GMPLS ID and Jx bit pattern for link x, Node 2's GMPLS ID and and Jx bit pattern for link x} This means that it is 100% compatible with existing SDH/SONET equipment, which is not a claim that G.7714.1 can make. Note also that this is clearly spelled out in the draft and has been mentioned in e-mail several times. Thanks, John Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Apr 2003 14:20:22 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed response to the Liaison Statement on LMP Link Verification Date: Wed, 23 Apr 2003 10:17:46 -0400 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC62406845B14@OCCLUST02EVS1.ugd.att.com> Thread-Topic: Proposed response to the Liaison Statement on LMP Link Verification Thread-Index: AcMI5iijVXB+xvH0SgCe39xibts0gQAFg7kw From: "Brungard, Deborah A, ALABS" To: "Stephen Trowbridge" , Cc: "George Newsome" , , "Wijnen, Bert (Bert)" , , , "Ron Bonica (E-mail)" , I support the liaison response as proposed by Jonathan. It may be = helpful to add further clarification on the lmp-test format choice. - suggest instead of saying "not restricted to printable characters" = which implies a choice of character/format, say "LMP needs to support = use of various types of control plane identifiers and control plane = information, this information is not restricted to the use of printable = characters. In addition, the LMP message structures can not be supported = by the G7714.1 format". And on the use of a format distinguishing = character, "LMP uses a prior negotiation before use, the in-band is not = used in parallel with other Jx applications. The correlation procedure = will be used." There seems to be three discussion threads (all related to lmp-test): - confusion on lmp-test and G7714.1 as providing procedures for the = "same purpose" We discussed this both in T1X1 and ITU-T Q14. Both the T1X1 liaison and = the ITU-T Q14 liaison clearly identify the two procedures as different = applications. And the ITU-T Q14 liaison states "The control plane = protocol specific format is outside of the scope of G.7714.1. We invite = IETF to propose the message format suitable to exchange these = information elements." I don't view this thread of discussion as = impacting the liaison. Suggest continuing this discussion on transport = plane discovery vs. control plane discovery on the ITU exploders as = Q12/Q14 have already identified a related work item. - confusion on why the G7714.1 format can not be used for lmp-test See my above suggestion. And note, many of today's management interfaces = (Corba) are not constrained by TL1/printability. Performance, etc need = to be considered. =20 - equipment functionality/configurations/impact on legacy Again, this was identified in the T1X1 liaison. It doesn't impact = lmp-test (if we model the scope of lmp-test as similar to G7714.1, which = also does not address these topics). Suggest moving this discussion to = the ITU exploders (discussion on G7714.1 equipment impacts just kicked = off this morning). And I could not resist some comments (refer to db below), though I will = move on to the ITU exploder to continue ;-) Deborah (t1x15 hatless) -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Tuesday, April 22, 2003 11:45 AM To: Jonathan.Lang@RinconNetworks.com Cc: 'George Newsome'; Dimitri.Papadimitriou@alcatel.be; 'Wijnen, Bert (Bert)'; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS; Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verification Jonathan, I think that the following are true: - Both the lmp-test draft and G.7714.1 perform connectivity discovery = and verification. - Both the lmp-test draft and G.7714.1 have chosen scenarios where they = will use the Jx bytes for this purpose, although they have chosen different points in the life cycle where Jx byte messaging is considered = appropriate. While the procedures seem to be executed at different points in time, = they seem to be for the same purpose over the same bytes, which would suggest that it is worthwhile looking for better alignment rather than having everybody go their own way. db: Not the same application. The words "Green Field" have been tossed about, and I think there are actually two questions here: - To what extent to we require new or redesigned equipment to implement this functionality? The installed base of SONET/SDH equipment is huge, and I think there is a great desire to deploy this kind of technology with the most minor possible tweaks to the existing transport = equipment. I think this desire is behind the suggestions to try to keep the Jx format as close as possible to the current formats used for TTIs = (e.g., printable characters) and the requests not to define multiple formats to be used for the same or similar purposes. db: refer to next item.=20 - To what extent do we wish to deploy this kind of technology over existing SONET/SDH networks? I think that many operators are = interested in deploying ASON/GMPLS technology over a portion of the capacity of their existing transport networks. As a result, it is useful to look at what is required for "peaceful coexistance" of this technology with other traffic. This is what has motivated in G.7714.1 to use the "distinguishing character" so that various termination and NIM = functions can tell the difference between a message used for = discovery/connectivity verification and a normal trace identifier. I am not convinced by arguments such as "you will never see these in the same network" or "the specific scenario is such that the wrong TT function or NIM function will never see this message". You can never quite tell how someone will connect things or use a particular feature, and it seems like a far more robust approach to choose a format where it is always possible to distinguish between the various possible uses of the same bytes. db: Note, to clarify, G7714.1 requires all new G7714.1-aware transport = equipment, both terminations and intermediate equipment. And for = operators, "turning-off" of legacy intermediate NIMs is not an option = (proposed in G7714.1), as the investment in intermediate NIMs is not for = 24/7 entertainment of our field staff. G7714.1 does not "peacefully = coexist". One ITU operator suggested using a different byte than Jx = based on this concern with G7714.1. Whereas, LMP requires GMPLS-aware = transport equipment. And LMP provides two options depending on support = by legacy equipment (in-band, correlation). For either G7714.1 or GMPLS = LMP, an operator chooses equipment configurations/options based on their = application. New applications/new equipment (no free lunch;-)). No = different from today's operations. And the two options (in-band, = correlated) provided by LMP support two different use scenarios, = including use of legacy NIMs. As discussed for G7714.1, Q9 needs to = evaluate the equipment support scenarios. ---end of comment--- Another thing that I think I read between the lines of your response = would be worth spelling out explicitly in the lmp-test draft. The intent is = for pre-service. What I think this means is the following (assuming that = this is correct, the draft should say so): - For VC-n/m signals, there is never an ACTUAL VC-n/m present. So when = you use the Jx bytes for discovery/connectivity verification in this = context, it will be included in a supervisory unequipped signal that is created with the Jx bytes inserted with the appropriate message. These = messages will never be carried in anything except a supervisory unequipped = signal. - For RS-n signals, since there is no "supervisory unequipped" signal = that is different from an in-service regenerator section, the pre-service = state is inferred from alarm reporting - either old style "NMON" as per = G.783, or "NALM" as per M.3100 Amendment 3 Alarm Reporting Control. (This is probably as good as can be done for the RS layer - personally, I am = not very comfortable with this as operators may temporarily turn off = alarming for all kinds of reasons. Being in an "NMON" or "NALM" state does not always mean that there is no customer payload of VC-n/m signals being carried, in contrast to a supervisory unequipped signal which will = never carry a customer payload - in any case, I am not sure what else you = can do to try to distinguish a "pre-service" state for RS-n signals). db: Or it can be viewed as a gmpls test signal generator. Similar to = G7714.1 (which did not include any text on the signal format), it should = not be defined at this time, it needs input by ITU Q9/Q11. Jonathan = already noted this in his response regarding G783. Note, the monitoring = state does not define the service state, the service state defines the = monitoring options;-) --- end of comment --- Regards, Steve Jonathan Lang wrote: >=20 > George, > Please see inline. >=20 > Thanks, > Jonathan >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of George Newsome > > Sent: Monday, April 21, 2003 12:27 PM > > To: Dimitri.Papadimitriou@alcatel.be; = Jonathan.Lang@RinconNetworks.com > > Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org; Deborah Brungard > > (E-mail); Steve Trowbridge (E-mail); Kireeti@juniper.net; > > 'Ron Bonica (E-mail)'; zinin@psg.com > > Subject: Re: Proposed response to the Liaison Statement on > > LMP Link Verification > > > > > > All, > > > > I have a few comments on the proposed response to the Liaison > > Statement > > from T1-X1 on LMP Link Verification. > > > > It seems to me that the response agrees that the application is the > > same, verifying the transport connectivity between two > > points. However > > no mention is made as to why it is neither possible nor > > desirable to use > > the same message format, thereby reducing the amount of > > variation in the > > world. > As I said in my response to Rajender, the intention was to agree the > "application space" and "scenario of use" are different from what is > described in the t1x1 liaison. Where in response did we acknowledge = the > context is the same for g7714.1 and lmp? >=20 > > > > One unwanted consequence of three Jx formats is equipment burden. = Why > > should equipment be burdened with three variations, when two are = quite > > sufficient? Part of this burden is unnecessary behaviour for = equipment > > to sort out which format is being used, provisioning of the choice, = or > > simply being non interoperable. > > > > A single format, which is useful in non green field = applications,makes > > a lot of sense. > For legacy equipment, the Jx-trace mechanism (defined in LMP) would be > the easiest to provide the required functionality. It doesn't modify > any of the Jx formats from existing deployments. >=20 > > > > I also have a few specific comments inline. > > > > Regards > > > > George Newsome > > > > > > Wijnen, Bert (Bert) wrote: > > > > > Thnaks for the proposed response. > > > > > > It would be good if people could tell us if they agree or disagree > > > and if they disagree, then pls explain why. > > > > > > If the response is acceptable, then it sounds to me that at least > > > there would be no impact on the draft-ietf-ccamp-lmp-08.txt > > > document, which is currently in IETF Last Call. Since we had split > > > the SONET/SDH material off into a separate document, my initial > > > evaluation made me think that the draft-ietf-ccamp-lmp-08.txt > > > would not have any ITU-T/T1X1 issues/concerns. The liason = statement > > > did refer to it a few times and so I started to worry, but from > > > the (proposed) response it seems there is no isseu. > > > > > > Would be good to get at least confimration of that by the end > > > of the Last Call, and that is April 24th. > > > > > > Thanks, > > > Bert > > > > > > > > >>-----Original Message----- > > >>From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com] > > >>Sent: vrijdag 18 april 2003 22:25 > > >>To: ccamp@ops.ietf.org > > >>Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; > > >>bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be > > >>Subject: FW: Proposed response to the Liaison Statement on > > >>ASON Routing > > >> > > >> > > >>All, > > >> > > >>Here's a proposed response to the Liaison Statement from > > T1-X1 on LMP > > >>Link Verification, posted April 11, 2003. > > >> > > >>Thanks, > > >>Jonathan & Dimitri > > = >>-------------------------------------------------------------------- > > >>Dear Mr. Biholar, > > >> > > >> > > >> > > >>>Context of Application Space > > >>> > > >> > > >> > > >>>It is currently our understanding that the use case > > >>>scenario for which this procedure is applied encompasses > > >>>both transport plane connectivity verification as well as > > >>>correlation of these entities with the control plane. > > >>>ITU-T G.7714.1 is focused on discovering the transport > > >>>plane link connection end point relationships and > > >>>verifying their connectivity. > > >>>This Recommendation defines two procedures for performing > > >>>the connectivity verification function, one of which > > >>>utilizes either the Jx or the DCC bytes of the server > > >>>signal (termed "in-service"). The other approach in > > >>>G.7714.1, termed as "out of service", corresponds to > > >>>inserting a test signal in the payload of the server > > >>>signal. Based on an analysis of the data link state > > >>>definitions in draft-ietf-ccamp-lmp-08.txt, we understand > > >>>that the approach defined in the LMP test for physical > > >>>connectivity occurs in the context of the "out of service" > > >>>state (as described in G.7714.1). > > >>> > > >>>Please confirm this. > > >>> > > >>Yes, this is correct > > >> > > >> > > >>>Usage of Jx Bytes > > >>> > > >>>In defining the Jx bytes within G.7714.1, the following > > >>>was taken into account: > > >>>1. One consideration involved the case where the Discovery > > >>>Agent is located in an external system, and an external > > >>>interface is used by the Network Element to provision and > > >>>receive the Trail Trace message. As an existing text- > > >>>oriented Man-Machine Language, such as TL1, may be reused > > >>>to provide this interface, it was decided that the > > >>>discovery message be limited to printable characters. > > >>>Specifically, the TTI characters should be limited to > > >>>printable characters as per T.50 with trailing NULLs or > > >>>SPACEs. Use of arbitrary bit patterns in the lower 7 bits > > >>>of each byte could prematurely terminate the pattern or > > >>>trigger fault notification for certain hardware or > > >>>software implementations. The strategy chosen in G.7714.1 > > >>>avoids the danger by limiting the information content of > > >>>each byte to 6 bits (84 bits total) and uses a base 64 > > >>>coding according to RFC2045 to place the information in > > >>>the available bits. > > >>> > > >> We understand that a general transport plane discovery agent > application > > >> such as G.7714.1 may want to limit the format to printable > > >> characters. However, LMP is a subset of the GMPLS control plane > > >> where no such constraint exists. As such, we don't think LMP > > >> link verification needs to be constrained to be printable > > >> characters. > > >> > > > > This does not give any reason as to why LMP could not or should not > use > > this limitation. When GMPLS is retrofitted onto todays networks, the > > same limitation will be there for the same reasons G.7714.1 took > account > > of it. LMP may be pre-service, but this is not the same as a green > field > > application. > I see no reason why LMP should have this limitation. I don't = understand > your comment about "not the same as green field application". The > J0-trace mechanism doesn't require any modification to the Jx bytes. >=20 > > > > > > >> > > >>>2. Another consideration involved providing a means for > > >>>distinguishing this use of the Jx bytes from the > > >>>traditional use for Trail Trace identifiers in new > > >>>equipments. As a result, G.7714.1 includes a > > >>>distinguishing character ("+") as the first non-CRC byte > > >>>that will never appear as the first character of a TTI. > > >>>This requires modification of the trail termination > > >>>functions to prevent the raising of TTI mismatch > > >>>alarms during the connectivity verification process. > > >>> > > >> We understand the need for this distinguishing character for the > > >> G7714.1 in-service application; however, LMP link > > verification is designed > > >> to be used before a link is put in service. It is our = understanding > > >> per G.806 section 6.1, when a TTP is not in service, it is in > > >> the NMON state (not monitored)." > > >> > > > > > > Many network elements take the availability of an input signal as a > > trigger to switch into monitoring mode. However, even for those = which > do > > not, there does not seem to be a good reason for not using a > > common format. > I can think of a couple. The application space and usage are = different. >=20 > > > > > > >> > > >>>While the context for testing the transport plane > > >>>connectivity is different between the two documents, they > > >>>both use the Jx bytes of the server signal, and we invite > > >>>the IETF to determine the appropriateness of the above > > >>>aspects in their test signal definitions. > > >>> > > >>We agree the context is different. We evaluated the above > > aspects and > > >>we don't feel they are appropriate for LMP (see comments above). > > >> > > > > > > I'm still looking for the rationale that led you to this > > conclusion. I only see a statement. > Please see above. >=20 > > > > >> > > >>>Even if these considerations are not relevant to this > > >>>context, it will be necessary to augment G.783 equipment > > >>>functions to recognize this new usage of Jx messages. > > >>> > > >>We would be happy to provide assistance to T1X1/ITU-T in = augmenting > > >>G.783 equipment functions to recognize the additional capability = for > > >>GMPLS networking elements. > > >> > > >> > > >>>Required Updates to SDH Equipment Specifications > > >>> > > >>>SDH equipment specifications as they currently exist reflect > > >>>the usage of the Jx bytes prior to the development of > > >>>G.7714.1. ITU-T Study Group 15 has as a work item to > > >>>revise these equipment functions to include support for > > >>>these new functions. Specifically, this will involve > > >>>updates to trail termination functions to generate and > > >>>receive the new messages and to avoid unnecessary alarms in > > >>>the case where the new messages are received. In addition, > > >>>non-intrusive monitoring functions will need to be revised > > >>>so that unnecessary alarms are not raised when the > > >>>messages are observed en-route. Whether or not there is > > >>>further alignment between the message formats used in > > >>>G.7714.1 and the subject draft, the new functions to > > >>>support the subject draft will also need to be reflected > > >>>in the atomic functions in G.783. The sending and > > >>>receiving of these messages can be reflected in the trail > > >>>termination functions in a similar way to what we plan to > > >>>do for support of G.7714.1 functions. > > >>> > > >> We understand that G7714.1 is addressing an in-service test > > >> procedure and needs to be concerned with NIM (and non-support of > G7714.1 > > >> by legacy NIM). The LMP test procedure is a pre-service > > >> application. We will be happy to work with T1X1/ITU SG15 to > > >> augment G.783 to recognize the additional capability for GMPLS > > >> networking elements. > > > > > > It seems to me that having yet another format to do the same > > thing, and which cannot be interleaved with normal tracing, is not = an > additional > > capability, but less capability. > See above about doing "the same thing." As far as normal tracing = goes, > see J0-trace mechanism in LMP Link Verification. It's my = understanding > that G.7714.1 defines a new Jx format which will not work with = existing > hardware and normal tracing. >=20 > > > > >> > > >>>Terminology Differences > > >>> > > >> > > >> > > >>>Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, > > >>>the "up/free (in-service)" data link state appears to > > >>>correspond with what G.7714.1 refers to as "out-of- > > >>>service". This difference in terminology has resulted in > > >>>different interpretations of the context. Explaining the > > >>>scenarios further in the lmp test document would be > > >>>beneficial in establishing a translation between the > > >>>differing uses of the same terms. Within ITU-T, work is > > >>>being initiated of draft Rec. G.fame, Framework for ASON > > >>>Management, where control plane/management plane > > >>>interactions will be addressed. > > >>> > > >> We agree that terminology differences between IETF and ITU wrt > > >> GMPLS have been confusing. There is an ongoing effort within > > >> CCAMP to work together with ITU/T1X1 on bridging the terminology > > >> gaps. For example, there is a new Internet draft > > (draft-aboulmagd-ccamp-transport-lmp-00.txt) > > >> being considered in CCAMP to do this mapping for LMP. > > >> > > >>>Further Study Items > > >>> > > >>>Following are some areas where further contributions are > > >>>requested: > > >>>1. For SDH equipment functions in G.783, it needs to > > >>>be understood whether the application of the lmp test > > >>>message requires revision of NIM (non-intrusive > > >>>monitoring) functions. The reason for this is that the > > >>>test procedure is initiated between control entities at > > >>>the end-points of the trail, and intermediate points are > > >>>not necessarily aware that the test is taking place. For > > >>>G.7714.1, it was felt important for any termination or NIM > > >>>function to easily distinguish between the various uses of > > >>>the Jx bytes. It may be necessary for the subject draft > > >>>to use a similarly easily recognizable format. If no > > >>>revision to NIM functions is required for the context of > > >>>this draft, the architecture of the context for this > > >>>application (demonstrating why the NIM functions are not > > >>>required) should be reflected in G.803 and/or G.807/G.8080. > > >>> > > >> We understand that G7714.1 is addressing an in-service test > > >> procedure and needs to be concerned with NIM (and non-support of > G7714.1 > > >> by legacy NIM). The LMP test procedure is a pre-service > > >> application. Can you clarify how "pre-service" > > >> applications impact G.803/G.807/G.8080? If we > > >> can provide assistance in updating these Recommendations to > > >> reflect LMP applications, please let us know. > > >> > > >> G.803/G.807/G.8080? If we can provide assistance in updating > > >> these Recommendations to reflect LMP applications, please let us > > >> know. > > >> > > >>>2.Determination of whether it would be possible to use the > > >>>identical message formats in the subject draft as in > > >>>G.7714.1 for the connectivity verification function. > > >>> > > >>We have evaluated the current formats in G.7714.1 and we believe = are > > >>inappropriate for the usage of LMP. > > >> > > > > > > Some rationale for this belief would be most useful. > See above. >=20 > > > > > > >> > > >>>3.Determination of whether it would be possible to use the > > >>>same overall structure (distinguishing character, 4 bit > > >>>message type, 80 bit message body) if a different message > > >>>format or information content is required. > > >>> > > >>As mentioned above, we believe the overall message structure and > > >>constraints are inappropriate for LMP. > > >> > > > > > > I don't see answers to the above questions re technical feasibility, > and > > belief is not a reason for not using the same format in the = interests > of > > reducing variation. > See above. >=20 > > > > >> > > >>>4.Work is needed to clarify under what > > >>>configurations/states (for example: no VC-n signals > > >>>carrying client traffic) the lmp test message is > > >>>applicable over J0. If the signal can be framed and J0 > > >>>can be recovered, the Regenerator Section is considered > > >>>as "in service" from a transport plane perspective. So > > >>>unlike the J1/J2 case, the application of the lmp test > > >>>message at the Regenerator Section does not occur in an > > >>>"out of service" state (from a transport plane > > >>>perspective). > > >>> > > >> Section 6.1 of G.806 refers to a "termination function part of a > > >> trail, which is in the process of set-up" as in the NMON state. > > >> LMP link verification is based on pre-service testing. Please let > > >> us know if we can be of any assistance in updating the > > >> appropriate Recommendations to support the GMPLS network element > > >> LMP capability. > > >> > > >> > > >>>5. Clarification of the usage of transport and control > > >>>names for transport resources in the subject draft, as > > >>>described in G.8080 Amendment > > >>> > > >>LMP defines a TRACE object when a separation between data > > and control > > >>plane name space is requested. > > >> > > > > > > I'm afraid that I don't understand this answer. > Please look at Section 3.1 and Section 4 of > draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt. >=20 > > > > > > >> > > >>>6. Consideration of the ANSI 64-byte J1. > > >>> > > >>This was mistakenly deleted from the latest version of the > > draft. This > > >>will be included in the next version. > > >> > > > > > > > > Hopefully, this will not create yet another format. > Nope. Since the byte limitation isn't as severe, it will follow the > nomal LMP Test message format without any additional formats. See > draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt (previous version of the > draft) for the text. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Apr 2003 19:54:11 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155016A36A2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Dimitrios Pendarakis , "Dimitri Papadimitriou (E-mail)" , "Steven M. Bellovin" Cc: "Ccamp-wg (E-mail)" Subject: RE: draft-ietf-ccamp-gmpls-architecture Date: Tue, 22 Apr 2003 21:49:03 +0200 MIME-Version: 1.0 Content-Type: text/plain Steve thanks for the input/review. Dimitrios and Dimitri, if the two of you could respind the draft (by Thursday at the latest) to try and address Steves (and other, as posted to the list) comments, then I can put it back on IESG agenda for next week. Thanks, Bert > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: dinsdag 22 april 2003 18:31 > To: Dimitrios Pendarakis > Cc: 'Wijnen, Bert (Bert)'; Ccamp-wg (E-mail); zinin@psg.com > Subject: Re: draft-ietf-ccamp-gmpls-architecture > > > In message > <05707214338CD5119BFF0040A5B170D30347EEDB@mail3.tellium.com>, Dimitr > ios Pendarakis writes: > >Bert, > > > >Comments on the issues brought up by Steve: > >i) The risk of attackers being able to inject and/or snoop on > > (control) traffic depends on both the physical characteristics > > of the control link and whether the interface is an inter- or > > intra-domain one. For example, an in-band, in-fiber control > > channel over SONET/SDH overhead bytes is, in general, considered > > less vulnerable than an out-of-band IP network. > Similarly, however, > > most carriers seem to consider control links that are not within > > their control (intra-domain) less secure. > > > > Proposed resolution: Add statement in the document stressing the > > dependency on control link physical characteristics. > > And delete the text about intra-domain versus inter-domain -- that's > not relevant here. > > > > >ii) Difference between authentication and authorization. I believe > > authorization falls in the category of what is commonly called > > "policy control". Steve is right about pointing this out, as well > > as the implications of appropriate policy controls to increase > > security and limit the impact of attacks. > > > > Proposed resolution: Expand on the difference, add > references for > > policy control (rap WG?) and Steve's comment. I can provide some > > updated text for this, as well as (i). > > I don't think that that's right. The issue is who has the right to, > say, allocate or reallocate lambdas between given pairs of switches. > Note that there are two very different questions here: how to > represent, on the wire, the resources that are available to a given > party, and how to make more complex decisions, such as a limit on the > total bandwidth available to some party in the presence of contention > for certain resources. Simple policies -- "party A, > identified by the > following mechanism, may request N megabits/sec" are simple. > But what > about requests for enough different lambdas that a given waveband of > the desired capacity is not available? > > You can't solve this broader problem here; that's the sort of thing I > would like in some follow-on document. But this document needs to > sketch the problem in enough detail that implementors are > aware of it. > (In some sense, the solution doesn't require > interoperability. Control > elements will receive request and match them against the > local security > policy. My goal for this document is that the requirement be spelled > out clearly enough that people will understand the need. > > > >iii) Need for a (broader) security architecture. Clearly, a > small section > > in the architecture document can not claim to address > all security > > issues. I recall that there have been some individual > draft submissions > > in the past regarding security requirements. > Additionally, other bodies > > such as the OIF have carried more work on securing intra-domain > > interfaces for transport networks; some of that work > could hopefully be > > useful in this discussion. While much of the additional > work involves > > using profiles of existing IP security mechanisms in the > ccamp context, > > I can see benefits in terms of pursuing this further, > especially since > > it would help alleviate one of the concerns that > carriers considering > > deployment of GMPLS or similar solutions have. > > > >Thanks, > >Dimitris > > > > > >-----Original Message----- > >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > >Sent: Wednesday, April 16, 2003 12:38 PM > >To: Ccamp-wg (E-mail) > >Cc: Steve Bellovin (E-mail) > >Subject: FW: draft-ietf-ccamp-gmpls-architecture > > > > > >Comments on the document from IESG. I think we need an answer > >to the serious comment made by Steve > > > >-----Original Message----- > >From: Steve Bellovin [mailto:smb@research.att.com] > >Sent: woensdag 16 april 2003 18:20 > >To: iesg-secretary@ietf.org > >Cc: iesg@ietf.org > >Subject: draft-ietf-ccamp-gmpls-architecture > > > > > >Nit: section 4 says > > > > Re-using existing IP routing protocols allows for non-PSC > layers to > > take advantages of all the valuable developments that took place > > since years for IP routing, > > > >which isn't grammatically correct. > > > >Serious issue: > > > >The Security Considerations section hints at, but doesn't follow > >through with, the difference between authentication and > authorization. > >The requirement for cryptographic authentication or encryption > >depends on the risk of attackers being able to inject and/or snoop > >on traffic. This may or may not be correlated with intra-domain vs. > >inter-domain GMPLS. The physical characteristics and exposure of the > >link matter more; there may be additional exposure since it > appears that > >the control plane link may be more than one hop long. > > > >The authorization question is what resources a given node may request > >of another. This may indeed be differ for inter-domain and > intra-domain > >GMPLS. On the other hand, imposing such limits even internally helps > >guard against spreading break-ins, and has useful effects with regard > >to configuration errors. > > > >The more important question raised by this latter point is whether or > >not a security architecture is needed that specifies what sorts of > >restrictions can be applied. I don't know the answer to > that one; clearly, > >though, implementors are going to have to decide. > > > > > >************************************************************* > ********* > >This email and any files transmitted with it are > confidential and intended sol > >ely for the use of the individual or entity to whom they are > addressed. Any re > >view, retransmission or other use of this communication by > any person or entit > >y other than the intended recipient is prohibited. If you > believe that you hav > >e received this email in error please notify the sender by > return electronic m > >ail and delete all copies of this communication. > >************************************************************* > ********* > > > > > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com (2nd edition of > "Firewalls" book) > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Apr 2003 15:56:22 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155016A3652@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Ron Bonica , "Ccamp-wg (E-mail)" Subject: RE: draft-ietf-ccamp-tracereq-01.txt Date: Tue, 22 Apr 2003 17:54:57 +0200 MIME-Version: 1.0 Content-Type: text/plain Some comments from my side inline > > -----Original Message----- > > From: Ron Bonica [mailto:Ronald.P.Bonica@mci.com] > > Sent: maandag 21 april 2003 20:55 > > To: Wijnen, Bert (Bert); Ccamp-wg (E-mail) > > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > > > > Bert, > > > > Sorry to have taken so long to respond. I have been away on > > vacation. > > No problem... we all need that once in a while (or so I think) > > Comments inline..... > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Wijnen, Bert (Bert) > > > Sent: Wednesday, April 16, 2003 9:30 AM > > > To: Ccamp-wg (E-mail) > > > Subject: FW: draft-ietf-ccamp-tracereq-01.txt > > > > > > > > > Please consider these comments and let me know if they > > > wrrant some additional text in the ID. > > > > > > Thanks, > > > Bert > > > > > > >***** o Tracing Requirements for Generic Tunnels (None) > > > > > > > > Token: Wijnen, Bert > > > > Note: New revision Addresses comments. > > > > Now on IESG agenda for April 17th > > > > Responsible: Bert > > > > > > 1. this document looks like it might be the union of all the > > > "i want it to do " requests. an important part of > > > requirements documents is knowing what to not require. > > > do they have any? > > > > This document specifies requirements for a new protocol. It specifies > > requirements, primarily, by detailing the required capabilities of > > applications that will use this protocol. The application may implement > > some subset of those capabilities. It may also implement a superset of > > the required capabilities. However, protocol designers are not required > > to consider the additional capabilities when designing the protocol. > > > > Should there be some text to this effect included in the draft? > > Might be a good idea... > > > 2. i am concerned about the security stuff that they've buried in > > > their requirements. nothing definite. it seems unwieldy. but > > > then, so many security things do... > > > > Can you be more specific? Is there any particular requirement that > > you feel cannot be implemented? > > Well... remember I had a bot of trouble finding which of the numbered bullets needed some extra security or not... I guess that is what the commenting person may have meant with "burried". > > > 3. section 4.1 and 4.2 seem to be worded with a particular > > > implementation in mind. requirements documents ought not > > > specify solutions (eg, 4.2 talks about udp, why can't i use > > > icmp?) > > > > Section 4 provides a few protocol requirements, stated as such. In > > particular, Section 4.1 states that the new protocol will consist of > > probes and responses, and that each probe/response pair will reveal > > information regarding a network hop. (In this respect, the > > new protocol will resemble TRACEROUTE). > > > > Had I remembered to include an application requirement to support partial > > traces through broken paths, this requirement would have made much more > > sense! > > I will fix this. > > Great > > Section 4.2 requires that the protocol be implemented over UDP. I included > > this section primarily to rule out implmentations that were _not_ > > acceptable. For example, ICMP should not be used, because carrying MPLS > > information over ICMP would constitute a layer violation. TCP should not > > be used, because this would conflict with the protocol's > > requirement for statelessness. Tunnel specific mechanisms > > should not be used, because > > this would conflict with the requirement for generality. > > > > This leaves UDP and IP as the two most resonable candidates. Should I > > include some words the that effect in the document? > > So, although I guess many (nmost) of us understand that, adding some of that explantnion to the document may help (more novice) readers. > > > > > 4. justification of requirements might be nice. > > > > > > > This is interesting, but it could result in a much longer > > document. Wouldn't this distract the reader from the document's > > basic intent? > > Always difficult to say. I personally like for example RFC3216 format. > > In any event, I will spin a new version of the document as > > soon as there is some response to this message. > > Good. I hope to get responses soon. Others on the WG list, please do chime in if you have an opinion. Bert > > Ron > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Apr 2003 15:50:51 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155016A364E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Ron Bonica , "Ccamp-wg (E-mail)" Subject: RE: draft-ietf-ccamp-tracereq-01.txt Date: Tue, 22 Apr 2003 17:47:44 +0200 MIME-Version: 1.0 Content-Type: text/plain Thjanks Ron, I am checking with the people who raised the issues. Thanks, Bert > -----Original Message----- > From: Ron Bonica [mailto:Ronald.P.Bonica@mci.com] > Sent: maandag 21 april 2003 20:55 > To: Wijnen, Bert (Bert); Ccamp-wg (E-mail) > Subject: RE: draft-ietf-ccamp-tracereq-01.txt > > > Bert, > > Sorry to have taken so long to respond. I have been away on vacation. > > Comments inline..... > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Wijnen, Bert (Bert) > > Sent: Wednesday, April 16, 2003 9:30 AM > > To: Ccamp-wg (E-mail) > > Subject: FW: draft-ietf-ccamp-tracereq-01.txt > > > > > > Please consider these comments and let me know if they > > wrrant some additional text in the ID. > > > > Thanks, > > Bert > > > > >***** o Tracing Requirements for Generic Tunnels (None) > > > > > > Token: Wijnen, Bert > > > Note: New revision Addresses comments. > > > Now on IESG agenda for April 17th > > > Responsible: Bert > > > > 1. this document looks like it might be the union of all the > > "i want it to do " requests. an important part of > > requirements documents is knowing what to not require. > > do they have any? > > This document specifies requirements for a new protocol. It specifies > requirements, primarily, by detailing the required capabilities of > applications that will use this protocol. The application may > implement > some subset of those capabilities. It may also implement a superset of > the required capabilities. However, protocol designers are > not required > to consider the additional capabilities when designing the protocol. > > Should there be some text to this effect included in the draft? > > > 2. i am concerned about the security stuff that they've buried in > > their requirements. nothing definite. it seems unwieldy. but > > then, so many security things do... > > Can you be more specific? Is there any particular requirement that > you feel cannot be implemented? > > > 3. section 4.1 and 4.2 seem to be worded with a particular > > implementation in mind. requirements documents ought not > > specify solutions (eg, 4.2 talks about udp, why can't i use > > icmp?) > > Section 4 provides a few protocol requirements, stated as such. In > particular, Section 4.1 states that the new protocol will consist of > probes and responses, and that each probe/response pair will reveal > information regarding a network hop. (In this respect, the > new protocol > will resemble TRACEROUTE). > > Had I remembered to include an application requirement to > support partial > traces through broken paths, this requirement would have made > much more > sense! > I will fix this. > > Section 4.2 requires that the protocol be implemented over > UDP. I included > this > section primarily to rule out implmentations that were _not_ > acceptable. For > example, > ICMP should not be used, because carrying MPLS information > over ICMP would > constitute > a layer violation. TCP should not be used, because this would > conflict with > the protocol's > requirement for statelessness. Tunnel specific mechanisms > should not be > used, because > this would conflict with the requirement for generality. > > This leaves UDP and IP as the two most resonable candidates. Should I > include some words > the that effect in the document? > > > > 4. justification of requirements might be nice. > > > > This is interesting, but it could result in a much longer > document. Wouldn't > this distract > the reader from the document's basic intent? > > In any event, I will spin a new version of the document as > soon as there is > some response to this message. > > Ron > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Apr 2003 15:47:58 +0000 Message-ID: <3EA56365.41528195@lucent.com> Date: Tue, 22 Apr 2003 09:44:37 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Jonathan.Lang@RinconNetworks.com CC: "'George Newsome'" , Dimitri.Papadimitriou@alcatel.be, "'Wijnen, Bert (Bert)'" , ccamp@ops.ietf.org, "'Deborah Brungard (E-mail)'" , Kireeti@juniper.net, "'Ron Bonica (E-mail)'" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verification Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan, I think that the following are true: - Both the lmp-test draft and G.7714.1 perform connectivity discovery and verification. - Both the lmp-test draft and G.7714.1 have chosen scenarios where they will use the Jx bytes for this purpose, although they have chosen different points in the life cycle where Jx byte messaging is considered appropriate. While the procedures seem to be executed at different points in time, they seem to be for the same purpose over the same bytes, which would suggest that it is worthwhile looking for better alignment rather than having everybody go their own way. The words "Green Field" have been tossed about, and I think there are actually two questions here: - To what extent to we require new or redesigned equipment to implement this functionality? The installed base of SONET/SDH equipment is huge, and I think there is a great desire to deploy this kind of technology with the most minor possible tweaks to the existing transport equipment. I think this desire is behind the suggestions to try to keep the Jx format as close as possible to the current formats used for TTIs (e.g., printable characters) and the requests not to define multiple formats to be used for the same or similar purposes. - To what extent do we wish to deploy this kind of technology over existing SONET/SDH networks? I think that many operators are interested in deploying ASON/GMPLS technology over a portion of the capacity of their existing transport networks. As a result, it is useful to look at what is required for "peaceful coexistance" of this technology with other traffic. This is what has motivated in G.7714.1 to use the "distinguishing character" so that various termination and NIM functions can tell the difference between a message used for discovery/connectivity verification and a normal trace identifier. I am not convinced by arguments such as "you will never see these in the same network" or "the specific scenario is such that the wrong TT function or NIM function will never see this message". You can never quite tell how someone will connect things or use a particular feature, and it seems like a far more robust approach to choose a format where it is always possible to distinguish between the various possible uses of the same bytes. Another thing that I think I read between the lines of your response would be worth spelling out explicitly in the lmp-test draft. The intent is for pre-service. What I think this means is the following (assuming that this is correct, the draft should say so): - For VC-n/m signals, there is never an ACTUAL VC-n/m present. So when you use the Jx bytes for discovery/connectivity verification in this context, it will be included in a supervisory unequipped signal that is created with the Jx bytes inserted with the appropriate message. These messages will never be carried in anything except a supervisory unequipped signal. - For RS-n signals, since there is no "supervisory unequipped" signal that is different from an in-service regenerator section, the pre-service state is inferred from alarm reporting - either old style "NMON" as per G.783, or "NALM" as per M.3100 Amendment 3 Alarm Reporting Control. (This is probably as good as can be done for the RS layer - personally, I am not very comfortable with this as operators may temporarily turn off alarming for all kinds of reasons. Being in an "NMON" or "NALM" state does not always mean that there is no customer payload of VC-n/m signals being carried, in contrast to a supervisory unequipped signal which will never carry a customer payload - in any case, I am not sure what else you can do to try to distinguish a "pre-service" state for RS-n signals). Regards, Steve Jonathan Lang wrote: > > George, > Please see inline. > > Thanks, > Jonathan > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of George Newsome > > Sent: Monday, April 21, 2003 12:27 PM > > To: Dimitri.Papadimitriou@alcatel.be; Jonathan.Lang@RinconNetworks.com > > Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org; Deborah Brungard > > (E-mail); Steve Trowbridge (E-mail); Kireeti@juniper.net; > > 'Ron Bonica (E-mail)'; zinin@psg.com > > Subject: Re: Proposed response to the Liaison Statement on > > LMP Link Verification > > > > > > All, > > > > I have a few comments on the proposed response to the Liaison > > Statement > > from T1-X1 on LMP Link Verification. > > > > It seems to me that the response agrees that the application is the > > same, verifying the transport connectivity between two > > points. However > > no mention is made as to why it is neither possible nor > > desirable to use > > the same message format, thereby reducing the amount of > > variation in the > > world. > As I said in my response to Rajender, the intention was to agree the > "application space" and "scenario of use" are different from what is > described in the t1x1 liaison. Where in response did we acknowledge the > context is the same for g7714.1 and lmp? > > > > > One unwanted consequence of three Jx formats is equipment burden. Why > > should equipment be burdened with three variations, when two are quite > > sufficient? Part of this burden is unnecessary behaviour for equipment > > to sort out which format is being used, provisioning of the choice, or > > simply being non interoperable. > > > > A single format, which is useful in non green field applications,makes > > a lot of sense. > For legacy equipment, the Jx-trace mechanism (defined in LMP) would be > the easiest to provide the required functionality. It doesn't modify > any of the Jx formats from existing deployments. > > > > > I also have a few specific comments inline. > > > > Regards > > > > George Newsome > > > > > > Wijnen, Bert (Bert) wrote: > > > > > Thnaks for the proposed response. > > > > > > It would be good if people could tell us if they agree or disagree > > > and if they disagree, then pls explain why. > > > > > > If the response is acceptable, then it sounds to me that at least > > > there would be no impact on the draft-ietf-ccamp-lmp-08.txt > > > document, which is currently in IETF Last Call. Since we had split > > > the SONET/SDH material off into a separate document, my initial > > > evaluation made me think that the draft-ietf-ccamp-lmp-08.txt > > > would not have any ITU-T/T1X1 issues/concerns. The liason statement > > > did refer to it a few times and so I started to worry, but from > > > the (proposed) response it seems there is no isseu. > > > > > > Would be good to get at least confimration of that by the end > > > of the Last Call, and that is April 24th. > > > > > > Thanks, > > > Bert > > > > > > > > >>-----Original Message----- > > >>From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com] > > >>Sent: vrijdag 18 april 2003 22:25 > > >>To: ccamp@ops.ietf.org > > >>Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; > > >>bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be > > >>Subject: FW: Proposed response to the Liaison Statement on > > >>ASON Routing > > >> > > >> > > >>All, > > >> > > >>Here's a proposed response to the Liaison Statement from > > T1-X1 on LMP > > >>Link Verification, posted April 11, 2003. > > >> > > >>Thanks, > > >>Jonathan & Dimitri > > >>-------------------------------------------------------------------- > > >>Dear Mr. Biholar, > > >> > > >> > > >> > > >>>Context of Application Space > > >>> > > >> > > >> > > >>>It is currently our understanding that the use case > > >>>scenario for which this procedure is applied encompasses > > >>>both transport plane connectivity verification as well as > > >>>correlation of these entities with the control plane. > > >>>ITU-T G.7714.1 is focused on discovering the transport > > >>>plane link connection end point relationships and > > >>>verifying their connectivity. > > >>>This Recommendation defines two procedures for performing > > >>>the connectivity verification function, one of which > > >>>utilizes either the Jx or the DCC bytes of the server > > >>>signal (termed "in-service"). The other approach in > > >>>G.7714.1, termed as "out of service", corresponds to > > >>>inserting a test signal in the payload of the server > > >>>signal. Based on an analysis of the data link state > > >>>definitions in draft-ietf-ccamp-lmp-08.txt, we understand > > >>>that the approach defined in the LMP test for physical > > >>>connectivity occurs in the context of the "out of service" > > >>>state (as described in G.7714.1). > > >>> > > >>>Please confirm this. > > >>> > > >>Yes, this is correct > > >> > > >> > > >>>Usage of Jx Bytes > > >>> > > >>>In defining the Jx bytes within G.7714.1, the following > > >>>was taken into account: > > >>>1. One consideration involved the case where the Discovery > > >>>Agent is located in an external system, and an external > > >>>interface is used by the Network Element to provision and > > >>>receive the Trail Trace message. As an existing text- > > >>>oriented Man-Machine Language, such as TL1, may be reused > > >>>to provide this interface, it was decided that the > > >>>discovery message be limited to printable characters. > > >>>Specifically, the TTI characters should be limited to > > >>>printable characters as per T.50 with trailing NULLs or > > >>>SPACEs. Use of arbitrary bit patterns in the lower 7 bits > > >>>of each byte could prematurely terminate the pattern or > > >>>trigger fault notification for certain hardware or > > >>>software implementations. The strategy chosen in G.7714.1 > > >>>avoids the danger by limiting the information content of > > >>>each byte to 6 bits (84 bits total) and uses a base 64 > > >>>coding according to RFC2045 to place the information in > > >>>the available bits. > > >>> > > >> We understand that a general transport plane discovery agent > application > > >> such as G.7714.1 may want to limit the format to printable > > >> characters. However, LMP is a subset of the GMPLS control plane > > >> where no such constraint exists. As such, we don't think LMP > > >> link verification needs to be constrained to be printable > > >> characters. > > >> > > > > This does not give any reason as to why LMP could not or should not > use > > this limitation. When GMPLS is retrofitted onto todays networks, the > > same limitation will be there for the same reasons G.7714.1 took > account > > of it. LMP may be pre-service, but this is not the same as a green > field > > application. > I see no reason why LMP should have this limitation. I don't understand > your comment about "not the same as green field application". The > J0-trace mechanism doesn't require any modification to the Jx bytes. > > > > > > > >> > > >>>2. Another consideration involved providing a means for > > >>>distinguishing this use of the Jx bytes from the > > >>>traditional use for Trail Trace identifiers in new > > >>>equipments. As a result, G.7714.1 includes a > > >>>distinguishing character ("+") as the first non-CRC byte > > >>>that will never appear as the first character of a TTI. > > >>>This requires modification of the trail termination > > >>>functions to prevent the raising of TTI mismatch > > >>>alarms during the connectivity verification process. > > >>> > > >> We understand the need for this distinguishing character for the > > >> G7714.1 in-service application; however, LMP link > > verification is designed > > >> to be used before a link is put in service. It is our understanding > > >> per G.806 section 6.1, when a TTP is not in service, it is in > > >> the NMON state (not monitored)." > > >> > > > > > > Many network elements take the availability of an input signal as a > > trigger to switch into monitoring mode. However, even for those which > do > > not, there does not seem to be a good reason for not using a > > common format. > I can think of a couple. The application space and usage are different. > > > > > > > >> > > >>>While the context for testing the transport plane > > >>>connectivity is different between the two documents, they > > >>>both use the Jx bytes of the server signal, and we invite > > >>>the IETF to determine the appropriateness of the above > > >>>aspects in their test signal definitions. > > >>> > > >>We agree the context is different. We evaluated the above > > aspects and > > >>we don't feel they are appropriate for LMP (see comments above). > > >> > > > > > > I'm still looking for the rationale that led you to this > > conclusion. I only see a statement. > Please see above. > > > > > >> > > >>>Even if these considerations are not relevant to this > > >>>context, it will be necessary to augment G.783 equipment > > >>>functions to recognize this new usage of Jx messages. > > >>> > > >>We would be happy to provide assistance to T1X1/ITU-T in augmenting > > >>G.783 equipment functions to recognize the additional capability for > > >>GMPLS networking elements. > > >> > > >> > > >>>Required Updates to SDH Equipment Specifications > > >>> > > >>>SDH equipment specifications as they currently exist reflect > > >>>the usage of the Jx bytes prior to the development of > > >>>G.7714.1. ITU-T Study Group 15 has as a work item to > > >>>revise these equipment functions to include support for > > >>>these new functions. Specifically, this will involve > > >>>updates to trail termination functions to generate and > > >>>receive the new messages and to avoid unnecessary alarms in > > >>>the case where the new messages are received. In addition, > > >>>non-intrusive monitoring functions will need to be revised > > >>>so that unnecessary alarms are not raised when the > > >>>messages are observed en-route. Whether or not there is > > >>>further alignment between the message formats used in > > >>>G.7714.1 and the subject draft, the new functions to > > >>>support the subject draft will also need to be reflected > > >>>in the atomic functions in G.783. The sending and > > >>>receiving of these messages can be reflected in the trail > > >>>termination functions in a similar way to what we plan to > > >>>do for support of G.7714.1 functions. > > >>> > > >> We understand that G7714.1 is addressing an in-service test > > >> procedure and needs to be concerned with NIM (and non-support of > G7714.1 > > >> by legacy NIM). The LMP test procedure is a pre-service > > >> application. We will be happy to work with T1X1/ITU SG15 to > > >> augment G.783 to recognize the additional capability for GMPLS > > >> networking elements. > > > > > > It seems to me that having yet another format to do the same > > thing, and which cannot be interleaved with normal tracing, is not an > additional > > capability, but less capability. > See above about doing "the same thing." As far as normal tracing goes, > see J0-trace mechanism in LMP Link Verification. It's my understanding > that G.7714.1 defines a new Jx format which will not work with existing > hardware and normal tracing. > > > > > >> > > >>>Terminology Differences > > >>> > > >> > > >> > > >>>Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, > > >>>the "up/free (in-service)" data link state appears to > > >>>correspond with what G.7714.1 refers to as "out-of- > > >>>service". This difference in terminology has resulted in > > >>>different interpretations of the context. Explaining the > > >>>scenarios further in the lmp test document would be > > >>>beneficial in establishing a translation between the > > >>>differing uses of the same terms. Within ITU-T, work is > > >>>being initiated of draft Rec. G.fame, Framework for ASON > > >>>Management, where control plane/management plane > > >>>interactions will be addressed. > > >>> > > >> We agree that terminology differences between IETF and ITU wrt > > >> GMPLS have been confusing. There is an ongoing effort within > > >> CCAMP to work together with ITU/T1X1 on bridging the terminology > > >> gaps. For example, there is a new Internet draft > > (draft-aboulmagd-ccamp-transport-lmp-00.txt) > > >> being considered in CCAMP to do this mapping for LMP. > > >> > > >>>Further Study Items > > >>> > > >>>Following are some areas where further contributions are > > >>>requested: > > >>>1. For SDH equipment functions in G.783, it needs to > > >>>be understood whether the application of the lmp test > > >>>message requires revision of NIM (non-intrusive > > >>>monitoring) functions. The reason for this is that the > > >>>test procedure is initiated between control entities at > > >>>the end-points of the trail, and intermediate points are > > >>>not necessarily aware that the test is taking place. For > > >>>G.7714.1, it was felt important for any termination or NIM > > >>>function to easily distinguish between the various uses of > > >>>the Jx bytes. It may be necessary for the subject draft > > >>>to use a similarly easily recognizable format. If no > > >>>revision to NIM functions is required for the context of > > >>>this draft, the architecture of the context for this > > >>>application (demonstrating why the NIM functions are not > > >>>required) should be reflected in G.803 and/or G.807/G.8080. > > >>> > > >> We understand that G7714.1 is addressing an in-service test > > >> procedure and needs to be concerned with NIM (and non-support of > G7714.1 > > >> by legacy NIM). The LMP test procedure is a pre-service > > >> application. Can you clarify how "pre-service" > > >> applications impact G.803/G.807/G.8080? If we > > >> can provide assistance in updating these Recommendations to > > >> reflect LMP applications, please let us know. > > >> > > >> G.803/G.807/G.8080? If we can provide assistance in updating > > >> these Recommendations to reflect LMP applications, please let us > > >> know. > > >> > > >>>2.Determination of whether it would be possible to use the > > >>>identical message formats in the subject draft as in > > >>>G.7714.1 for the connectivity verification function. > > >>> > > >>We have evaluated the current formats in G.7714.1 and we believe are > > >>inappropriate for the usage of LMP. > > >> > > > > > > Some rationale for this belief would be most useful. > See above. > > > > > > > >> > > >>>3.Determination of whether it would be possible to use the > > >>>same overall structure (distinguishing character, 4 bit > > >>>message type, 80 bit message body) if a different message > > >>>format or information content is required. > > >>> > > >>As mentioned above, we believe the overall message structure and > > >>constraints are inappropriate for LMP. > > >> > > > > > > I don't see answers to the above questions re technical feasibility, > and > > belief is not a reason for not using the same format in the interests > of > > reducing variation. > See above. > > > > > >> > > >>>4.Work is needed to clarify under what > > >>>configurations/states (for example: no VC-n signals > > >>>carrying client traffic) the lmp test message is > > >>>applicable over J0. If the signal can be framed and J0 > > >>>can be recovered, the Regenerator Section is considered > > >>>as "in service" from a transport plane perspective. So > > >>>unlike the J1/J2 case, the application of the lmp test > > >>>message at the Regenerator Section does not occur in an > > >>>"out of service" state (from a transport plane > > >>>perspective). > > >>> > > >> Section 6.1 of G.806 refers to a "termination function part of a > > >> trail, which is in the process of set-up" as in the NMON state. > > >> LMP link verification is based on pre-service testing. Please let > > >> us know if we can be of any assistance in updating the > > >> appropriate Recommendations to support the GMPLS network element > > >> LMP capability. > > >> > > >> > > >>>5. Clarification of the usage of transport and control > > >>>names for transport resources in the subject draft, as > > >>>described in G.8080 Amendment > > >>> > > >>LMP defines a TRACE object when a separation between data > > and control > > >>plane name space is requested. > > >> > > > > > > I'm afraid that I don't understand this answer. > Please look at Section 3.1 and Section 4 of > draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt. > > > > > > > >> > > >>>6. Consideration of the ANSI 64-byte J1. > > >>> > > >>This was mistakenly deleted from the latest version of the > > draft. This > > >>will be included in the next version. > > >> > > > > > > > > Hopefully, this will not create yet another format. > Nope. Since the byte limitation isn't as severe, it will follow the > nomal LMP Test message format without any additional formats. See > draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt (previous version of the > draft) for the text. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Apr 2003 15:12:52 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3706F14240@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'Razdan, Rajender'" , "'Jonathan.Lang@RinconNetworks.com'" , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, "'Deborah Brungard (E-mail)'" , "'Steve Trowbridge (E-mail)'" Cc: Kireeti@juniper.net, "'Ron Bonica (E-mail)'" , zinin@psg.com, Dimitri.Papadimitriou@alcatel.be Subject: RE: Proposed response to the T1X1 Liaison Statement on LMP Link V erification Date: Tue, 22 Apr 2003 11:11:03 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C308E1.63E1CE74" 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_01C308E1.63E1CE74 Content-Type: text/plain; charset="iso-8859-1" Hi, Given both approaches are checking for connectivity in the transport network using Jx bytes, it also seems odd to me that we would choose to use different formats according to when in the life cycle of the application this function occurs. I'd also like to note that G.7714.1 usage of Jx bytes for link connection endpoint discovery and connectivity verification is termed "in-service" because it is possible to perform the test in service; however, there is nothing that precludes their usage in an out-of-service application. Best regards, Eve -----Original Message----- From: Razdan, Rajender [mailto:RRazdan@ciena.com] Sent: Tuesday, April 22, 2003 10:38 AM To: 'Jonathan.Lang@RinconNetworks.com'; 'Wijnen, Bert (Bert)'; ccamp@ops.ietf.org; 'Deborah Brungard (E-mail)'; 'Steve Trowbridge (E-mail)' Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; Dimitri.Papadimitriou@alcatel.be Subject: RE: Proposed response to the T1X1 Liaison Statement on LMP Link V erification Jonathan, Thanks for changing the subject heading to reflect the correct liaison (I had blindly used the "reply all" feature in responding to the original mail from Bert). My point about the context being the same for G.7714.1 and the LMP Link verification is that both are essentially checking for connectivity between two points in a transport network, and both are using the same mechanism to do so, i.e. Jx trace bytes. I understand your point that this message is being used only in the context of GMPLS networks and that the planned usage is for out-of-service. While it is no doubt possible to have multiple "discovery" formats, the question is.. is it desirable to do so? As I said earlier, it seems that common sense would dictate that we try to align the various formats, if we can. Not only does the LMP test message format not match with G.7714.1, but it also does not match the LMP Bootstrap format. It seems to me to be a very simple matter to get all the three documents aligned; and one that would save both vendors and carrriers from the hassle of having to support multiple different formats even if they be for 'presumably' different applications. Regards, Rajender -----Original Message----- From: Jonathan Lang [ mailto:Jonathan.Lang@RinconNetworks.com ] Sent: Tuesday, April 22, 2003 12:27 AM To: Razdan, Rajender; 'Wijnen, Bert (Bert)'; ccamp@ops.ietf.org; 'Deborah Brungard (E-mail)'; 'Steve Trowbridge (E-mail)' Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; Dimitri.Papadimitriou@alcatel.be Subject: RE: Proposed response to the T1X1 Liaison Statement on LMP Link Verification Rajender, Please see inline for comment. (Note: I changed the subject header to reflect the correct liason.) -----Original Message----- From: Razdan, Rajender [ mailto:RRazdan@ciena.com ] Rajender, >Sent: Monday, April 21, 2003 8:35 AM >To: 'Wijnen, Bert (Bert)'; ccamp@ops.ietf.org; Deborah Brungard (E-mail); Steve >Trowbridge (E-mail) >Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; >Dimitri.Papadimitriou@alcatel.be; Jonathan.Lang@RinconNetworks.com >Subject: RE: Proposed response to the Liaison Statement on ASON Routing > > >I, for one, find the response very unsatisfactory. The T1X1, in >their liaison statement, put in a lot of effort in explaining >the rationale behind the discovery message format as specified >in G.7714.1. The response to this liaison, while acknowledging >that the context for the LMP test message and the G.7714.1 >discovery message are the same, Where in proposed response did we acknowledge the context is the same for g7714.1 and lmp? The intention of the response was to agree the "application space" and "scenario of use" are different from those described in the t1x1 liaison. Thanks, Jonathan >perfunctorily dismisses the >need for alignment between the two documents (ITU Rec. G.7714.1 >and the LMP test draft). I would have thought that it is common >sense to avoid having multiple formats for essentially the same >application if that can be avoided. After all, it doesn't serve >either the vendor community or the carriers to have to support >multiple 'discovery' formats. I find it intriguing that while >the LMP bootstrap draft has made attempts to align itself with >G.7714.1 message format, that there should be so much resistance >to doing the same with the LMP test draft document. It would be >useful if the authors of the LMP test draft explain why there >is such reluctance on their parts to align the LMP test message >to match Rec. G.7714.1? >regards, >Rajender Razdan >>-----Original Message----- >>From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] >>Sent: Saturday, April 19, 2003 11:53 AM >>To: ccamp@ops.ietf.org; Deborah Brungard (E-mail); Steve Trowbridge >>(E-mail) >>Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; >>bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be; >>Jonathan.Lang@RinconNetworks.com >>Subject: RE: Proposed response to the Liaison Statement on ASON Routing >> >> >>Thnaks for the proposed response. >>It would be good if people could tell us if they agree or disagree >>and if they disagree, then pls explain why. >>If the response is acceptable, then it sounds to me that at least >>there would be no impact on the draft-ietf-ccamp-lmp-08.txt >>document, which is currently in IETF Last Call. Since we had split >>the SONET/SDH material off into a separate document, my initial >>evaluation made me think that the draft-ietf-ccamp-lmp-08.txt >>would not have any ITU-T/T1X1 issues/concerns. The liason statement >>did refer to it a few times and so I started to worry, but from >>the (proposed) response it seems there is no isseu. >>Would be good to get at least confimration of that by the end >>of the Last Call, and that is April 24th. >>Thanks, >>Bert >>> -----Original Message----- >>> From: Jonathan Lang [ mailto:Jonathan.Lang@RinconNetworks.com ] >>> Sent: vrijdag 18 april 2003 22:25 >>> To: ccamp@ops.ietf.org >>> Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; >>> bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be >>> Subject: FW: Proposed response to the Liaison Statement on >>> ASON Routing >>> >>> >>> All, >>> >>> Here's a proposed response to the Liaison Statement from T1-X1 on LMP >>> Link Verification, posted April 11, 2003. >>> >>> Thanks, >>> Jonathan & Dimitri >>> -------------------------------------------------------------------- >>> Dear Mr. Biholar, >>> >>> >>> >Context of Application Space >>> >>> >It is currently our understanding that the use case >>> >scenario for which this procedure is applied encompasses >>> >both transport plane connectivity verification as well as >>> >correlation of these entities with the control plane. >>> >ITU-T G.7714.1 is focused on discovering the transport >>> >plane link connection end point relationships and >>> >verifying their connectivity. >>> >This Recommendation defines two procedures for performing >>> >the connectivity verification function, one of which >>> >utilizes either the Jx or the DCC bytes of the server >>> >signal (termed "in-service"). The other approach in >>> >G.7714.1, termed as "out of service", corresponds to >>> >inserting a test signal in the payload of the server >>> >signal. Based on an analysis of the data link state >>> >definitions in draft-ietf-ccamp-lmp-08.txt, we understand >>> >that the approach defined in the LMP test for physical >>> >connectivity occurs in the context of the "out of service" >>> >state (as described in G.7714.1). >>> > >>> >Please confirm this. >>> Yes, this is correct >>> >>> >Usage of Jx Bytes >>> > >>> >In defining the Jx bytes within G.7714.1, the following >>> >was taken into account: >>> >1. One consideration involved the case where the Discovery >>> >Agent is located in an external system, and an external >>> >interface is used by the Network Element to provision and >>> >receive the Trail Trace message. As an existing text- >>> >oriented Man-Machine Language, such as TL1, may be reused >>> >to provide this interface, it was decided that the >>> >discovery message be limited to printable characters. >>> >Specifically, the TTI characters should be limited to >>> >printable characters as per T.50 with trailing NULLs or >>> >SPACEs. Use of arbitrary bit patterns in the lower 7 bits >>> >of each byte could prematurely terminate the pattern or >>> >trigger fault notification for certain hardware or >>> >software implementations. The strategy chosen in G.7714.1 >>> >avoids the danger by limiting the information content of >>> >each byte to 6 bits (84 bits total) and uses a base 64 >>> >coding according to RFC2045 to place the information in >>> >the available bits. >>> We understand that a general transport plane discovery agent >>> application >>> such as G.7714.1 may want to limit the format to printable characters. >>> However, LMP is a subset of the GMPLS control plane where no such >>> constraint exists. As such, we don't think LMP link >>> verification needs >>> to be constrained to be printable characters. >>> >>> >2. Another consideration involved providing a means for >>> >distinguishing this use of the Jx bytes from the >>> >traditional use for Trail Trace identifiers in new >>> >equipments. As a result, G.7714.1 includes a >>> >distinguishing character ("+") as the first non-CRC byte >>> >that will never appear as the first character of a TTI. >>> >This requires modification of the trail termination >>> >functions to prevent the raising of TTI mismatch >>> >alarms during the connectivity verification process. >>> We understand the need for this distinguishing character for >>> the G7714.1 >>> in-service application; however, LMP link verification is >>> designed to be >>> used before a link is put in service. It is our >>> understanding per G.806 >>> section 6.1, when a TTP is not in service, it is in the NMON >>> state (not >>> monitored)." >>> >>> >While the context for testing the transport plane >>> >connectivity is different between the two documents, they >>> >both use the Jx bytes of the server signal, and we invite >>> >the IETF to determine the appropriateness of the above >>> >aspects in their test signal definitions. >>> We agree the context is different. We evaluated the above aspects and >>> we don't feel they are appropriate for LMP (see comments above). >>> >>> >Even if these considerations are not relevant to this >>> >context, it will be necessary to augment G.783 equipment >>> >functions to recognize this new usage of Jx messages. >>> We would be happy to provide assistance to T1X1/ITU-T in augmenting >>> G.783 equipment functions to recognize the additional capability for >>> GMPLS networking elements. >>> >>> >Required Updates to SDH Equipment Specifications >>> > >>> >SDH equipment specifications as they currently exist reflect >>> >the usage of the Jx bytes prior to the development of >>> >G.7714.1. ITU-T Study Group 15 has as a work item to >>> >revise these equipment functions to include support for >>> >these new functions. Specifically, this will involve >>> >updates to trail termination functions to generate and >>> >receive the new messages and to avoid unnecessary alarms in >>> >the case where the new messages are received. In addition, >>> >non-intrusive monitoring functions will need to be revised >>> >so that unnecessary alarms are not raised when the >>> >messages are observed en-route. Whether or not there is >>> >further alignment between the message formats used in >>> >G.7714.1 and the subject draft, the new functions to >>> >support the subject draft will also need to be reflected >>> >in the atomic functions in G.783. The sending and >>> >receiving of these messages can be reflected in the trail >>> >termination functions in a similar way to what we plan to >>> >do for support of G.7714.1 functions. >>> We understand that G7714.1 is addressing an in-service test procedure >>> and needs to be concerned with NIM (and non-support of >>> G7714.1 by legacy >>> NIM). The LMP test procedure is a pre-service application. >>> We will be >>> happy to work with T1X1/ITU SG15 to augment G.783 to recognize the >>> additional capability for GMPLS networking elements. >>> >>> >Terminology Differences >>> >>> >Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, >>> >the "up/free (in-service)" data link state appears to >>> >correspond with what G.7714.1 refers to as "out-of- >>> >service". This difference in terminology has resulted in >>> >different interpretations of the context. Explaining the >>> >scenarios further in the lmp test document would be >>> >beneficial in establishing a translation between the >>> >differing uses of the same terms. Within ITU-T, work is >>> >being initiated of draft Rec. G.fame, Framework for ASON >>> >Management, where control plane/management plane >>> >interactions will be addressed. >>> We agree that terminology differences between IETF and ITU wrt GMPLS >>> have been confusing. There is an ongoing effort within CCAMP to work >>> together with ITU/T1X1 on bridging the terminology gaps. For example, >>> there is a new Internet draft >>> (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in CCAMP >>> to do this mapping for LMP. >>> >>> >Further Study Items >>> > >>> >Following are some areas where further contributions are >>> >requested: >>> >1. For SDH equipment functions in G.783, it needs to >>> >be understood whether the application of the lmp test >>> >message requires revision of NIM (non-intrusive >>> >monitoring) functions. The reason for this is that the >>> >test procedure is initiated between control entities at >>> >the end-points of the trail, and intermediate points are >>> >not necessarily aware that the test is taking place. For >>> >G.7714.1, it was felt important for any termination or NIM >>> >function to easily distinguish between the various uses of >>> >the Jx bytes. It may be necessary for the subject draft >>> >to use a similarly easily recognizable format. If no >>> >revision to NIM functions is required for the context of >>> >this draft, the architecture of the context for this >>> >application (demonstrating why the NIM functions are not >>> >required) should be reflected in G.803 and/or G.807/G.8080. >>> We understand that G7714.1 is addressing an in-service test procedure >>> and needs to be concerned with NIM (and non-support of >>> G7714.1 by legacy >>> NIM). The LMP test procedure is a pre-service application. Can you >>> clarify how "pre-service" applications impact >>> G.803/G.807/G.8080? If we >>> can provide assistance in updating these Recommendations to >>> reflect LMP >>> applications, please let us know. >>> >>> >2.Determination of whether it would be possible to use the >>> >identical message formats in the subject draft as in >>> >G.7714.1 for the connectivity verification function. >>> We have evaluated the current formats in G.7714.1 and we believe are >>> inappropriate for the usage of LMP. >>> >>> >3.Determination of whether it would be possible to use the >>> >same overall structure (distinguishing character, 4 bit >>> >message type, 80 bit message body) if a different message >>> >format or information content is required. >>> As mentioned above, we believe the overall message structure and >>> constraints >>> are inappropriate for LMP. >>> >>> >4.Work is needed to clarify under what >>> >configurations/states (for example: no VC-n signals >>> >carrying client traffic) the lmp test message is >>> >applicable over J0. If the signal can be framed and J0 >>> >can be recovered, the Regenerator Section is considered >>> >as "in service" from a transport plane perspective. So >>> >unlike the J1/J2 case, the application of the lmp test >>> >message at the Regenerator Section does not occur in an >>> >"out of service" state (from a transport plane >>> >perspective). >>> Section 6.1 of G.806 refers to a "termination function part >>> of a trail, >>> which is in the process of set-up" as in the NMON state. LMP link >>> verification is based on pre-service testing. Please let us >>> know if we >>> can be of any assistance in updating the appropriate >>> Recommendations to >>> support the GMPLS network element LMP capability. >>> >>> >5. Clarification of the usage of transport and control >>> >names for transport resources in the subject draft, as >>> >described in G.8080 Amendment >>> LMP defines a TRACE object when a separation between data and control >>> plane name space is requested. >>> >>> >6. Consideration of the ANSI 64-byte J1. >>> This was mistakenly deleted from the latest version of the draft. This >>> will be included in the next version. >>> >>> ------_=_NextPart_001_01C308E1.63E1CE74 Content-Type: text/html; charset="iso-8859-1" RE: Proposed response to the T1X1 Liaison Statement on LMP Link Verification
Hi,
 
Given both approaches are checking for connectivity in the transport network using Jx bytes, it also seems odd to me
that we would choose to use different formats according to when in the life cycle of the application this function occurs.
 
I'd also like to note that G.7714.1 usage of Jx bytes for link connection endpoint discovery and connectivity verification is termed "in-service" because
it is possible to perform the test in service; however, there is nothing that precludes their usage in an out-of-service application. 
 
Best regards,
Eve
-----Original Message-----
From: Razdan, Rajender [mailto:RRazdan@ciena.com]
Sent: Tuesday, April 22, 2003 10:38 AM
To: 'Jonathan.Lang@RinconNetworks.com'; 'Wijnen, Bert (Bert)'; ccamp@ops.ietf.org; 'Deborah Brungard (E-mail)'; 'Steve Trowbridge (E-mail)'
Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; Dimitri.Papadimitriou@alcatel.be
Subject: RE: Proposed response to the T1X1 Liaison Statement on LMP Link V erification

Jonathan,

    Thanks for changing the subject heading to reflect the correct liaison
(I had blindly used the "reply all" feature in responding to the original
mail from Bert). My point about the context being the same for G.7714.1 and
the LMP Link verification is that both are essentially checking for
connectivity between two points in a transport network, and both are
using the same mechanism to do so, i.e. Jx trace bytes. I understand your
point that this message is being used only in the context of GMPLS networks
and that the planned usage is for out-of-service. While it is no doubt
possible to have multiple "discovery" formats, the question is.. is it
desirable to do so? As I said earlier, it seems that common sense would
dictate that we try to align the various formats, if we can. Not only
does the LMP test message format not match with G.7714.1, but it also does
not match the LMP Bootstrap format. It seems to me to be a very simple
matter to get all the three documents aligned; and one that would save
both vendors and carrriers from the hassle of having to support multiple
different formats even if they be for 'presumably' different applications.


Regards,
Rajender
 

-----Original Message-----
From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com]
Sent: Tuesday, April 22, 2003 12:27 AM
To: Razdan, Rajender; 'Wijnen, Bert (Bert)'; ccamp@ops.ietf.org;
'Deborah Brungard (E-mail)'; 'Steve Trowbridge (E-mail)'
Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com;
Dimitri.Papadimitriou@alcatel.be
Subject: RE: Proposed response to the T1X1 Liaison Statement on LMP Link
Verification


Rajender,
  Please see inline for comment.

  (Note: I changed the subject header to reflect the correct liason.)

-----Original Message-----
From: Razdan, Rajender [mailto:RRazdan@ciena.com]
Rajender,

>Sent: Monday, April 21, 2003 8:35 AM
>To: 'Wijnen, Bert (Bert)'; ccamp@ops.ietf.org; Deborah Brungard
(E-mail); Steve
>Trowbridge (E-mail)
>Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com;
>Dimitri.Papadimitriou@alcatel.be; Jonathan.Lang@RinconNetworks.com
>Subject: RE: Proposed response to the Liaison Statement on ASON Routing
>
>
>I, for one, find the response very unsatisfactory. The T1X1, in
>their liaison statement, put in a lot of effort in explaining
>the rationale behind the discovery message format as specified
>in G.7714.1. The response to this liaison, while acknowledging
>that the context for the LMP test message and the G.7714.1
>discovery message are the same,
Where in proposed response did we acknowledge the context is the same
for g7714.1 and lmp?  The intention of the response was to agree the
"application space" and "scenario of use" are different from those
described in the t1x1 liaison.

Thanks,
Jonathan

>perfunctorily dismisses the
>need for alignment between the two documents (ITU Rec. G.7714.1
>and the LMP test draft). I would have thought that it is common
>sense to avoid having multiple formats for essentially the same
>application if that can be avoided. After all, it doesn't serve
>either the vendor community or the carriers to have to support
>multiple 'discovery' formats. I find it intriguing that while
>the LMP bootstrap draft has made attempts to align itself with
>G.7714.1 message format, that there should be so much resistance
>to doing the same with the LMP test draft document. It would be
>useful if the authors of the LMP test draft explain why there
>is such reluctance on their parts to align the LMP test message
>to match Rec. G.7714.1?
>regards,
>Rajender Razdan
>>-----Original Message-----
>>From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
>>Sent: Saturday, April 19, 2003 11:53 AM
>>To: ccamp@ops.ietf.org; Deborah Brungard (E-mail); Steve Trowbridge
>>(E-mail)
>>Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com;
>>bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be;
>>Jonathan.Lang@RinconNetworks.com
>>Subject: RE: Proposed response to the Liaison Statement on ASON
Routing
>>
>>
>>Thnaks for the proposed response.
>>It would be good if people could tell us if they agree or disagree
>>and if they disagree, then pls explain why.
>>If the response is acceptable, then it sounds to me that at least
>>there would be no impact on the draft-ietf-ccamp-lmp-08.txt
>>document, which is currently in IETF Last Call. Since we had split
>>the SONET/SDH material off into a separate document, my initial
>>evaluation made me think that the draft-ietf-ccamp-lmp-08.txt
>>would not have any ITU-T/T1X1 issues/concerns. The liason statement
>>did refer to it a few times and so I started to worry, but from
>>the (proposed) response it seems there is no isseu.
>>Would be good to get at least confimration of that by the end
>>of the Last Call, and that is April 24th.
>>Thanks,
>>Bert
>>> -----Original Message-----
>>> From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com]
>>> Sent: vrijdag 18 april 2003 22:25
>>> To: ccamp@ops.ietf.org
>>> Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com;
>>> bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be
>>> Subject: FW: Proposed response to the Liaison Statement on
>>> ASON Routing
>>>
>>>
>>> All,
>>>
>>> Here's a proposed response to the Liaison Statement from T1-X1 on
LMP
>>> Link Verification, posted April 11, 2003.
>>>
>>> Thanks,
>>> Jonathan & Dimitri
>>> --------------------------------------------------------------------

>>> Dear Mr. Biholar,
>>>
>>>
>>> >Context of Application Space
>>> <snip>
>>> >It is currently our understanding that the use case
>>> >scenario for which this procedure is applied encompasses
>>> >both transport plane connectivity verification as well as
>>> >correlation of these entities with the control plane.
>>> >ITU-T G.7714.1 is focused on discovering the transport
>>> >plane link connection end point relationships and
>>> >verifying their connectivity.
>>> >This Recommendation defines two procedures for performing
>>> >the connectivity verification function, one of which
>>> >utilizes either the Jx or the DCC bytes of the server
>>> >signal (termed "in-service"). The other approach in
>>> >G.7714.1, termed as "out of service", corresponds to
>>> >inserting a test signal in the payload of the server
>>> >signal. Based on an analysis of the data link state
>>> >definitions in draft-ietf-ccamp-lmp-08.txt, we understand
>>> >that the approach defined in the LMP test for physical
>>> >connectivity occurs in the context of the "out of service"
>>> >state (as described in G.7714.1).
>>> >
>>> >Please confirm this.
>>> Yes, this is correct
>>>
>>> >Usage of Jx Bytes
>>> >
>>> >In defining the Jx bytes within G.7714.1, the following
>>> >was taken into account:
>>> >1. One consideration involved the case where the Discovery
>>> >Agent is located in an external system, and an external
>>> >interface is used by the Network Element to provision and
>>> >receive the Trail Trace message. As an existing text-
>>> >oriented Man-Machine Language, such as TL1, may be reused
>>> >to provide this interface, it was decided that the
>>> >discovery message be limited to printable characters.
>>> >Specifically, the TTI characters should be limited to
>>> >printable characters as per T.50 with trailing NULLs or
>>> >SPACEs. Use of arbitrary bit patterns in the lower 7 bits
>>> >of each byte could prematurely terminate the pattern or
>>> >trigger fault notification for certain hardware or
>>> >software implementations. The strategy chosen in G.7714.1
>>> >avoids the danger by limiting the information content of
>>> >each byte to 6 bits (84 bits total) and uses a base 64
>>> >coding according to RFC2045 to place the information in
>>> >the available bits.
>>> We understand that a general transport plane discovery agent
>>> application
>>> such as G.7714.1 may want to limit the format to printable
characters.
>>> However, LMP is a subset of the GMPLS control plane where no such
>>> constraint exists.  As such, we don't think LMP link
>>> verification needs
>>> to be constrained to be printable characters.
>>>
>>> >2. Another consideration involved providing a means for
>>> >distinguishing this use of the Jx bytes from the
>>> >traditional use for Trail Trace identifiers in new
>>> >equipments. As a result, G.7714.1 includes a
>>> >distinguishing character ("+") as the first non-CRC byte
>>> >that will never appear as the first character of a TTI.
>>> >This requires modification of the trail termination
>>> >functions to prevent the raising of TTI mismatch
>>> >alarms during the connectivity verification process.
>>> We understand the need for this distinguishing character for
>>> the G7714.1
>>> in-service application; however, LMP link verification is
>>> designed to be
>>> used before a link is put in service.  It is our
>>> understanding per G.806
>>> section 6.1, when a TTP is not in service, it is in the NMON
>>> state (not
>>> monitored)."
>>>
>>> >While the context for testing the transport plane
>>> >connectivity is different between the two documents, they
>>> >both use the Jx bytes of the server signal, and we invite
>>> >the IETF to determine the appropriateness of the above
>>> >aspects in their test signal definitions.
>>> We agree the context is different.  We evaluated the above aspects
and
>>> we don't feel they are appropriate for LMP (see comments above).
>>>
>>> >Even if these considerations are not relevant to this
>>> >context, it will be necessary to augment G.783 equipment
>>> >functions to recognize this new usage of Jx messages.
>>> We would be happy to provide assistance to T1X1/ITU-T in augmenting
>>> G.783 equipment functions to recognize the additional capability for

>>> GMPLS networking elements.
>>>
>>> >Required Updates to SDH Equipment Specifications
>>> >
>>> >SDH equipment specifications as they currently exist reflect
>>> >the usage of the Jx bytes prior to the development of
>>> >G.7714.1. ITU-T Study Group 15 has as a work item to
>>> >revise these equipment functions to include support for
>>> >these new functions. Specifically, this will involve
>>> >updates to trail termination functions to generate and
>>> >receive the new messages and to avoid unnecessary alarms in
>>> >the case where the new messages are received. In addition,
>>> >non-intrusive monitoring functions will need to be revised
>>> >so that unnecessary alarms are not raised when the
>>> >messages are observed en-route. Whether or not there is
>>> >further alignment between the message formats used in
>>> >G.7714.1 and the subject draft, the new functions to
>>> >support the subject draft will also need to be reflected
>>> >in the atomic functions in G.783. The sending and
>>> >receiving of these messages can be reflected in the trail
>>> >termination functions in a similar way to what we plan to
>>> >do for support of G.7714.1 functions.
>>> We understand that G7714.1 is addressing an in-service test
procedure
>>> and needs to be concerned with NIM (and non-support of
>>> G7714.1 by legacy
>>> NIM).  The LMP test procedure is a pre-service application.
>>> We will be
>>> happy to work with T1X1/ITU SG15 to augment G.783 to recognize the
>>> additional capability for GMPLS networking elements.
>>>
>>> >Terminology Differences
>>> <snip>
>>> >Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
>>> >the "up/free (in-service)" data link state appears to
>>> >correspond with what G.7714.1 refers to as "out-of-
>>> >service".  This difference in terminology has resulted in
>>> >different interpretations of the context.  Explaining the
>>> >scenarios further in the lmp test document would be
>>> >beneficial in establishing a translation between the
>>> >differing uses of the same terms.  Within ITU-T, work is
>>> >being initiated of draft Rec. G.fame, Framework for ASON
>>> >Management, where control plane/management plane
>>> >interactions will be addressed.
>>> We agree that terminology differences between IETF and ITU wrt GMPLS

>>> have been confusing.  There is an ongoing effort within CCAMP to
work
>>> together with ITU/T1X1 on bridging the terminology gaps. For
example,
>>> there is a new Internet draft
>>> (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in
CCAMP
>>> to do this mapping for LMP.
>>>
>>> >Further Study Items
>>> >
>>> >Following are some areas where further contributions are
>>> >requested:
>>> >1.   For SDH equipment functions in G.783, it needs to
>>> >be understood whether the application of the lmp test
>>> >message requires revision of NIM (non-intrusive
>>> >monitoring) functions. The reason for this is that the
>>> >test procedure is initiated between control entities at
>>> >the end-points of the trail, and intermediate points are
>>> >not necessarily aware that the test is taking place. For
>>> >G.7714.1, it was felt important for any termination or NIM
>>> >function to easily distinguish between the various uses of
>>> >the Jx bytes. It may be necessary for the subject draft
>>> >to use a similarly easily recognizable format. If no
>>> >revision to NIM functions is required for the context of
>>> >this draft, the architecture of the context for this
>>> >application (demonstrating why the NIM functions are not
>>> >required) should be reflected in G.803 and/or G.807/G.8080.
>>> We understand that G7714.1 is addressing an in-service test
procedure
>>> and needs to be concerned with NIM (and non-support of
>>> G7714.1 by legacy
>>> NIM).  The LMP test procedure is a pre-service application.  Can you

>>> clarify how "pre-service" applications impact
>>> G.803/G.807/G.8080?  If we
>>> can provide assistance in updating these Recommendations to
>>> reflect LMP
>>> applications, please let us know.
>>>
>>> >2.Determination of whether it would be possible to use the
>>> >identical message formats in the subject draft as in
>>> >G.7714.1 for the connectivity verification function.
>>> We have evaluated the current formats in G.7714.1 and we believe are

>>> inappropriate for the usage of LMP.
>>>
>>> >3.Determination of whether it would be possible to use the
>>> >same overall structure (distinguishing character, 4 bit
>>> >message type, 80 bit message body) if a different message
>>> >format or information content is required.
>>> As mentioned above, we believe the overall message structure and
>>> constraints
>>> are inappropriate for LMP.
>>>
>>> >4.Work is needed to clarify under what
>>> >configurations/states (for example: no VC-n signals
>>> >carrying client traffic) the lmp test message is
>>> >applicable over J0.  If the signal can be framed and J0
>>> >can be recovered, the Regenerator Section is considered
>>> >as "in service" from a transport plane perspective. So
>>> >unlike the J1/J2 case, the application of the lmp test
>>> >message at the Regenerator Section does not occur in an
>>> >"out of service" state (from a transport plane
>>> >perspective).
>>> Section 6.1 of G.806 refers to a "termination function part
>>> of a trail,
>>> which is in the process of set-up" as in the NMON state.  LMP link
>>> verification is based on pre-service testing.  Please let us
>>> know if we
>>> can be of any assistance in updating the appropriate
>>> Recommendations to
>>> support the GMPLS network element LMP capability.
>>>
>>> >5. Clarification of the usage of transport and control
>>> >names for transport resources in the subject draft, as
>>> >described in G.8080 Amendment
>>> LMP defines a TRACE object when a separation between data and
control
>>> plane name space is requested.
>>>
>>> >6. Consideration of the ANSI 64-byte J1.
>>> This was mistakenly deleted from the latest version of the draft.
This
>>> will be included in the next version.
>>>
>>>



------_=_NextPart_001_01C308E1.63E1CE74-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Apr 2003 14:40:24 +0000 Message-ID: <9A1A304A69213E4E9CC08614134C7F7C5357E6@w2k04exg02.ciena.com> From: "Razdan, Rajender" To: "'Jonathan.Lang@RinconNetworks.com'" , "'Wijnen, Bert (Bert)'" , ccamp@ops.ietf.org, "'Deborah Brungard (E-mail)'" , "'Steve Trowbridge (E-mail)'" Cc: Kireeti@juniper.net, "'Ron Bonica (E-mail)'" , zinin@psg.com, Dimitri.Papadimitriou@alcatel.be Subject: RE: Proposed response to the T1X1 Liaison Statement on LMP Link V erification Date: Tue, 22 Apr 2003 10:37:59 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C308DC.C5299590" 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_01C308DC.C5299590 Content-Type: text/plain; charset="iso-8859-1" Jonathan, Thanks for changing the subject heading to reflect the correct liaison (I had blindly used the "reply all" feature in responding to the original mail from Bert). My point about the context being the same for G.7714.1 and the LMP Link verification is that both are essentially checking for connectivity between two points in a transport network, and both are using the same mechanism to do so, i.e. Jx trace bytes. I understand your point that this message is being used only in the context of GMPLS networks and that the planned usage is for out-of-service. While it is no doubt possible to have multiple "discovery" formats, the question is.. is it desirable to do so? As I said earlier, it seems that common sense would dictate that we try to align the various formats, if we can. Not only does the LMP test message format not match with G.7714.1, but it also does not match the LMP Bootstrap format. It seems to me to be a very simple matter to get all the three documents aligned; and one that would save both vendors and carrriers from the hassle of having to support multiple different formats even if they be for 'presumably' different applications. Regards, Rajender -----Original Message----- From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com] Sent: Tuesday, April 22, 2003 12:27 AM To: Razdan, Rajender; 'Wijnen, Bert (Bert)'; ccamp@ops.ietf.org; 'Deborah Brungard (E-mail)'; 'Steve Trowbridge (E-mail)' Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; Dimitri.Papadimitriou@alcatel.be Subject: RE: Proposed response to the T1X1 Liaison Statement on LMP Link Verification Rajender, Please see inline for comment. (Note: I changed the subject header to reflect the correct liason.) -----Original Message----- From: Razdan, Rajender [mailto:RRazdan@ciena.com] Rajender, >Sent: Monday, April 21, 2003 8:35 AM >To: 'Wijnen, Bert (Bert)'; ccamp@ops.ietf.org; Deborah Brungard (E-mail); Steve >Trowbridge (E-mail) >Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; >Dimitri.Papadimitriou@alcatel.be; Jonathan.Lang@RinconNetworks.com >Subject: RE: Proposed response to the Liaison Statement on ASON Routing > > >I, for one, find the response very unsatisfactory. The T1X1, in >their liaison statement, put in a lot of effort in explaining >the rationale behind the discovery message format as specified >in G.7714.1. The response to this liaison, while acknowledging >that the context for the LMP test message and the G.7714.1 >discovery message are the same, Where in proposed response did we acknowledge the context is the same for g7714.1 and lmp? The intention of the response was to agree the "application space" and "scenario of use" are different from those described in the t1x1 liaison. Thanks, Jonathan >perfunctorily dismisses the >need for alignment between the two documents (ITU Rec. G.7714.1 >and the LMP test draft). I would have thought that it is common >sense to avoid having multiple formats for essentially the same >application if that can be avoided. After all, it doesn't serve >either the vendor community or the carriers to have to support >multiple 'discovery' formats. I find it intriguing that while >the LMP bootstrap draft has made attempts to align itself with >G.7714.1 message format, that there should be so much resistance >to doing the same with the LMP test draft document. It would be >useful if the authors of the LMP test draft explain why there >is such reluctance on their parts to align the LMP test message >to match Rec. G.7714.1? >regards, >Rajender Razdan >>-----Original Message----- >>From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >>Sent: Saturday, April 19, 2003 11:53 AM >>To: ccamp@ops.ietf.org; Deborah Brungard (E-mail); Steve Trowbridge >>(E-mail) >>Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; >>bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be; >>Jonathan.Lang@RinconNetworks.com >>Subject: RE: Proposed response to the Liaison Statement on ASON Routing >> >> >>Thnaks for the proposed response. >>It would be good if people could tell us if they agree or disagree >>and if they disagree, then pls explain why. >>If the response is acceptable, then it sounds to me that at least >>there would be no impact on the draft-ietf-ccamp-lmp-08.txt >>document, which is currently in IETF Last Call. Since we had split >>the SONET/SDH material off into a separate document, my initial >>evaluation made me think that the draft-ietf-ccamp-lmp-08.txt >>would not have any ITU-T/T1X1 issues/concerns. The liason statement >>did refer to it a few times and so I started to worry, but from >>the (proposed) response it seems there is no isseu. >>Would be good to get at least confimration of that by the end >>of the Last Call, and that is April 24th. >>Thanks, >>Bert >>> -----Original Message----- >>> From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com] >>> Sent: vrijdag 18 april 2003 22:25 >>> To: ccamp@ops.ietf.org >>> Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; >>> bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be >>> Subject: FW: Proposed response to the Liaison Statement on >>> ASON Routing >>> >>> >>> All, >>> >>> Here's a proposed response to the Liaison Statement from T1-X1 on LMP >>> Link Verification, posted April 11, 2003. >>> >>> Thanks, >>> Jonathan & Dimitri >>> -------------------------------------------------------------------- >>> Dear Mr. Biholar, >>> >>> >>> >Context of Application Space >>> >>> >It is currently our understanding that the use case >>> >scenario for which this procedure is applied encompasses >>> >both transport plane connectivity verification as well as >>> >correlation of these entities with the control plane. >>> >ITU-T G.7714.1 is focused on discovering the transport >>> >plane link connection end point relationships and >>> >verifying their connectivity. >>> >This Recommendation defines two procedures for performing >>> >the connectivity verification function, one of which >>> >utilizes either the Jx or the DCC bytes of the server >>> >signal (termed "in-service"). The other approach in >>> >G.7714.1, termed as "out of service", corresponds to >>> >inserting a test signal in the payload of the server >>> >signal. Based on an analysis of the data link state >>> >definitions in draft-ietf-ccamp-lmp-08.txt, we understand >>> >that the approach defined in the LMP test for physical >>> >connectivity occurs in the context of the "out of service" >>> >state (as described in G.7714.1). >>> > >>> >Please confirm this. >>> Yes, this is correct >>> >>> >Usage of Jx Bytes >>> > >>> >In defining the Jx bytes within G.7714.1, the following >>> >was taken into account: >>> >1. One consideration involved the case where the Discovery >>> >Agent is located in an external system, and an external >>> >interface is used by the Network Element to provision and >>> >receive the Trail Trace message. As an existing text- >>> >oriented Man-Machine Language, such as TL1, may be reused >>> >to provide this interface, it was decided that the >>> >discovery message be limited to printable characters. >>> >Specifically, the TTI characters should be limited to >>> >printable characters as per T.50 with trailing NULLs or >>> >SPACEs. Use of arbitrary bit patterns in the lower 7 bits >>> >of each byte could prematurely terminate the pattern or >>> >trigger fault notification for certain hardware or >>> >software implementations. The strategy chosen in G.7714.1 >>> >avoids the danger by limiting the information content of >>> >each byte to 6 bits (84 bits total) and uses a base 64 >>> >coding according to RFC2045 to place the information in >>> >the available bits. >>> We understand that a general transport plane discovery agent >>> application >>> such as G.7714.1 may want to limit the format to printable characters. >>> However, LMP is a subset of the GMPLS control plane where no such >>> constraint exists. As such, we don't think LMP link >>> verification needs >>> to be constrained to be printable characters. >>> >>> >2. Another consideration involved providing a means for >>> >distinguishing this use of the Jx bytes from the >>> >traditional use for Trail Trace identifiers in new >>> >equipments. As a result, G.7714.1 includes a >>> >distinguishing character ("+") as the first non-CRC byte >>> >that will never appear as the first character of a TTI. >>> >This requires modification of the trail termination >>> >functions to prevent the raising of TTI mismatch >>> >alarms during the connectivity verification process. >>> We understand the need for this distinguishing character for >>> the G7714.1 >>> in-service application; however, LMP link verification is >>> designed to be >>> used before a link is put in service. It is our >>> understanding per G.806 >>> section 6.1, when a TTP is not in service, it is in the NMON >>> state (not >>> monitored)." >>> >>> >While the context for testing the transport plane >>> >connectivity is different between the two documents, they >>> >both use the Jx bytes of the server signal, and we invite >>> >the IETF to determine the appropriateness of the above >>> >aspects in their test signal definitions. >>> We agree the context is different. We evaluated the above aspects and >>> we don't feel they are appropriate for LMP (see comments above). >>> >>> >Even if these considerations are not relevant to this >>> >context, it will be necessary to augment G.783 equipment >>> >functions to recognize this new usage of Jx messages. >>> We would be happy to provide assistance to T1X1/ITU-T in augmenting >>> G.783 equipment functions to recognize the additional capability for >>> GMPLS networking elements. >>> >>> >Required Updates to SDH Equipment Specifications >>> > >>> >SDH equipment specifications as they currently exist reflect >>> >the usage of the Jx bytes prior to the development of >>> >G.7714.1. ITU-T Study Group 15 has as a work item to >>> >revise these equipment functions to include support for >>> >these new functions. Specifically, this will involve >>> >updates to trail termination functions to generate and >>> >receive the new messages and to avoid unnecessary alarms in >>> >the case where the new messages are received. In addition, >>> >non-intrusive monitoring functions will need to be revised >>> >so that unnecessary alarms are not raised when the >>> >messages are observed en-route. Whether or not there is >>> >further alignment between the message formats used in >>> >G.7714.1 and the subject draft, the new functions to >>> >support the subject draft will also need to be reflected >>> >in the atomic functions in G.783. The sending and >>> >receiving of these messages can be reflected in the trail >>> >termination functions in a similar way to what we plan to >>> >do for support of G.7714.1 functions. >>> We understand that G7714.1 is addressing an in-service test procedure >>> and needs to be concerned with NIM (and non-support of >>> G7714.1 by legacy >>> NIM). The LMP test procedure is a pre-service application. >>> We will be >>> happy to work with T1X1/ITU SG15 to augment G.783 to recognize the >>> additional capability for GMPLS networking elements. >>> >>> >Terminology Differences >>> >>> >Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, >>> >the "up/free (in-service)" data link state appears to >>> >correspond with what G.7714.1 refers to as "out-of- >>> >service". This difference in terminology has resulted in >>> >different interpretations of the context. Explaining the >>> >scenarios further in the lmp test document would be >>> >beneficial in establishing a translation between the >>> >differing uses of the same terms. Within ITU-T, work is >>> >being initiated of draft Rec. G.fame, Framework for ASON >>> >Management, where control plane/management plane >>> >interactions will be addressed. >>> We agree that terminology differences between IETF and ITU wrt GMPLS >>> have been confusing. There is an ongoing effort within CCAMP to work >>> together with ITU/T1X1 on bridging the terminology gaps. For example, >>> there is a new Internet draft >>> (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in CCAMP >>> to do this mapping for LMP. >>> >>> >Further Study Items >>> > >>> >Following are some areas where further contributions are >>> >requested: >>> >1. For SDH equipment functions in G.783, it needs to >>> >be understood whether the application of the lmp test >>> >message requires revision of NIM (non-intrusive >>> >monitoring) functions. The reason for this is that the >>> >test procedure is initiated between control entities at >>> >the end-points of the trail, and intermediate points are >>> >not necessarily aware that the test is taking place. For >>> >G.7714.1, it was felt important for any termination or NIM >>> >function to easily distinguish between the various uses of >>> >the Jx bytes. It may be necessary for the subject draft >>> >to use a similarly easily recognizable format. If no >>> >revision to NIM functions is required for the context of >>> >this draft, the architecture of the context for this >>> >application (demonstrating why the NIM functions are not >>> >required) should be reflected in G.803 and/or G.807/G.8080. >>> We understand that G7714.1 is addressing an in-service test procedure >>> and needs to be concerned with NIM (and non-support of >>> G7714.1 by legacy >>> NIM). The LMP test procedure is a pre-service application. Can you >>> clarify how "pre-service" applications impact >>> G.803/G.807/G.8080? If we >>> can provide assistance in updating these Recommendations to >>> reflect LMP >>> applications, please let us know. >>> >>> >2.Determination of whether it would be possible to use the >>> >identical message formats in the subject draft as in >>> >G.7714.1 for the connectivity verification function. >>> We have evaluated the current formats in G.7714.1 and we believe are >>> inappropriate for the usage of LMP. >>> >>> >3.Determination of whether it would be possible to use the >>> >same overall structure (distinguishing character, 4 bit >>> >message type, 80 bit message body) if a different message >>> >format or information content is required. >>> As mentioned above, we believe the overall message structure and >>> constraints >>> are inappropriate for LMP. >>> >>> >4.Work is needed to clarify under what >>> >configurations/states (for example: no VC-n signals >>> >carrying client traffic) the lmp test message is >>> >applicable over J0. If the signal can be framed and J0 >>> >can be recovered, the Regenerator Section is considered >>> >as "in service" from a transport plane perspective. So >>> >unlike the J1/J2 case, the application of the lmp test >>> >message at the Regenerator Section does not occur in an >>> >"out of service" state (from a transport plane >>> >perspective). >>> Section 6.1 of G.806 refers to a "termination function part >>> of a trail, >>> which is in the process of set-up" as in the NMON state. LMP link >>> verification is based on pre-service testing. Please let us >>> know if we >>> can be of any assistance in updating the appropriate >>> Recommendations to >>> support the GMPLS network element LMP capability. >>> >>> >5. Clarification of the usage of transport and control >>> >names for transport resources in the subject draft, as >>> >described in G.8080 Amendment >>> LMP defines a TRACE object when a separation between data and control >>> plane name space is requested. >>> >>> >6. Consideration of the ANSI 64-byte J1. >>> This was mistakenly deleted from the latest version of the draft. This >>> will be included in the next version. >>> >>> ------_=_NextPart_001_01C308DC.C5299590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Proposed response to the T1X1 Liaison Statement on LMP Link = Verification

Jonathan,

    Thanks for changing the subject = heading to reflect the correct liaison
(I had blindly used the "reply all" = feature in responding to the original
mail from Bert). My point about the context being = the same for G.7714.1 and
the LMP Link verification is that both are = essentially checking for
connectivity between two points in a transport = network, and both are
using the same mechanism to do so, i.e. Jx trace = bytes. I understand your
point that this message is being used only in the = context of GMPLS networks
and that the planned usage is for out-of-service. = While it is no doubt
possible to have multiple "discovery" = formats, the question is.. is it
desirable to do so? As I said earlier, it seems that = common sense would
dictate that we try to align the various formats, if = we can. Not only
does the LMP test message format not match with = G.7714.1, but it also does
not match the LMP Bootstrap format. It seems to me = to be a very simple
matter to get all the three documents aligned; and = one that would save
both vendors and carrriers from the hassle of having = to support multiple
different formats even if they be for 'presumably' = different applications.


Regards,
Rajender
 

-----Original Message-----
From: Jonathan Lang [mailto:Jonathan.Lang@Ri= nconNetworks.com]
Sent: Tuesday, April 22, 2003 12:27 AM
To: Razdan, Rajender; 'Wijnen, Bert (Bert)'; = ccamp@ops.ietf.org;
'Deborah Brungard (E-mail)'; 'Steve Trowbridge = (E-mail)'
Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; = zinin@psg.com;
Dimitri.Papadimitriou@alcatel.be
Subject: RE: Proposed response to the T1X1 Liaison = Statement on LMP Link
Verification


Rajender,
  Please see inline for comment.

  (Note: I changed the subject header to reflect = the correct liason.)

-----Original Message-----
From: Razdan, Rajender [mailto:RRazdan@ciena.com]
Rajender,

>Sent: Monday, April 21, 2003 8:35 AM
>To: 'Wijnen, Bert (Bert)'; ccamp@ops.ietf.org; = Deborah Brungard
(E-mail); Steve
>Trowbridge (E-mail)
>Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; = zinin@psg.com;
>Dimitri.Papadimitriou@alcatel.be; = Jonathan.Lang@RinconNetworks.com
>Subject: RE: Proposed response to the Liaison = Statement on ASON Routing
>
>
>I, for one, find the response very = unsatisfactory. The T1X1, in
>their liaison statement, put in a lot of effort = in explaining
>the rationale behind the discovery message = format as specified
>in G.7714.1. The response to this liaison, while = acknowledging
>that the context for the LMP test message and = the G.7714.1
>discovery message are the same,
Where in proposed response did we acknowledge the = context is the same
for g7714.1 and lmp?  The intention of the = response was to agree the
"application space" and "scenario of = use" are different from those
described in the t1x1 liaison.

Thanks,
Jonathan

>perfunctorily dismisses the
>need for alignment between the two documents = (ITU Rec. G.7714.1
>and the LMP test draft). I would have thought = that it is common
>sense to avoid having multiple formats for = essentially the same
>application if that can be avoided. After all, = it doesn't serve
>either the vendor community or the carriers to = have to support
>multiple 'discovery' formats. I find it = intriguing that while
>the LMP bootstrap draft has made attempts to = align itself with
>G.7714.1 message format, that there should be so = much resistance
>to doing the same with the LMP test draft = document. It would be
>useful if the authors of the LMP test draft = explain why there
>is such reluctance on their parts to align the = LMP test message
>to match Rec. G.7714.1?
>regards,
>Rajender Razdan
>>-----Original Message-----
>>From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
>>Sent: Saturday, April 19, 2003 11:53 = AM
>>To: ccamp@ops.ietf.org; Deborah Brungard = (E-mail); Steve Trowbridge
>>(E-mail)
>>Cc: Kireeti@juniper.net; 'Ron Bonica = (E-mail)'; zinin@psg.com;
>>bwijnen@lucent.com; = Dimitri.Papadimitriou@alcatel.be;
>>Jonathan.Lang@RinconNetworks.com
>>Subject: RE: Proposed response to the = Liaison Statement on ASON
Routing
>>
>>
>>Thnaks for the proposed response.
>>It would be good if people could tell us if = they agree or disagree
>>and if they disagree, then pls explain = why.
>>If the response is acceptable, then it = sounds to me that at least
>>there would be no impact on the = draft-ietf-ccamp-lmp-08.txt
>>document, which is currently in IETF Last = Call. Since we had split
>>the SONET/SDH material off into a separate = document, my initial
>>evaluation made me think that the = draft-ietf-ccamp-lmp-08.txt
>>would not have any ITU-T/T1X1 = issues/concerns. The liason statement
>>did refer to it a few times and so I started = to worry, but from
>>the (proposed) response it seems there is no = isseu.
>>Would be good to get at least confimration = of that by the end
>>of the Last Call, and that is April = 24th.
>>Thanks,
>>Bert
>>> -----Original Message-----
>>> From: Jonathan Lang [mailto:Jonathan.Lang@Ri= nconNetworks.com]
>>> Sent: vrijdag 18 april 2003 = 22:25
>>> To: ccamp@ops.ietf.org
>>> Cc: Kireeti@juniper.net; 'Ron Bonica = (E-mail)'; zinin@psg.com;
>>> bwijnen@lucent.com; = Dimitri.Papadimitriou@alcatel.be
>>> Subject: FW: Proposed response to the = Liaison Statement on
>>> ASON Routing
>>>
>>>
>>> All,
>>>
>>> Here's a proposed response to the = Liaison Statement from T1-X1 on
LMP
>>> Link Verification, posted April 11, = 2003.
>>>
>>> Thanks,
>>> Jonathan & Dimitri
>>> = --------------------------------------------------------------------

>>> Dear Mr. Biholar,
>>>
>>>
>>> >Context of Application Space
>>> <snip>
>>> >It is currently our understanding = that the use case
>>> >scenario for which this procedure = is applied encompasses
>>> >both transport plane connectivity = verification as well as
>>> >correlation of these entities with = the control plane.
>>> >ITU-T G.7714.1 is focused on = discovering the transport
>>> >plane link connection end point = relationships and
>>> >verifying their = connectivity.
>>> >This Recommendation defines two = procedures for performing
>>> >the connectivity verification = function, one of which
>>> >utilizes either the Jx or the DCC = bytes of the server
>>> >signal (termed = "in-service"). The other approach in
>>> >G.7714.1, termed as "out of = service", corresponds to
>>> >inserting a test signal in the = payload of the server
>>> >signal. Based on an analysis of the = data link state
>>> >definitions in = draft-ietf-ccamp-lmp-08.txt, we understand
>>> >that the approach defined in the = LMP test for physical
>>> >connectivity occurs in the context = of the "out of service"
>>> >state (as described in = G.7714.1).
>>> >
>>> >Please confirm this.
>>> Yes, this is correct
>>>
>>> >Usage of Jx Bytes
>>> >
>>> >In defining the Jx bytes within = G.7714.1, the following
>>> >was taken into account:
>>> >1. One consideration involved the = case where the Discovery
>>> >Agent is located in an external = system, and an external
>>> >interface is used by the Network = Element to provision and
>>> >receive the Trail Trace message. As = an existing text-
>>> >oriented Man-Machine Language, such = as TL1, may be reused
>>> >to provide this interface, it was = decided that the
>>> >discovery message be limited to = printable characters.
>>> >Specifically, the TTI characters = should be limited to
>>> >printable characters as per T.50 = with trailing NULLs or
>>> >SPACEs. Use of arbitrary bit = patterns in the lower 7 bits
>>> >of each byte could prematurely = terminate the pattern or
>>> >trigger fault notification for = certain hardware or
>>> >software implementations. The = strategy chosen in G.7714.1
>>> >avoids the danger by limiting the = information content of
>>> >each byte to 6 bits (84 bits total) = and uses a base 64
>>> >coding according to RFC2045 to = place the information in
>>> >the available bits.
>>> We understand that a general transport = plane discovery agent
>>> application
>>> such as G.7714.1 may want to limit the = format to printable
characters.
>>> However, LMP is a subset of the GMPLS = control plane where no such
>>> constraint exists.  As such, we = don't think LMP link
>>> verification needs
>>> to be constrained to be printable = characters.
>>>
>>> >2. Another consideration involved = providing a means for
>>> >distinguishing this use of the Jx = bytes from the
>>> >traditional use for Trail Trace = identifiers in new
>>> >equipments. As a result, G.7714.1 = includes a
>>> >distinguishing character = ("+") as the first non-CRC byte
>>> >that will never appear as the first = character of a TTI.
>>> >This requires modification of the = trail termination
>>> >functions to prevent the raising of = TTI mismatch
>>> >alarms during the connectivity = verification process.
>>> We understand the need for this = distinguishing character for
>>> the G7714.1
>>> in-service application; however, LMP = link verification is
>>> designed to be
>>> used before a link is put in = service.  It is our
>>> understanding per G.806
>>> section 6.1, when a TTP is not in = service, it is in the NMON
>>> state (not
>>> monitored)."
>>>
>>> >While the context for testing the = transport plane
>>> >connectivity is different between = the two documents, they
>>> >both use the Jx bytes of the server = signal, and we invite
>>> >the IETF to determine the = appropriateness of the above
>>> >aspects in their test signal = definitions.
>>> We agree the context is = different.  We evaluated the above aspects
and
>>> we don't feel they are appropriate for = LMP (see comments above).
>>>
>>> >Even if these considerations are = not relevant to this
>>> >context, it will be necessary to = augment G.783 equipment
>>> >functions to recognize this new = usage of Jx messages.
>>> We would be happy to provide assistance = to T1X1/ITU-T in augmenting
>>> G.783 equipment functions to recognize = the additional capability for

>>> GMPLS networking elements.
>>>
>>> >Required Updates to SDH Equipment = Specifications
>>> >
>>> >SDH equipment specifications as = they currently exist reflect
>>> >the usage of the Jx bytes prior to = the development of
>>> >G.7714.1. ITU-T Study Group 15 has = as a work item to
>>> >revise these equipment functions to = include support for
>>> >these new functions. Specifically, = this will involve
>>> >updates to trail termination = functions to generate and
>>> >receive the new messages and to = avoid unnecessary alarms in
>>> >the case where the new messages are = received. In addition,
>>> >non-intrusive monitoring functions = will need to be revised
>>> >so that unnecessary alarms are not = raised when the
>>> >messages are observed en-route. = Whether or not there is
>>> >further alignment between the = message formats used in
>>> >G.7714.1 and the subject draft, the = new functions to
>>> >support the subject draft will also = need to be reflected
>>> >in the atomic functions in G.783. = The sending and
>>> >receiving of these messages can be = reflected in the trail
>>> >termination functions in a similar = way to what we plan to
>>> >do for support of G.7714.1 = functions.
>>> We understand that G7714.1 is = addressing an in-service test
procedure
>>> and needs to be concerned with NIM (and = non-support of
>>> G7714.1 by legacy
>>> NIM).  The LMP test procedure is a = pre-service application.
>>> We will be
>>> happy to work with T1X1/ITU SG15 to = augment G.783 to recognize the
>>> additional capability for GMPLS = networking elements.
>>>
>>> >Terminology Differences
>>> <snip>
>>> >Based upon = draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
>>> >the "up/free = (in-service)" data link state appears to
>>> >correspond with what G.7714.1 = refers to as "out-of-
>>> >service".  This difference= in terminology has resulted in
>>> >different interpretations of the = context.  Explaining the
>>> >scenarios further in the lmp test = document would be
>>> >beneficial in establishing a = translation between the
>>> >differing uses of the same = terms.  Within ITU-T, work is
>>> >being initiated of draft Rec. = G.fame, Framework for ASON
>>> >Management, where control = plane/management plane
>>> >interactions will be = addressed.
>>> We agree that terminology differences = between IETF and ITU wrt GMPLS

>>> have been confusing.  There is an = ongoing effort within CCAMP to
work
>>> together with ITU/T1X1 on bridging the = terminology gaps. For
example,
>>> there is a new Internet draft
>>> = (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in
CCAMP
>>> to do this mapping for LMP.
>>>
>>> >Further Study Items
>>> >
>>> >Following are some areas where = further contributions are
>>> >requested:
>>> >1.   For SDH equipment = functions in G.783, it needs to
>>> >be understood whether the = application of the lmp test
>>> >message requires revision of NIM = (non-intrusive
>>> >monitoring) functions. The reason = for this is that the
>>> >test procedure is initiated between = control entities at
>>> >the end-points of the trail, and = intermediate points are
>>> >not necessarily aware that the test = is taking place. For
>>> >G.7714.1, it was felt important for = any termination or NIM
>>> >function to easily distinguish = between the various uses of
>>> >the Jx bytes. It may be necessary = for the subject draft
>>> >to use a similarly easily = recognizable format. If no
>>> >revision to NIM functions is = required for the context of
>>> >this draft, the architecture of the = context for this
>>> >application (demonstrating why the = NIM functions are not
>>> >required) should be reflected in = G.803 and/or G.807/G.8080.
>>> We understand that G7714.1 is = addressing an in-service test
procedure
>>> and needs to be concerned with NIM (and = non-support of
>>> G7714.1 by legacy
>>> NIM).  The LMP test procedure is a = pre-service application.  Can you

>>> clarify how "pre-service" = applications impact
>>> G.803/G.807/G.8080?  If we
>>> can provide assistance in updating = these Recommendations to
>>> reflect LMP
>>> applications, please let us = know.
>>>
>>> >2.Determination of whether it would = be possible to use the
>>> >identical message formats in the = subject draft as in
>>> >G.7714.1 for the connectivity = verification function.
>>> We have evaluated the current formats = in G.7714.1 and we believe are

>>> inappropriate for the usage of = LMP.
>>>
>>> >3.Determination of whether it would = be possible to use the
>>> >same overall structure = (distinguishing character, 4 bit
>>> >message type, 80 bit message body) = if a different message
>>> >format or information content is = required.
>>> As mentioned above, we believe the = overall message structure and
>>> constraints
>>> are inappropriate for LMP.
>>>
>>> >4.Work is needed to clarify under = what
>>> >configurations/states (for example: = no VC-n signals
>>> >carrying client traffic) the lmp = test message is
>>> >applicable over J0.  If the = signal can be framed and J0
>>> >can be recovered, the Regenerator = Section is considered
>>> >as "in service" from a = transport plane perspective. So
>>> >unlike the J1/J2 case, the = application of the lmp test
>>> >message at the Regenerator Section = does not occur in an
>>> >"out of service" state = (from a transport plane
>>> >perspective).
>>> Section 6.1 of G.806 refers to a = "termination function part
>>> of a trail,
>>> which is in the process of set-up" = as in the NMON state.  LMP link
>>> verification is based on pre-service = testing.  Please let us
>>> know if we
>>> can be of any assistance in updating = the appropriate
>>> Recommendations to
>>> support the GMPLS network element LMP = capability.
>>>
>>> >5. Clarification of the usage of = transport and control
>>> >names for transport resources in = the subject draft, as
>>> >described in G.8080 = Amendment
>>> LMP defines a TRACE object when a = separation between data and
control
>>> plane name space is requested.
>>>
>>> >6. Consideration of the ANSI = 64-byte J1.
>>> This was mistakenly deleted from the = latest version of the draft.
This
>>> will be included in the next = version.
>>>
>>>



------_=_NextPart_001_01C308DC.C5299590-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Apr 2003 11:45:08 +0000 Message-Id: <200304221139.HAA03114@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-mib-05.txt Date: Tue, 22 Apr 2003 07:39:08 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Link Management Protocol Management Information Base Author(s) : M. Dubuc et al. Filename : draft-ietf-ccamp-lmp-mib-05.txt Pages : 80 Date : 2003-4-21 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-mib-05.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-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-21143705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-21143705.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Apr 2003 21:56:04 +0000 Date: Mon, 21 Apr 2003 17:51:06 -0400 From: Ron Bonica Subject: RE: draft-ietf-ccamp-tracereq-01.txt To: ccamp@ops.ietf.org, bwijnen@lucent.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Bert, Sorry to have taken so long to respond. I have been away on vacation. Comments inline..... > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Wijnen, Bert (Bert) > Sent: Wednesday, April 16, 2003 9:30 AM > To: Ccamp-wg (E-mail) > Subject: FW: draft-ietf-ccamp-tracereq-01.txt > > > Please consider these comments and let me know if they > wrrant some additional text in the ID. > > Thanks, > Bert > > >***** o Tracing Requirements for Generic Tunnels (None) > > > > Token: Wijnen, Bert > > Note: New revision Addresses comments. > > Now on IESG agenda for April 17th > > Responsible: Bert > > 1. this document looks like it might be the union of all the > "i want it to do " requests. an important part of > requirements documents is knowing what to not require. > do they have any? This document specifies requirements for a new protocol. It specifies requirements, primarily, by detailing the required capabilities of applications that will use this protocol. The application may implement some subset of those capabilities. It may also implement a superset of the required capabilities. However, protocol designers are not required to consider the additional capabilities when designing the protocol. I can add some text to this effect. > 2. i am concerned about the security stuff that they've buried in > their requirements. nothing definite. it seems unwieldy. but > then, so many security things do... Can you be more specific? Is there any particular requirement that you feel cannot be implemented? > 3. section 4.1 and 4.2 seem to be worded with a particular > implementation in mind. requirements documents ought not > specify solutions (eg, 4.2 talks about udp, why can't i use > icmp?) Section 4 provides a few protocol requirements, stated as such. In particular, Section 4.1 states that the new protocol will consist of probes and responses, and that each probe/response pair will reveal information regarding a network hop. (In this respect, the new protocol will resemble TRACEROUTE). Had I remembered to include an application requirement to support partial traces through broken paths, this requirement would have made much more sense! I will fix this. Section 4.2 requires that the protocol be implemented over UDP. I included this section primarily to rule out implmentations that were _not_ acceptable. For example, ICMP should not be used, because carrying MPLS information over ICMP would constitute a layer violation. TCP should not be used, because this would conflict with the protocol's requirement for statelessness. Tunnel specific mechanisms should not be used, because this would conflict with the requirement for generality. This leaves UDP and IP as the two most resonable candidates. I can add some words indicating how we arrived at this decision. > 4. justification of requirements might be nice. > I can add a sentence or two after each requirement. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Apr 2003 19:30:33 +0000 Message-ID: <3EA445F5.1020506@ieee.org> Date: Mon, 21 Apr 2003 15:26:45 -0400 From: George Newsome 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: Dimitri.Papadimitriou@alcatel.be, Jonathan.Lang@RinconNetworks.com CC: "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, "Deborah Brungard (E-mail)" , "Steve Trowbridge (E-mail)" , Kireeti@juniper.net, "'Ron Bonica (E-mail)'" , zinin@psg.com Subject: Re: Proposed response to the Liaison Statement on LMP Link Verification Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, I have a few comments on the proposed response to the Liaison Statement from T1-X1 on LMP Link Verification. It seems to me that the response agrees that the application is the same, verifying the transport connectivity between two points. However no mention is made as to why it is neither possible nor desirable to use the same message format, thereby reducing the amount of variation in the world. One unwanted consequence of three Jx formats is equipment burden. Why should equipment be burdened with three variations, when two are quite sufficient? Part of this burden is unnecessary behaviour for equipment to sort out which format is being used, provisioning of the choice, or simply being non interoperable. A single format, which is useful in non green field applications, makes a lot of sense. I also have a few specific comments inline. Regards George Newsome Wijnen, Bert (Bert) wrote: > Thnaks for the proposed response. > > It would be good if people could tell us if they agree or disagree > and if they disagree, then pls explain why. > > If the response is acceptable, then it sounds to me that at least > there would be no impact on the draft-ietf-ccamp-lmp-08.txt > document, which is currently in IETF Last Call. Since we had split > the SONET/SDH material off into a separate document, my initial > evaluation made me think that the draft-ietf-ccamp-lmp-08.txt > would not have any ITU-T/T1X1 issues/concerns. The liason statement > did refer to it a few times and so I started to worry, but from > the (proposed) response it seems there is no isseu. > > Would be good to get at least confimration of that by the end > of the Last Call, and that is April 24th. > > Thanks, > Bert > > >>-----Original Message----- >>From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com] >>Sent: vrijdag 18 april 2003 22:25 >>To: ccamp@ops.ietf.org >>Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; >>bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be >>Subject: FW: Proposed response to the Liaison Statement on >>ASON Routing >> >> >>All, >> >>Here's a proposed response to the Liaison Statement from T1-X1 on LMP >>Link Verification, posted April 11, 2003. >> >>Thanks, >>Jonathan & Dimitri >>-------------------------------------------------------------------- >>Dear Mr. Biholar, >> >> >> >>>Context of Application Space >>> >> >> >>>It is currently our understanding that the use case >>>scenario for which this procedure is applied encompasses >>>both transport plane connectivity verification as well as >>>correlation of these entities with the control plane. >>>ITU-T G.7714.1 is focused on discovering the transport >>>plane link connection end point relationships and >>>verifying their connectivity. >>>This Recommendation defines two procedures for performing >>>the connectivity verification function, one of which >>>utilizes either the Jx or the DCC bytes of the server >>>signal (termed "in-service"). The other approach in >>>G.7714.1, termed as "out of service", corresponds to >>>inserting a test signal in the payload of the server >>>signal. Based on an analysis of the data link state >>>definitions in draft-ietf-ccamp-lmp-08.txt, we understand >>>that the approach defined in the LMP test for physical >>>connectivity occurs in the context of the "out of service" >>>state (as described in G.7714.1). >>> >>>Please confirm this. >>> >>Yes, this is correct >> >> >>>Usage of Jx Bytes >>> >>>In defining the Jx bytes within G.7714.1, the following >>>was taken into account: >>>1. One consideration involved the case where the Discovery >>>Agent is located in an external system, and an external >>>interface is used by the Network Element to provision and >>>receive the Trail Trace message. As an existing text- >>>oriented Man-Machine Language, such as TL1, may be reused >>>to provide this interface, it was decided that the >>>discovery message be limited to printable characters. >>>Specifically, the TTI characters should be limited to >>>printable characters as per T.50 with trailing NULLs or >>>SPACEs. Use of arbitrary bit patterns in the lower 7 bits >>>of each byte could prematurely terminate the pattern or >>>trigger fault notification for certain hardware or >>>software implementations. The strategy chosen in G.7714.1 >>>avoids the danger by limiting the information content of >>>each byte to 6 bits (84 bits total) and uses a base 64 >>>coding according to RFC2045 to place the information in >>>the available bits. >>> >> We understand that a general transport plane discovery agent application >> such as G.7714.1 may want to limit the format to printable >> characters. However, LMP is a subset of the GMPLS control plane >> where no such constraint exists. As such, we don't think LMP >> link verification needs to be constrained to be printable >> characters. >> This does not give any reason as to why LMP could not or should not use this limitation. When GMPLS is retrofitted onto todays networks, the same limitation will be there for the same reasons G.7714.1 took account of it. LMP may be pre-service, but this is not the same as a green field application. >> >>>2. Another consideration involved providing a means for >>>distinguishing this use of the Jx bytes from the >>>traditional use for Trail Trace identifiers in new >>>equipments. As a result, G.7714.1 includes a >>>distinguishing character ("+") as the first non-CRC byte >>>that will never appear as the first character of a TTI. >>>This requires modification of the trail termination >>>functions to prevent the raising of TTI mismatch >>>alarms during the connectivity verification process. >>> >> We understand the need for this distinguishing character for the >> G7714.1 in-service application; however, LMP link verification is designed >> to be used before a link is put in service. It is our understanding >> per G.806 section 6.1, when a TTP is not in service, it is in >> the NMON state (not monitored)." >> Many network elements take the availability of an input signal as a trigger to switch into monitoring mode. However, even for those which do not, there does not seem to be a good reason for not using a common format. >> >>>While the context for testing the transport plane >>>connectivity is different between the two documents, they >>>both use the Jx bytes of the server signal, and we invite >>>the IETF to determine the appropriateness of the above >>>aspects in their test signal definitions. >>> >>We agree the context is different. We evaluated the above aspects and >>we don't feel they are appropriate for LMP (see comments above). >> I'm still looking for the rationale that led you to this conclusion. I only see a statement. >> >>>Even if these considerations are not relevant to this >>>context, it will be necessary to augment G.783 equipment >>>functions to recognize this new usage of Jx messages. >>> >>We would be happy to provide assistance to T1X1/ITU-T in augmenting >>G.783 equipment functions to recognize the additional capability for >>GMPLS networking elements. >> >> >>>Required Updates to SDH Equipment Specifications >>> >>>SDH equipment specifications as they currently exist reflect >>>the usage of the Jx bytes prior to the development of >>>G.7714.1. ITU-T Study Group 15 has as a work item to >>>revise these equipment functions to include support for >>>these new functions. Specifically, this will involve >>>updates to trail termination functions to generate and >>>receive the new messages and to avoid unnecessary alarms in >>>the case where the new messages are received. In addition, >>>non-intrusive monitoring functions will need to be revised >>>so that unnecessary alarms are not raised when the >>>messages are observed en-route. Whether or not there is >>>further alignment between the message formats used in >>>G.7714.1 and the subject draft, the new functions to >>>support the subject draft will also need to be reflected >>>in the atomic functions in G.783. The sending and >>>receiving of these messages can be reflected in the trail >>>termination functions in a similar way to what we plan to >>>do for support of G.7714.1 functions. >>> >> We understand that G7714.1 is addressing an in-service test >> procedure and needs to be concerned with NIM (and non-support of G7714.1 >> by legacy NIM). The LMP test procedure is a pre-service >> application. We will be happy to work with T1X1/ITU SG15 to >> augment G.783 to recognize the additional capability for GMPLS >> networking elements. It seems to me that having yet another format to do the same thing, and which cannot be interleaved with normal tracing, is not an additional capability, but less capability. >> >>>Terminology Differences >>> >> >> >>>Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, >>>the "up/free (in-service)" data link state appears to >>>correspond with what G.7714.1 refers to as "out-of- >>>service". This difference in terminology has resulted in >>>different interpretations of the context. Explaining the >>>scenarios further in the lmp test document would be >>>beneficial in establishing a translation between the >>>differing uses of the same terms. Within ITU-T, work is >>>being initiated of draft Rec. G.fame, Framework for ASON >>>Management, where control plane/management plane >>>interactions will be addressed. >>> >> We agree that terminology differences between IETF and ITU wrt >> GMPLS have been confusing. There is an ongoing effort within >> CCAMP to work together with ITU/T1X1 on bridging the terminology >> gaps. For example, there is a new Internet draft (draft-aboulmagd-ccamp-transport-lmp-00.txt) >> being considered in CCAMP to do this mapping for LMP. >> >>>Further Study Items >>> >>>Following are some areas where further contributions are >>>requested: >>>1. For SDH equipment functions in G.783, it needs to >>>be understood whether the application of the lmp test >>>message requires revision of NIM (non-intrusive >>>monitoring) functions. The reason for this is that the >>>test procedure is initiated between control entities at >>>the end-points of the trail, and intermediate points are >>>not necessarily aware that the test is taking place. For >>>G.7714.1, it was felt important for any termination or NIM >>>function to easily distinguish between the various uses of >>>the Jx bytes. It may be necessary for the subject draft >>>to use a similarly easily recognizable format. If no >>>revision to NIM functions is required for the context of >>>this draft, the architecture of the context for this >>>application (demonstrating why the NIM functions are not >>>required) should be reflected in G.803 and/or G.807/G.8080. >>> >> We understand that G7714.1 is addressing an in-service test >> procedure and needs to be concerned with NIM (and non-support of G7714.1 >> by legacy NIM). The LMP test procedure is a pre-service >> application. Can you clarify how "pre-service" applications impact G.803/G.807/G.8080? If we >> can provide assistance in updating these Recommendations to >> reflect LMP applications, please let us know. >> >> G.803/G.807/G.8080? If we can provide assistance in updating >> these Recommendations to reflect LMP applications, please let us >> know. >> >>>2.Determination of whether it would be possible to use the >>>identical message formats in the subject draft as in >>>G.7714.1 for the connectivity verification function. >>> >>We have evaluated the current formats in G.7714.1 and we believe are >>inappropriate for the usage of LMP. >> Some rationale for this belief would be most useful. >> >>>3.Determination of whether it would be possible to use the >>>same overall structure (distinguishing character, 4 bit >>>message type, 80 bit message body) if a different message >>>format or information content is required. >>> >>As mentioned above, we believe the overall message structure and >>constraints are inappropriate for LMP. >> I don't see answers to the above questions re technical feasibility, and belief is not a reason for not using the same format in the interests of reducing variation. >> >>>4.Work is needed to clarify under what >>>configurations/states (for example: no VC-n signals >>>carrying client traffic) the lmp test message is >>>applicable over J0. If the signal can be framed and J0 >>>can be recovered, the Regenerator Section is considered >>>as "in service" from a transport plane perspective. So >>>unlike the J1/J2 case, the application of the lmp test >>>message at the Regenerator Section does not occur in an >>>"out of service" state (from a transport plane >>>perspective). >>> >> Section 6.1 of G.806 refers to a "termination function part of a >> trail, which is in the process of set-up" as in the NMON state. >> LMP link verification is based on pre-service testing. Please let >> us know if we can be of any assistance in updating the >> appropriate Recommendations to support the GMPLS network element >> LMP capability. >> >> >>>5. Clarification of the usage of transport and control >>>names for transport resources in the subject draft, as >>>described in G.8080 Amendment >>> >>LMP defines a TRACE object when a separation between data and control >>plane name space is requested. >> I'm afraid that I don't understand this answer. >> >>>6. Consideration of the ANSI 64-byte J1. >>> >>This was mistakenly deleted from the latest version of the draft. This >>will be included in the next version. >> Hopefully, this will not create yet another format. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Apr 2003 15:40:41 +0000 Message-ID: <9A1A304A69213E4E9CC08614134C7F7C5357D9@w2k04exg02.ciena.com> From: "Razdan, Rajender" To: "'Wijnen, Bert (Bert)'" , ccamp@ops.ietf.org, "Deborah Brungard (E-mail)" , "Steve Trowbridge (E-mail)" Cc: Kireeti@juniper.net, "'Ron Bonica (E-mail)'" , zinin@psg.com, Dimitri.Papadimitriou@alcatel.be, Jonathan.Lang@RinconNetworks.com Subject: RE: Proposed response to the Liaison Statement on ASON Routing Date: Mon, 21 Apr 2003 11:35:12 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3081B.993A4D60" 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_01C3081B.993A4D60 Content-Type: text/plain; charset="iso-8859-1" I, for one, find the response very unsatisfactory. The T1X1, in their liaison statement, put in a lot of effort in explaining the rationale behind the discovery message format as specified in G.7714.1. The response to this liaison, while acknowledging that the context for the LMP test message and the G.7714.1 discovery message are the same, perfunctorily dismisses the need for alignment between the two documents (ITU Rec. G.7714.1 and the LMP test draft). I would have thought that it is common sense to avoid having multiple formats for essentially the same application if that can be avoided. After all, it doesn't serve either the vendor community or the carriers to have to support multiple 'discovery' formats. I find it intriguing that while the LMP bootstrap draft has made attempts to align itself with G.7714.1 message format, that there should be so much resistance to doing the same with the LMP test draft document. It would be useful if the authors of the LMP test draft explain why there is such reluctance on their parts to align the LMP test message to match Rec. G.7714.1? regards, Rajender Razdan -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Saturday, April 19, 2003 11:53 AM To: ccamp@ops.ietf.org; Deborah Brungard (E-mail); Steve Trowbridge (E-mail) Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be; Jonathan.Lang@RinconNetworks.com Subject: RE: Proposed response to the Liaison Statement on ASON Routing Thnaks for the proposed response. It would be good if people could tell us if they agree or disagree and if they disagree, then pls explain why. If the response is acceptable, then it sounds to me that at least there would be no impact on the draft-ietf-ccamp-lmp-08.txt document, which is currently in IETF Last Call. Since we had split the SONET/SDH material off into a separate document, my initial evaluation made me think that the draft-ietf-ccamp-lmp-08.txt would not have any ITU-T/T1X1 issues/concerns. The liason statement did refer to it a few times and so I started to worry, but from the (proposed) response it seems there is no isseu. Would be good to get at least confimration of that by the end of the Last Call, and that is April 24th. Thanks, Bert > -----Original Message----- > From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com] > Sent: vrijdag 18 april 2003 22:25 > To: ccamp@ops.ietf.org > Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; > bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be > Subject: FW: Proposed response to the Liaison Statement on > ASON Routing > > > All, > > Here's a proposed response to the Liaison Statement from T1-X1 on LMP > Link Verification, posted April 11, 2003. > > Thanks, > Jonathan & Dimitri > -------------------------------------------------------------------- > Dear Mr. Biholar, > > > >Context of Application Space > > >It is currently our understanding that the use case > >scenario for which this procedure is applied encompasses > >both transport plane connectivity verification as well as > >correlation of these entities with the control plane. > >ITU-T G.7714.1 is focused on discovering the transport > >plane link connection end point relationships and > >verifying their connectivity. > >This Recommendation defines two procedures for performing > >the connectivity verification function, one of which > >utilizes either the Jx or the DCC bytes of the server > >signal (termed "in-service"). The other approach in > >G.7714.1, termed as "out of service", corresponds to > >inserting a test signal in the payload of the server > >signal. Based on an analysis of the data link state > >definitions in draft-ietf-ccamp-lmp-08.txt, we understand > >that the approach defined in the LMP test for physical > >connectivity occurs in the context of the "out of service" > >state (as described in G.7714.1). > > > >Please confirm this. > Yes, this is correct > > >Usage of Jx Bytes > > > >In defining the Jx bytes within G.7714.1, the following > >was taken into account: > >1. One consideration involved the case where the Discovery > >Agent is located in an external system, and an external > >interface is used by the Network Element to provision and > >receive the Trail Trace message. As an existing text- > >oriented Man-Machine Language, such as TL1, may be reused > >to provide this interface, it was decided that the > >discovery message be limited to printable characters. > >Specifically, the TTI characters should be limited to > >printable characters as per T.50 with trailing NULLs or > >SPACEs. Use of arbitrary bit patterns in the lower 7 bits > >of each byte could prematurely terminate the pattern or > >trigger fault notification for certain hardware or > >software implementations. The strategy chosen in G.7714.1 > >avoids the danger by limiting the information content of > >each byte to 6 bits (84 bits total) and uses a base 64 > >coding according to RFC2045 to place the information in > >the available bits. > We understand that a general transport plane discovery agent > application > such as G.7714.1 may want to limit the format to printable characters. > However, LMP is a subset of the GMPLS control plane where no such > constraint exists. As such, we don't think LMP link > verification needs > to be constrained to be printable characters. > > >2. Another consideration involved providing a means for > >distinguishing this use of the Jx bytes from the > >traditional use for Trail Trace identifiers in new > >equipments. As a result, G.7714.1 includes a > >distinguishing character ("+") as the first non-CRC byte > >that will never appear as the first character of a TTI. > >This requires modification of the trail termination > >functions to prevent the raising of TTI mismatch > >alarms during the connectivity verification process. > We understand the need for this distinguishing character for > the G7714.1 > in-service application; however, LMP link verification is > designed to be > used before a link is put in service. It is our > understanding per G.806 > section 6.1, when a TTP is not in service, it is in the NMON > state (not > monitored)." > > >While the context for testing the transport plane > >connectivity is different between the two documents, they > >both use the Jx bytes of the server signal, and we invite > >the IETF to determine the appropriateness of the above > >aspects in their test signal definitions. > We agree the context is different. We evaluated the above aspects and > we don't feel they are appropriate for LMP (see comments above). > > >Even if these considerations are not relevant to this > >context, it will be necessary to augment G.783 equipment > >functions to recognize this new usage of Jx messages. > We would be happy to provide assistance to T1X1/ITU-T in augmenting > G.783 equipment functions to recognize the additional capability for > GMPLS networking elements. > > >Required Updates to SDH Equipment Specifications > > > >SDH equipment specifications as they currently exist reflect > >the usage of the Jx bytes prior to the development of > >G.7714.1. ITU-T Study Group 15 has as a work item to > >revise these equipment functions to include support for > >these new functions. Specifically, this will involve > >updates to trail termination functions to generate and > >receive the new messages and to avoid unnecessary alarms in > >the case where the new messages are received. In addition, > >non-intrusive monitoring functions will need to be revised > >so that unnecessary alarms are not raised when the > >messages are observed en-route. Whether or not there is > >further alignment between the message formats used in > >G.7714.1 and the subject draft, the new functions to > >support the subject draft will also need to be reflected > >in the atomic functions in G.783. The sending and > >receiving of these messages can be reflected in the trail > >termination functions in a similar way to what we plan to > >do for support of G.7714.1 functions. > We understand that G7714.1 is addressing an in-service test procedure > and needs to be concerned with NIM (and non-support of > G7714.1 by legacy > NIM). The LMP test procedure is a pre-service application. > We will be > happy to work with T1X1/ITU SG15 to augment G.783 to recognize the > additional capability for GMPLS networking elements. > > >Terminology Differences > > >Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, > >the "up/free (in-service)" data link state appears to > >correspond with what G.7714.1 refers to as "out-of- > >service". This difference in terminology has resulted in > >different interpretations of the context. Explaining the > >scenarios further in the lmp test document would be > >beneficial in establishing a translation between the > >differing uses of the same terms. Within ITU-T, work is > >being initiated of draft Rec. G.fame, Framework for ASON > >Management, where control plane/management plane > >interactions will be addressed. > We agree that terminology differences between IETF and ITU wrt GMPLS > have been confusing. There is an ongoing effort within CCAMP to work > together with ITU/T1X1 on bridging the terminology gaps. For example, > there is a new Internet draft > (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in CCAMP > to do this mapping for LMP. > > >Further Study Items > > > >Following are some areas where further contributions are > >requested: > >1. For SDH equipment functions in G.783, it needs to > >be understood whether the application of the lmp test > >message requires revision of NIM (non-intrusive > >monitoring) functions. The reason for this is that the > >test procedure is initiated between control entities at > >the end-points of the trail, and intermediate points are > >not necessarily aware that the test is taking place. For > >G.7714.1, it was felt important for any termination or NIM > >function to easily distinguish between the various uses of > >the Jx bytes. It may be necessary for the subject draft > >to use a similarly easily recognizable format. If no > >revision to NIM functions is required for the context of > >this draft, the architecture of the context for this > >application (demonstrating why the NIM functions are not > >required) should be reflected in G.803 and/or G.807/G.8080. > We understand that G7714.1 is addressing an in-service test procedure > and needs to be concerned with NIM (and non-support of > G7714.1 by legacy > NIM). The LMP test procedure is a pre-service application. Can you > clarify how "pre-service" applications impact > G.803/G.807/G.8080? If we > can provide assistance in updating these Recommendations to > reflect LMP > applications, please let us know. > > >2.Determination of whether it would be possible to use the > >identical message formats in the subject draft as in > >G.7714.1 for the connectivity verification function. > We have evaluated the current formats in G.7714.1 and we believe are > inappropriate for the usage of LMP. > > >3.Determination of whether it would be possible to use the > >same overall structure (distinguishing character, 4 bit > >message type, 80 bit message body) if a different message > >format or information content is required. > As mentioned above, we believe the overall message structure and > constraints > are inappropriate for LMP. > > >4.Work is needed to clarify under what > >configurations/states (for example: no VC-n signals > >carrying client traffic) the lmp test message is > >applicable over J0. If the signal can be framed and J0 > >can be recovered, the Regenerator Section is considered > >as "in service" from a transport plane perspective. So > >unlike the J1/J2 case, the application of the lmp test > >message at the Regenerator Section does not occur in an > >"out of service" state (from a transport plane > >perspective). > Section 6.1 of G.806 refers to a "termination function part > of a trail, > which is in the process of set-up" as in the NMON state. LMP link > verification is based on pre-service testing. Please let us > know if we > can be of any assistance in updating the appropriate > Recommendations to > support the GMPLS network element LMP capability. > > >5. Clarification of the usage of transport and control > >names for transport resources in the subject draft, as > >described in G.8080 Amendment > LMP defines a TRACE object when a separation between data and control > plane name space is requested. > > >6. Consideration of the ANSI 64-byte J1. > This was mistakenly deleted from the latest version of the draft. This > will be included in the next version. > > ------_=_NextPart_001_01C3081B.993A4D60 Content-Type: text/html; charset="iso-8859-1" RE: Proposed response to the Liaison Statement on ASON Routing

I, for one, find the response very unsatisfactory. The T1X1, in
their liaison statement, put in a lot of effort in explaining
the rationale behind the discovery message format as specified
in G.7714.1. The response to this liaison, while acknowledging
that the context for the LMP test message and the G.7714.1
discovery message are the same, perfunctorily dismisses the
need for alignment between the two documents (ITU Rec. G.7714.1
and the LMP test draft). I would have thought that it is common
sense to avoid having multiple formats for essentially the same
application if that can be avoided. After all, it doesn't serve
either the vendor community or the carriers to have to support
multiple 'discovery' formats. I find it intriguing that while
the LMP bootstrap draft has made attempts to align itself with
G.7714.1 message format, that there should be so much resistance
to doing the same with the LMP test draft document. It would be
useful if the authors of the LMP test draft explain why there
is such reluctance on their parts to align the LMP test message
to match Rec. G.7714.1?

regards,
Rajender Razdan

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Saturday, April 19, 2003 11:53 AM
To: ccamp@ops.ietf.org; Deborah Brungard (E-mail); Steve Trowbridge
(E-mail)
Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com;
bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be;
Jonathan.Lang@RinconNetworks.com
Subject: RE: Proposed response to the Liaison Statement on ASON Routing


Thnaks for the proposed response.

It would be good if people could tell us if they agree or disagree
and if they disagree, then pls explain why.

If the response is acceptable, then it sounds to me that at least
there would be no impact on the draft-ietf-ccamp-lmp-08.txt
document, which is currently in IETF Last Call. Since we had split
the SONET/SDH material off into a separate document, my initial
evaluation made me think that the draft-ietf-ccamp-lmp-08.txt
would not have any ITU-T/T1X1 issues/concerns. The liason statement
did refer to it a few times and so I started to worry, but from
the (proposed) response it seems there is no isseu.

Would be good to get at least confimration of that by the end
of the Last Call, and that is April 24th.

Thanks,
Bert

> -----Original Message-----
> From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com]
> Sent: vrijdag 18 april 2003 22:25
> To: ccamp@ops.ietf.org
> Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com;
> bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be
> Subject: FW: Proposed response to the Liaison Statement on
> ASON Routing
>
>
> All,
>
> Here's a proposed response to the Liaison Statement from T1-X1 on LMP
> Link Verification, posted April 11, 2003.
>
> Thanks,
> Jonathan & Dimitri
> --------------------------------------------------------------------
> Dear Mr. Biholar,
> 
> 
> >Context of Application Space
> <snip>
> >It is currently our understanding that the use case
> >scenario for which this procedure is applied encompasses
> >both transport plane connectivity verification as well as
> >correlation of these entities with the control plane.
> >ITU-T G.7714.1 is focused on discovering the transport
> >plane link connection end point relationships and
> >verifying their connectivity.
> >This Recommendation defines two procedures for performing
> >the connectivity verification function, one of which
> >utilizes either the Jx or the DCC bytes of the server
> >signal (termed "in-service"). The other approach in
> >G.7714.1, termed as "out of service", corresponds to
> >inserting a test signal in the payload of the server
> >signal. Based on an analysis of the data link state
> >definitions in draft-ietf-ccamp-lmp-08.txt, we understand
> >that the approach defined in the LMP test for physical
> >connectivity occurs in the context of the "out of service"
> >state (as described in G.7714.1).
> >
> >Please confirm this.
> Yes, this is correct
>
> >Usage of Jx Bytes
> >
> >In defining the Jx bytes within G.7714.1, the following
> >was taken into account:
> >1. One consideration involved the case where the Discovery
> >Agent is located in an external system, and an external
> >interface is used by the Network Element to provision and
> >receive the Trail Trace message. As an existing text-
> >oriented Man-Machine Language, such as TL1, may be reused
> >to provide this interface, it was decided that the
> >discovery message be limited to printable characters.
> >Specifically, the TTI characters should be limited to
> >printable characters as per T.50 with trailing NULLs or
> >SPACEs. Use of arbitrary bit patterns in the lower 7 bits
> >of each byte could prematurely terminate the pattern or
> >trigger fault notification for certain hardware or
> >software implementations. The strategy chosen in G.7714.1
> >avoids the danger by limiting the information content of
> >each byte to 6 bits (84 bits total) and uses a base 64
> >coding according to RFC2045 to place the information in
> >the available bits.
> We understand that a general transport plane discovery agent
> application
> such as G.7714.1 may want to limit the format to printable characters.
> However, LMP is a subset of the GMPLS control plane where no such
> constraint exists.  As such, we don't think LMP link
> verification needs
> to be constrained to be printable characters.
>
> >2. Another consideration involved providing a means for
> >distinguishing this use of the Jx bytes from the
> >traditional use for Trail Trace identifiers in new
> >equipments. As a result, G.7714.1 includes a
> >distinguishing character ("+") as the first non-CRC byte
> >that will never appear as the first character of a TTI.
> >This requires modification of the trail termination
> >functions to prevent the raising of TTI mismatch
> >alarms during the connectivity verification process.
> We understand the need for this distinguishing character for
> the G7714.1
> in-service application; however, LMP link verification is
> designed to be
> used before a link is put in service.  It is our
> understanding per G.806
> section 6.1, when a TTP is not in service, it is in the NMON
> state (not
> monitored)."
> 
> >While the context for testing the transport plane
> >connectivity is different between the two documents, they
> >both use the Jx bytes of the server signal, and we invite
> >the IETF to determine the appropriateness of the above
> >aspects in their test signal definitions.
> We agree the context is different.  We evaluated the above aspects and
> we don't feel they are appropriate for LMP (see comments above).
>
> >Even if these considerations are not relevant to this
> >context, it will be necessary to augment G.783 equipment
> >functions to recognize this new usage of Jx messages.
> We would be happy to provide assistance to T1X1/ITU-T in augmenting
> G.783 equipment functions to recognize the additional capability for
> GMPLS networking elements.
> 
> >Required Updates to SDH Equipment Specifications
> >
> >SDH equipment specifications as they currently exist reflect
> >the usage of the Jx bytes prior to the development of
> >G.7714.1. ITU-T Study Group 15 has as a work item to
> >revise these equipment functions to include support for
> >these new functions. Specifically, this will involve
> >updates to trail termination functions to generate and
> >receive the new messages and to avoid unnecessary alarms in
> >the case where the new messages are received. In addition,
> >non-intrusive monitoring functions will need to be revised
> >so that unnecessary alarms are not raised when the
> >messages are observed en-route. Whether or not there is
> >further alignment between the message formats used in
> >G.7714.1 and the subject draft, the new functions to
> >support the subject draft will also need to be reflected
> >in the atomic functions in G.783. The sending and
> >receiving of these messages can be reflected in the trail
> >termination functions in a similar way to what we plan to
> >do for support of G.7714.1 functions.
> We understand that G7714.1 is addressing an in-service test procedure
> and needs to be concerned with NIM (and non-support of
> G7714.1 by legacy
> NIM).  The LMP test procedure is a pre-service application. 
> We will be
> happy to work with T1X1/ITU SG15 to augment G.783 to recognize the
> additional capability for GMPLS networking elements.
>
> >Terminology Differences
> <snip>
> >Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
> >the "up/free (in-service)" data link state appears to
> >correspond with what G.7714.1 refers to as "out-of-
> >service".  This difference in terminology has resulted in
> >different interpretations of the context.  Explaining the
> >scenarios further in the lmp test document would be
> >beneficial in establishing a translation between the
> >differing uses of the same terms.  Within ITU-T, work is
> >being initiated of draft Rec. G.fame, Framework for ASON
> >Management, where control plane/management plane
> >interactions will be addressed.
> We agree that terminology differences between IETF and ITU wrt GMPLS
> have been confusing.  There is an ongoing effort within CCAMP to work
> together with ITU/T1X1 on bridging the terminology gaps. For example,
> there is a new Internet draft
> (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in CCAMP
> to do this mapping for LMP.
>
> >Further Study Items
> >
> >Following are some areas where further contributions are
> >requested:
> >1.   For SDH equipment functions in G.783, it needs to
> >be understood whether the application of the lmp test
> >message requires revision of NIM (non-intrusive
> >monitoring) functions. The reason for this is that the
> >test procedure is initiated between control entities at
> >the end-points of the trail, and intermediate points are
> >not necessarily aware that the test is taking place. For
> >G.7714.1, it was felt important for any termination or NIM
> >function to easily distinguish between the various uses of
> >the Jx bytes. It may be necessary for the subject draft
> >to use a similarly easily recognizable format. If no
> >revision to NIM functions is required for the context of
> >this draft, the architecture of the context for this
> >application (demonstrating why the NIM functions are not
> >required) should be reflected in G.803 and/or G.807/G.8080.
> We understand that G7714.1 is addressing an in-service test procedure
> and needs to be concerned with NIM (and non-support of
> G7714.1 by legacy
> NIM).  The LMP test procedure is a pre-service application.  Can you
> clarify how "pre-service" applications impact
> G.803/G.807/G.8080?  If we
> can provide assistance in updating these Recommendations to
> reflect LMP
> applications, please let us know.
>
> >2.Determination of whether it would be possible to use the
> >identical message formats in the subject draft as in
> >G.7714.1 for the connectivity verification function.
> We have evaluated the current formats in G.7714.1 and we believe are
> inappropriate for the usage of LMP.
> 
> >3.Determination of whether it would be possible to use the
> >same overall structure (distinguishing character, 4 bit
> >message type, 80 bit message body) if a different message
> >format or information content is required.
> As mentioned above, we believe the overall message structure and
> constraints
> are inappropriate for LMP.
>
> >4.Work is needed to clarify under what
> >configurations/states (for example: no VC-n signals
> >carrying client traffic) the lmp test message is
> >applicable over J0.  If the signal can be framed and J0
> >can be recovered, the Regenerator Section is considered
> >as "in service" from a transport plane perspective. So
> >unlike the J1/J2 case, the application of the lmp test
> >message at the Regenerator Section does not occur in an
> >"out of service" state (from a transport plane
> >perspective).
> Section 6.1 of G.806 refers to a "termination function part
> of a trail,
> which is in the process of set-up" as in the NMON state.  LMP link
> verification is based on pre-service testing.  Please let us
> know if we
> can be of any assistance in updating the appropriate
> Recommendations to
> support the GMPLS network element LMP capability.
>
> >5. Clarification of the usage of transport and control
> >names for transport resources in the subject draft, as
> >described in G.8080 Amendment
> LMP defines a TRACE object when a separation between data and control
> plane name space is requested.
> 
> >6. Consideration of the ANSI 64-byte J1.
> This was mistakenly deleted from the latest version of the draft. This
> will be included in the next version.
>
>

------_=_NextPart_001_01C3081B.993A4D60-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 19 Apr 2003 15:55:57 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155016A32B2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp@ops.ietf.org, "Deborah Brungard (E-mail)" , "Steve Trowbridge (E-mail)" Cc: Kireeti@juniper.net, "'Ron Bonica (E-mail)'" , zinin@psg.com, bwijnen@lucent.com, Dimitri.Papadimitriou@alcatel.be, Jonathan.Lang@RinconNetworks.com Subject: RE: Proposed response to the Liaison Statement on ASON Routing Date: Sat, 19 Apr 2003 17:52:45 +0200 MIME-Version: 1.0 Content-Type: text/plain Thnaks for the proposed response. It would be good if people could tell us if they agree or disagree and if they disagree, then pls explain why. If the response is acceptable, then it sounds to me that at least there would be no impact on the draft-ietf-ccamp-lmp-08.txt document, which is currently in IETF Last Call. Since we had split the SONET/SDH material off into a separate document, my initial evaluation made me think that the draft-ietf-ccamp-lmp-08.txt would not have any ITU-T/T1X1 issues/concerns. The liason statement did refer to it a few times and so I started to worry, but from the (proposed) response it seems there is no isseu. Would be good to get at least confimration of that by the end of the Last Call, and that is April 24th. Thanks, Bert > -----Original Message----- > From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com] > Sent: vrijdag 18 april 2003 22:25 > To: ccamp@ops.ietf.org > Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com; > bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be > Subject: FW: Proposed response to the Liaison Statement on > ASON Routing > > > All, > > Here's a proposed response to the Liaison Statement from T1-X1 on LMP > Link Verification, posted April 11, 2003. > > Thanks, > Jonathan & Dimitri > -------------------------------------------------------------------- > Dear Mr. Biholar, > > > >Context of Application Space > > >It is currently our understanding that the use case > >scenario for which this procedure is applied encompasses > >both transport plane connectivity verification as well as > >correlation of these entities with the control plane. > >ITU-T G.7714.1 is focused on discovering the transport > >plane link connection end point relationships and > >verifying their connectivity. > >This Recommendation defines two procedures for performing > >the connectivity verification function, one of which > >utilizes either the Jx or the DCC bytes of the server > >signal (termed "in-service"). The other approach in > >G.7714.1, termed as "out of service", corresponds to > >inserting a test signal in the payload of the server > >signal. Based on an analysis of the data link state > >definitions in draft-ietf-ccamp-lmp-08.txt, we understand > >that the approach defined in the LMP test for physical > >connectivity occurs in the context of the "out of service" > >state (as described in G.7714.1). > > > >Please confirm this. > Yes, this is correct > > >Usage of Jx Bytes > > > >In defining the Jx bytes within G.7714.1, the following > >was taken into account: > >1. One consideration involved the case where the Discovery > >Agent is located in an external system, and an external > >interface is used by the Network Element to provision and > >receive the Trail Trace message. As an existing text- > >oriented Man-Machine Language, such as TL1, may be reused > >to provide this interface, it was decided that the > >discovery message be limited to printable characters. > >Specifically, the TTI characters should be limited to > >printable characters as per T.50 with trailing NULLs or > >SPACEs. Use of arbitrary bit patterns in the lower 7 bits > >of each byte could prematurely terminate the pattern or > >trigger fault notification for certain hardware or > >software implementations. The strategy chosen in G.7714.1 > >avoids the danger by limiting the information content of > >each byte to 6 bits (84 bits total) and uses a base 64 > >coding according to RFC2045 to place the information in > >the available bits. > We understand that a general transport plane discovery agent > application > such as G.7714.1 may want to limit the format to printable characters. > However, LMP is a subset of the GMPLS control plane where no such > constraint exists. As such, we don't think LMP link > verification needs > to be constrained to be printable characters. > > >2. Another consideration involved providing a means for > >distinguishing this use of the Jx bytes from the > >traditional use for Trail Trace identifiers in new > >equipments. As a result, G.7714.1 includes a > >distinguishing character ("+") as the first non-CRC byte > >that will never appear as the first character of a TTI. > >This requires modification of the trail termination > >functions to prevent the raising of TTI mismatch > >alarms during the connectivity verification process. > We understand the need for this distinguishing character for > the G7714.1 > in-service application; however, LMP link verification is > designed to be > used before a link is put in service. It is our > understanding per G.806 > section 6.1, when a TTP is not in service, it is in the NMON > state (not > monitored)." > > >While the context for testing the transport plane > >connectivity is different between the two documents, they > >both use the Jx bytes of the server signal, and we invite > >the IETF to determine the appropriateness of the above > >aspects in their test signal definitions. > We agree the context is different. We evaluated the above aspects and > we don't feel they are appropriate for LMP (see comments above). > > >Even if these considerations are not relevant to this > >context, it will be necessary to augment G.783 equipment > >functions to recognize this new usage of Jx messages. > We would be happy to provide assistance to T1X1/ITU-T in augmenting > G.783 equipment functions to recognize the additional capability for > GMPLS networking elements. > > >Required Updates to SDH Equipment Specifications > > > >SDH equipment specifications as they currently exist reflect > >the usage of the Jx bytes prior to the development of > >G.7714.1. ITU-T Study Group 15 has as a work item to > >revise these equipment functions to include support for > >these new functions. Specifically, this will involve > >updates to trail termination functions to generate and > >receive the new messages and to avoid unnecessary alarms in > >the case where the new messages are received. In addition, > >non-intrusive monitoring functions will need to be revised > >so that unnecessary alarms are not raised when the > >messages are observed en-route. Whether or not there is > >further alignment between the message formats used in > >G.7714.1 and the subject draft, the new functions to > >support the subject draft will also need to be reflected > >in the atomic functions in G.783. The sending and > >receiving of these messages can be reflected in the trail > >termination functions in a similar way to what we plan to > >do for support of G.7714.1 functions. > We understand that G7714.1 is addressing an in-service test procedure > and needs to be concerned with NIM (and non-support of > G7714.1 by legacy > NIM). The LMP test procedure is a pre-service application. > We will be > happy to work with T1X1/ITU SG15 to augment G.783 to recognize the > additional capability for GMPLS networking elements. > > >Terminology Differences > > >Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1, > >the "up/free (in-service)" data link state appears to > >correspond with what G.7714.1 refers to as "out-of- > >service". This difference in terminology has resulted in > >different interpretations of the context. Explaining the > >scenarios further in the lmp test document would be > >beneficial in establishing a translation between the > >differing uses of the same terms. Within ITU-T, work is > >being initiated of draft Rec. G.fame, Framework for ASON > >Management, where control plane/management plane > >interactions will be addressed. > We agree that terminology differences between IETF and ITU wrt GMPLS > have been confusing. There is an ongoing effort within CCAMP to work > together with ITU/T1X1 on bridging the terminology gaps. For example, > there is a new Internet draft > (draft-aboulmagd-ccamp-transport-lmp-00.txt) being considered in CCAMP > to do this mapping for LMP. > > >Further Study Items > > > >Following are some areas where further contributions are > >requested: > >1. For SDH equipment functions in G.783, it needs to > >be understood whether the application of the lmp test > >message requires revision of NIM (non-intrusive > >monitoring) functions. The reason for this is that the > >test procedure is initiated between control entities at > >the end-points of the trail, and intermediate points are > >not necessarily aware that the test is taking place. For > >G.7714.1, it was felt important for any termination or NIM > >function to easily distinguish between the various uses of > >the Jx bytes. It may be necessary for the subject draft > >to use a similarly easily recognizable format. If no > >revision to NIM functions is required for the context of > >this draft, the architecture of the context for this > >application (demonstrating why the NIM functions are not > >required) should be reflected in G.803 and/or G.807/G.8080. > We understand that G7714.1 is addressing an in-service test procedure > and needs to be concerned with NIM (and non-support of > G7714.1 by legacy > NIM). The LMP test procedure is a pre-service application. Can you > clarify how "pre-service" applications impact > G.803/G.807/G.8080? If we > can provide assistance in updating these Recommendations to > reflect LMP > applications, please let us know. > > >2.Determination of whether it would be possible to use the > >identical message formats in the subject draft as in > >G.7714.1 for the connectivity verification function. > We have evaluated the current formats in G.7714.1 and we believe are > inappropriate for the usage of LMP. > > >3.Determination of whether it would be possible to use the > >same overall structure (distinguishing character, 4 bit > >message type, 80 bit message body) if a different message > >format or information content is required. > As mentioned above, we believe the overall message structure and > constraints > are inappropriate for LMP. > > >4.Work is needed to clarify under what > >configurations/states (for example: no VC-n signals > >carrying client traffic) the lmp test message is > >applicable over J0. If the signal can be framed and J0 > >can be recovered, the Regenerator Section is considered > >as "in service" from a transport plane perspective. So > >unlike the J1/J2 case, the application of the lmp test > >message at the Regenerator Section does not occur in an > >"out of service" state (from a transport plane > >perspective). > Section 6.1 of G.806 refers to a "termination function part > of a trail, > which is in the process of set-up" as in the NMON state. LMP link > verification is based on pre-service testing. Please let us > know if we > can be of any assistance in updating the appropriate > Recommendations to > support the GMPLS network element LMP capability. > > >5. Clarification of the usage of transport and control > >names for transport resources in the subject draft, as > >described in G.8080 Amendment > LMP defines a TRACE object when a separation between data and control > plane name space is requested. > > >6. Consideration of the ANSI 64-byte J1. > This was mistakenly deleted from the latest version of the draft. This > will be included in the next version. > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 19 Apr 2003 06:15:47 +0000 Date: Fri, 18 Apr 2003 23:10:24 -0700 (PDT) From: Kireeti Kompella To: hklam@lucent.com cc: sob@harvard.edu, "" , "" , Kireeti Kompella , "" , "" Subject: Response to the ITU-T SG 15 Liaison Statement on ASON Routing Message-ID: <20030418225708.V61419@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Mr. Lam, Regarding the following Liaison sent to the CCAMP WG, IETF: INTERNATIONAL TELECOMMUNICATION UNION COM 15 - LS 39 - E TELECOMMUNICATION STANDARDIZATION SECTOR STUDY PERIOD 2001-2004 Question(s): 12, 14/15 20-31 January 2003 LIAISON STATEMENT Source: ITU-T SG15, Q.14/15 Title: Liaison Statement To IETF CCAMP WG and Sub-IP Area Directors From WP3/15 on ASON Routing Activities To: IETF CCAMP WG and Sub-IP Area Directors cc: OSPF and ISIS Working Groups Approval: Agreed to at SG 15 meeting, Geneva, 20-31 January 2003 For: Action Deadline: None Contact: Hing-Kam Lam, Lucent Technologies, USA Tel: +1 732-949-8338 Fax: +1 732-949-5055 Email: hklam@lucent.com The CCAMP WG has formulated its reply, which follows. Please forward this reply as you see fit as Rapporteur for Q.14/15. ========================================================================== > Q.14/15 would like to inform the IETF CCAMP Working Group and the Sub-IP > Area Directors that Q.14/15 is beginning work in defining the connection > routing protocols for use in ASON networks, and requests the benefit of > the IETF's expertise in this area. The IETF CCAMP WG would be glad to help. > Q.12/15 has also developed an amendment to ITU-T Recommendation G.8080 > (Architecture for the Automatically Switched Optical Network) to provide > clarification on naming and structure of the network for routing and > signalling and add architectural support for discovery procedures and > protection/restoration. > > A set of protocol-independent high level routing architecture and > requirements has already been specified in ITU-T Recommendation G.7715 > (see below) and Q. 14/15 has initiated work on a new draft recommendation > (numbered G.7715.1) describing the requirements for a link-state method > routing protocol for ASON. > > Some of the following requirements have been identified: > > 1. The routing protocol should support partitioning of transport > networks that may be controlled by using multiple instances of different > routing protocols at different levels. > > 2. The routing protocol should support separation of control and > data (i.e, transport) planes such that data and control entities are not > required to be co-located, and the scope of the data plane resources seen > by a routing function is not limited. > > 3. The routing protocol should support distribution, abstraction and > filtering of information within hierarchical and partitioning > relationships. > > 4. The routing protocol should support independence of inter-domain > and intra-domain routing protocols. > > It should be noted that the scope of this work is limited to routing of > transport connections within ASON networks. It is our expectation that the link-state routing paradigm that is being progressed at the IETF in the CCAMP WG in conjunction with the OSPF and ISIS WGs, will be seen to meet the above requirements. Some of this has not been articulated as well as it should be; we are addressing this. > Q.12 and Q.14/15 wish to work cooperatively with IETF in order to reach a > common understanding of respective terminology and available mechanisms. That is an excellent goal. We would be glad to work with you to achieve this; similar work is already under way for signaling and protection & restoration. > An interim meeting of Q.14/15 will be held on 9-13 June 2003, located in > Chicago . The Rapporteur for Q.14/15 invites the participation of > interested IETF members in discussions of ASON routing protocols at this > meeting, and invites comments and input from IETF community to progress > this work. Those interested in attending the interim meeting should > contact the Rapporteur for Q.14/15 (H. Kam Lam, hklam@lucent.com) by May > 27, 2003. Any contributions directed to the meeting must be submitted by > June 2, 2003. Thank you for the invitation. Several interested participants from the CCAMP WG are making arrangments to attend; if at all possible, the chairs of the CCAMP WG will attend as well. In particular, we plan to make a presentation stating how the proposed link-state routing structure in the IETF addresses the requirements for ASON networks. > Approved Recommendation G.7715 and the consented amendment to > Recommendation G.8080 may be obtained from the ccamp link at: > > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/in dex.html Thank you for making this available. Kireeti Kompella & Ron Bonica CCAMP WG chairs Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 22:09:46 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155016A30FE@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: RE: draft-ietf-ccamp-tracereq-01.txt Date: Fri, 18 Apr 2003 00:04:52 +0200 MIME-Version: 1.0 Content-Type: text/plain Some members of the IESG feel that it would be best to use RFC2119 language (e.g. MUST, SHOULD etc) to express the requirements. So... could the author and WG consider such when the other comments are being addressed. Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: woensdag 16 april 2003 15:30 > To: Ccamp-wg (E-mail) > Subject: FW: draft-ietf-ccamp-tracereq-01.txt > > > Please consider these comments and let me know if they > wrrant some additional text in the ID. > > Thanks, > Bert > > >***** o Tracing Requirements for Generic Tunnels (None) > > > > Token: Wijnen, Bert > > Note: New revision Addresses comments. > > Now on IESG agenda for April 17th > > Responsible: Bert > > 1. this document looks like it might be the union of all the > "i want it to do " requests. an important part of > requirements documents is knowing what to not require. > do they have any? > 2. i am concerned about the security stuff that they've buried in > their requirements. nothing definite. it seems unwieldy. but > then, so many security things do... > 3. section 4.1 and 4.2 seem to be worded with a particular > implementation in mind. requirements documents ought not > specify solutions (eg, 4.2 talks about udp, why can't i use > icmp?) > 4. justification of requirements might be nice. > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 16:45:34 +0000 Message-ID: <3E9ED92C.8070208@alcatel.be> Date: Thu, 17 Apr 2003 18:41:16 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "Ccamp-wg (E-mail)" Subject: Re: FW: draft-ietf-ccamp-gmpls-architecture-05.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed bert, the proposed text can be (as third paragraph of the section 8): "In GMPLS, the control channels between two adjacent nodes are no longer required to use the same physical medium as the data links between those nodes. Moreover, the control channels that are used to exchange the GMPLS control-plane information exist independently of the links they manage. Hence, LMP was designed to manage the data links, independently of the termination capabilities of those data links." thanks (also to john & jonathan for their help); - dimitri. Wijnen, Bert (Bert) wrote: > While review is taking place in the IESG, we've got > this comment. Does it warrant a small piece of text > to be added, or do we believe it has been addressed > properly already? > > If text is to be added, then pls send suggested text > in an email with an indication as to where we want to > put it. Do not send a new revision of the ID (yet). > > Thanks, > Bert > > > At 04:47 AM 4/16/2003 -0700, Randy Bush wrote: > >>>one immediate question comes to mind ... they talk of a link >>>management protocl (lmp) (eg in chap 8) it seems to do just >>>about what ppp does. the obvious question is 'why not use >>>ppp?' >> >>ppp control is done in-band. LMP supports the out-of-band mode, which >>is important in optical networks where you can't simultaneously switch >>some things through (user data) and take a look at other (control >>messages). The out-of-band nature places some unique requirements >>(such as 1:n control to data link ratio, link property correlation, >>failure detection) that warrant a separate protocol. > > > If it isn't already explained in the document, one might want to > add such an explanation. Documenting _why_ things are done is just > as important as document _what_ is done. > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 16:03:20 +0000 Message-ID: <3E9ECFC5.BE723F6@lucent.com> Date: Thu, 17 Apr 2003 10:01:09 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake CC: "'Varma, Eve L (Eve)'" , "'Kireeti Kompella'" , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, sob@harvard.edu Subject: Re: Proposed response to the Liaison Statement on ASON Routing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, I think we are mixing up at least 3 questions: 1) Is the independence of inter-domain and intra-domain routing protocols a valid and accepted requirement? The proposed liaison response seems to imply yes. 2) Does the current work underway meet this requirement? Your post seems to imply yes, and you seem to be assuming that Eve's post implies no, and change is needed to meet the requirement. I think Eve's words are softer than that: "will meet" to me means that whether or not the current work underway meets the requirement, because of acceptance of the requirement, that the end result of the work will ("continue to" or "now", depending on how you read the current text) meet the requirement. 3) Is it clear from the current text that the requirement is met? Even Kireeti's response seems to say no ("has not been articulated as well as it should be ...") I think that everyone is aligned wrt. questions 1 and 3. Regarding question 2, I think the easiest path to agreement is to choose text for the liaison reply where it doesn't matter whether you think that meeting the requirement is a "clarification" or a "change", but the end result will, in any case, meet the requirement. I think Eve's suggested text does that. Regards, Steve > > "does meet" with "will meet". > > > > Couldn't resist ;-) > > > > Best regards, > > Eve > > I don't agree with this. It is actually a pretty drastic change and I don't > think it is correct. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 15:50:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200304171519.h3HFJZQA019436@newdev.harvard.edu> Date: Thu, 17 Apr 2003 11:19:35 -0400 (EDT) From: Scott Bradner To: afarrel@movaz.com, kireeti@juniper.net Subject: Re: Fw: I-D ACTION:draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt Cc: ccamp@ops.ietf.org, sob@harvard.edu [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > My inclination is the latter, as I don't believe we get liaisons from > the ITU until a doc has some stature. I would appreciate feedback from > those more familiar with the ITU process. in any case, until this ID has IETF WG status "it does not exist" so it would be not a real good idea to say all that much about it Scott Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 15:50:23 +0000 Message-ID: <3E9ECC7A.9070209@alcatel.be> Date: Thu, 17 Apr 2003 17:47:06 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: John Drake Cc: "'Varma, Eve L (Eve)'" , "'Kireeti Kompella'" , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, sob@harvard.edu Subject: Re: Proposed response to the Liaison Statement on ASON Routing Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed i concur with john, i don't think the proposed change is appropriate John Drake wrote: > snipped ... > > >>and at the end of the text to substitute: >> >>"does meet" with "will meet". >> >>Couldn't resist ;-) >> >>Best regards, >>Eve > > > I don't agree with this. It is actually a pretty drastic change and I don't > think it is correct. > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 15:42:25 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed response to the Liaison Statement on ASON Routing Date: Thu, 17 Apr 2003 10:41:25 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A7013@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Proposed response to the Liaison Statement on ASON Routing Thread-Index: AcME8t7hAc4NDE3TQEW8prJU2KB13wABK3gg From: "Ash, Gerald R (Jerry), ALABS" To: "Kireeti Kompella" , "Wijnen, Bert (Bert)" , Cc: "Ash, Gerald R (Jerry), ALABS" > Deborah Brungard sent me private mail that she thought=20 > that the wording was fine, and that sending the liaison=20 > was a Good Thing. I agree. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 15:39:43 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972436@nimbus> From: John Drake To: "'Varma, Eve L (Eve)'" , 'Kireeti Kompella' , "Wijnen, Bert (Bert)" Cc: ccamp@ops.ietf.org, sob@harvard.edu Subject: RE: Proposed response to the Liaison Statement on ASON Routing Date: Thu, 17 Apr 2003 08:37:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" That would be fine. > -----Original Message----- > From: Varma, Eve L (Eve) [mailto:evarma@lucent.com] > Sent: Thursday, April 17, 2003 8:37 AM > To: John Drake; Varma, Eve L (Eve); 'Kireeti Kompella'; Wijnen, Bert > (Bert) > Cc: ccamp@ops.ietf.org; sob@harvard.edu > Subject: RE: Proposed response to the Liaison Statement on > ASON Routing > > > Hi, > > And I thought it was the flow of the english... > > It is our expectation.......will meet.... > > Perhaps you'd prefer "will be seen to meet"? > > My understanding is that there is an intent for further > explanation is to be provided > to demonstrate this. > > Best regards, > Eve > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Thursday, April 17, 2003 11:32 AM > To: 'Varma, Eve L (Eve)'; 'Kireeti Kompella'; Wijnen, Bert (Bert) > Cc: ccamp@ops.ietf.org; sob@harvard.edu > Subject: RE: Proposed response to the Liaison Statement on > ASON Routing > > > snipped ... > > > and at the end of the text to substitute: > > > > "does meet" with "will meet". > > > > Couldn't resist ;-) > > > > Best regards, > > Eve > > I don't agree with this. It is actually a pretty drastic > change and I don't > think it is correct. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 15:38:30 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3706F141DE@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'John Drake'" , "Varma, Eve L (Eve)" , "'Kireeti Kompella'" , "Wijnen, Bert (Bert)" Cc: ccamp@ops.ietf.org, sob@harvard.edu Subject: RE: Proposed response to the Liaison Statement on ASON Routing Date: Thu, 17 Apr 2003 11:36:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, And I thought it was the flow of the english... It is our expectation.......will meet.... Perhaps you'd prefer "will be seen to meet"? My understanding is that there is an intent for further explanation is to be provided to demonstrate this. Best regards, Eve -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Thursday, April 17, 2003 11:32 AM To: 'Varma, Eve L (Eve)'; 'Kireeti Kompella'; Wijnen, Bert (Bert) Cc: ccamp@ops.ietf.org; sob@harvard.edu Subject: RE: Proposed response to the Liaison Statement on ASON Routing snipped ... > and at the end of the text to substitute: > > "does meet" with "will meet". > > Couldn't resist ;-) > > Best regards, > Eve I don't agree with this. It is actually a pretty drastic change and I don't think it is correct. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 15:33:01 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972435@nimbus> From: John Drake To: "'Varma, Eve L (Eve)'" , 'Kireeti Kompella' , "Wijnen, Bert (Bert)" Cc: ccamp@ops.ietf.org, sob@harvard.edu Subject: RE: Proposed response to the Liaison Statement on ASON Routing Date: Thu, 17 Apr 2003 08:31:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" snipped ... > and at the end of the text to substitute: > > "does meet" with "will meet". > > Couldn't resist ;-) > > Best regards, > Eve I don't agree with this. It is actually a pretty drastic change and I don't think it is correct. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 15:27:47 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200304171457.h3HEvJql019311@newdev.harvard.edu> Date: Thu, 17 Apr 2003 10:57:19 -0400 (EDT) From: Scott Bradner To: bwijnen@lucent.com, kireeti@juniper.net Subject: RE: Proposed response to the Liaison Statement on ASON Routing Cc: ccamp@ops.ietf.org, sob@harvard.edu [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > But there were many others who thought that we should be more > proactive about liaisons, and I haven't heard from them .... here is one of those - ship it :-) Scott Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 15:26:38 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155016A308B@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Cc: "Russ Housley (E-mail)" Subject: RE: draft-ietf-ccamp-gmpls-architecture Date: Thu, 17 Apr 2003 16:48:47 +0200 More comments from IESG. Since it seems we need a respin to address serious comment, pls include a fix for: Russ: Two minor comments: 1. Section 4.3, 4th paragraph says: "Forwarding Adjacencies (FA) are further described in a separate section." It would be nice to say which one. 2. Section 15, please change "IPSEC" to "IPsec." Thanks, Bert Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 15:18:19 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3706F141DB@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'Kireeti Kompella'" , "Wijnen, Bert (Bert)" Cc: ccamp@ops.ietf.org, sob@harvard.edu Subject: RE: Proposed response to the Liaison Statement on ASON Routing Date: Thu, 17 Apr 2003 11:17:15 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi, I concur that sending the liaison is indeed a Good Thing :-) Asking for comments again of course stimulates the standards editing part of my brain, and so I will offer a minor editorial "tweak", which hopefully maintains the spirit of the response. In the phrase of your proposed response below: "We believe that the link-state routing paradigm that is being progressed at the IETF in the CCAMP WG in conjunction with the OSPF and ISIS WGs, does meet the above requirements." I would suggest to substitute: "We believe" with "It is our expectation" and at the end of the text to substitute: "does meet" with "will meet". Couldn't resist ;-) Best regards, Eve -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Thursday, April 17, 2003 10:56 AM To: Wijnen, Bert (Bert) Cc: ccamp@ops.ietf.org; sob@harvard.edu Subject: RE: Proposed response to the Liaison Statement on ASON Routing Hi Bert, > I am kind of surprised that I (believe I) did not yet see > any comments. Neither positive nor negative ??? To be fair, John Drake reminded me to respond to the liaison, and Deborah Brungard sent me private mail that she thought that the wording was fine, and that sending the liaison was a Good Thing. But there were many others who thought that we should be more proactive about liaisons, and I haven't heard from them .... Warning: I will take the lack of comments to mean tacit approval. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 15:14:16 +0000 Date: Thu, 17 Apr 2003 08:12:45 -0700 (PDT) From: Kireeti Kompella To: Adrian Farrel cc: ccamp@ops.ietf.org, "" Subject: Re: Fw: I-D ACTION:draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt Message-ID: <20030417075645.T53863@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks, Adrian et al for taking this on. > Kireeti, should someone (you?) formally notify the ITU of the existence > of this draft? Scott, any comments? Thoughts: o Let the ITU know formally _now_, OR o Let's work on this, and if it becomes a WG doc, let the ITU know _then_. My inclination is the latter, as I don't believe we get liaisons from the ITU until a doc has some stature. I would appreciate feedback from those more familiar with the ITU process. But I would re-iterate Adrian's appeal: please read and comment on the doc, as I would like to initiate a call to make this a WG doc soon, especially in the light of sending a formal liaison to the ITU-T. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 14:58:39 +0000 Date: Thu, 17 Apr 2003 07:56:10 -0700 (PDT) From: Kireeti Kompella To: "Wijnen, Bert (Bert)" cc: ccamp@ops.ietf.org, "" Subject: RE: Proposed response to the Liaison Statement on ASON Routing Message-ID: <20030417074722.M53863@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Bert, > I am kind of surprised that I (believe I) did not yet see > any comments. Neither positive nor negative ??? To be fair, John Drake reminded me to respond to the liaison, and Deborah Brungard sent me private mail that she thought that the wording was fine, and that sending the liaison was a Good Thing. But there were many others who thought that we should be more proactive about liaisons, and I haven't heard from them .... Warning: I will take the lack of comments to mean tacit approval. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 13:47:37 +0000 Message-ID: <004c01c304e7$c5801d50$681810ac@movaz.com> From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Subject: Fw: I-D ACTION:draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt Date: Thu, 17 Apr 2003 09:46:38 -0400 All, We have published a draft to formally close the loop on specifying (within the IETF) the requirements placed on GMPLS by the ITU's ASON architecture. It is our hope that this draft will clarify those requirements for the ITU community and allow us to easily determine whether the requirements have been met. If the requirements have not been met, we hope the draft will provide a reference point for moving forward. We would welcome comments from all, but especially those with a foot in the ITU camp. Kireeti, should someone (you?) formally notify the ITU of the existence of this draft? Cheers, Adrian ----- Original Message ----- From: To: Sent: Friday, April 11, 2003 7:43 AM Subject: I-D ACTION:draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Requirements for Generalized MPLS (GMPLS) Usage and > Extensions for Automatically Switched Optical Network > (ASON) > Author(s) : D. Papadimitriou et al. > Filename : draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt > Pages : 11 > Date : 2003-4-10 > > The Generalized MPLS (GMPLS) suite of protocol has been defined to > control different switching technologies as well as different > applications. These include support for requesting TDM connections > including SONET/SDH and Optical Transport Networks (OTNs). > This document concentrates on the signaling aspects of the GMPLS > suite of protocols. It identifies the features to be covered by the > signalling protocol to support the capabilities of an Automatically > Switched Optical Network (ASON). This document provides a problem > statement and additional requirements on the GMPLS signaling > protocol to support the ASON functionality. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ason-reqts-0 0.txt Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2003 13:45:44 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155016A3050@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , ccamp@ops.ietf.org Cc: sob@harvard.edu Subject: RE: Proposed response to the Liaison Statement on ASON Routing Date: Thu, 17 Apr 2003 15:41:52 +0200 MIME-Version: 1.0 Content-Type: text/plain I am kind of surprised that I (believe I) did not yet see any comments. Neither positive nor negative ??? Thanks, Bert > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: vrijdag 11 april 2003 20:01 > To: ccamp@ops.ietf.org > Cc: sob@harvard.edu > Subject: Proposed response to the Liaison Statement on ASON Routing > > > Hi All, > > Here's a proposed response to the Liaison Statement from the ITU-T > Study Group 15, Q 12, 14/15 on ASON Routing Activities, dated January > 31, 2003. > > Please post any comments you have to the CCAMP list; we would like to > send this by COB Friday April 18. > > Kireeti. > -------------------------------------------------------------------- > Dear Mr. Lam, > > > Q.14/15 would like to inform the IETF CCAMP Working Group > and the Sub-IP > > Area Directors that Q.14/15 is beginning work in defining > the connection > > routing protocols for use in ASON networks, and requests > the benefit of > > the IETF's expertise in this area. > > The IETF CCAMP WG would be glad to help. > > > Q.12/15 has also developed an amendment to ITU-T > Recommendation G.8080 > > (Architecture for the Automatically Switched Optical > Network) to provide > > clarification on naming and structure of the network for routing and > > signalling and add architectural support for discovery > procedures and > > protection/restoration. > > > > A set of protocol-independent high level routing architecture and > > requirements has already been specified in ITU-T > Recommendation G.7715 > > (see below) and Q. 14/15 has initiated work on a new draft > recommendation > > (numbered G.7715.1) describing the requirements for a > link-state method > > routing protocol for ASON. > > > > Some of the following requirements have been identified: > > > > 1. The routing protocol should support partitioning > of transport > > networks that may be controlled by using multiple instances > of different > > routing protocols at different levels. > > > > 2. The routing protocol should support separation of > control and > > data (i.e, transport) planes such that data and control > entities are not > > required to be co-located, and the scope of the data plane > resources seen > > by a routing function is not limited. > > > > 3. The routing protocol should support distribution, > abstraction and > > filtering of information within hierarchical and partitioning > > relationships. > > > > 4. The routing protocol should support independence of > inter-domain > > and intra-domain routing protocols. > > > > It should be noted that the scope of this work is limited > to routing of > > transport connections within ASON networks. > > We believe that the link-state routing paradigm that is being > progressed > at the IETF in the CCAMP WG in conjunction with the OSPF and ISIS WGs, > does meet the above requirements. Some of this has not been > articulated > as well as it should be; we are addressing this. > > > Q.12 and Q.14/15 wish to work cooperatively with IETF in > order to reach a > > common understanding of respective terminology and > available mechanisms. > > That is an excellent goal. We would be glad to work with you > to achieve > this; similar work is already under way for signaling and protection & > restoration. > > > An interim meeting of Q.14/15 will be held on 9-13 June > 2003, located in > > Chicago . The Rapporteur for Q.14/15 invites the participation of > > interested IETF members in discussions of ASON routing > protocols at this > > meeting, and invites comments and input from IETF community > to progress > > this work. Those interested in attending the interim meeting should > > contact the Rapporteur for Q.14/15 (H. Kam Lam, > hklam@lucent.com) by May > > 27, 2003. Any contributions directed to the meeting must > be submitted by > > June 2, 2003. > > Thank you for the invitation. Several interested > participants from the > CCAMP WG are making arrangments to attend; if at all possible, the > chairs of the CCAMP WG will attend as well. In particular, we plan to > make a presentation stating how the proposed link-state > routing structure > in the IETF addresses the requirements for ASON networks. > > > Approved Recommendation G.7715 and the consented amendment to > > Recommendation G.8080 may be obtained from the ccamp link at: > > > > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/in dex.html Thank you for making this available. Kireeti Kompella & Ron Bonica CCAMP WG chairs Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Apr 2003 19:12:32 +0000 Message-ID: <05707214338CD5119BFF0040A5B170D30347EEDB@mail3.tellium.com> From: Dimitrios Pendarakis To: "'Wijnen, Bert (Bert)'" , "Ccamp-wg (E-mail)" Cc: "Steve Bellovin (E-mail)" Subject: RE: draft-ietf-ccamp-gmpls-architecture Date: Wed, 16 Apr 2003 15:04:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, Comments on the issues brought up by Steve: i) The risk of attackers being able to inject and/or snoop on (control) traffic depends on both the physical characteristics of the control link and whether the interface is an inter- or intra-domain one. For example, an in-band, in-fiber control channel over SONET/SDH overhead bytes is, in general, considered less vulnerable than an out-of-band IP network. Similarly, however, most carriers seem to consider control links that are not within their control (intra-domain) less secure. Proposed resolution: Add statement in the document stressing the dependency on control link physical characteristics. ii) Difference between authentication and authorization. I believe authorization falls in the category of what is commonly called "policy control". Steve is right about pointing this out, as well as the implications of appropriate policy controls to increase security and limit the impact of attacks. Proposed resolution: Expand on the difference, add references for policy control (rap WG?) and Steve's comment. I can provide some updated text for this, as well as (i). iii) Need for a (broader) security architecture. Clearly, a small section in the architecture document can not claim to address all security issues. I recall that there have been some individual draft submissions in the past regarding security requirements. Additionally, other bodies such as the OIF have carried more work on securing intra-domain interfaces for transport networks; some of that work could hopefully be useful in this discussion. While much of the additional work involves using profiles of existing IP security mechanisms in the ccamp context, I can see benefits in terms of pursuing this further, especially since it would help alleviate one of the concerns that carriers considering deployment of GMPLS or similar solutions have. Thanks, Dimitris -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Wednesday, April 16, 2003 12:38 PM To: Ccamp-wg (E-mail) Cc: Steve Bellovin (E-mail) Subject: FW: draft-ietf-ccamp-gmpls-architecture Comments on the document from IESG. I think we need an answer to the serious comment made by Steve -----Original Message----- From: Steve Bellovin [mailto:smb@research.att.com] Sent: woensdag 16 april 2003 18:20 To: iesg-secretary@ietf.org Cc: iesg@ietf.org Subject: draft-ietf-ccamp-gmpls-architecture Nit: section 4 says Re-using existing IP routing protocols allows for non-PSC layers to take advantages of all the valuable developments that took place since years for IP routing, which isn't grammatically correct. Serious issue: The Security Considerations section hints at, but doesn't follow through with, the difference between authentication and authorization. The requirement for cryptographic authentication or encryption depends on the risk of attackers being able to inject and/or snoop on traffic. This may or may not be correlated with intra-domain vs. inter-domain GMPLS. The physical characteristics and exposure of the link matter more; there may be additional exposure since it appears that the control plane link may be more than one hop long. The authorization question is what resources a given node may request of another. This may indeed be differ for inter-domain and intra-domain GMPLS. On the other hand, imposing such limits even internally helps guard against spreading break-ins, and has useful effects with regard to configuration errors. The more important question raised by this latter point is whether or not a security architecture is needed that specifies what sorts of restrictions can be applied. I don't know the answer to that one; clearly, though, implementors are going to have to decide. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any review, retransmission or other use of this communication by any person or entity other than the intended recipient is prohibited. If you believe that you have received this email in error please notify the sender by return electronic mail and delete all copies of this communication. ********************************************************************** Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Apr 2003 16:42:07 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155016A2E89@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Cc: "Steve Bellovin (E-mail)" Subject: FW: draft-ietf-ccamp-gmpls-architecture Date: Wed, 16 Apr 2003 18:37:56 +0200 MIME-Version: 1.0 Content-Type: text/plain Comments on the document from IESG. I think we need an answer to the serious comment made by Steve -----Original Message----- From: Steve Bellovin [mailto:smb@research.att.com] Sent: woensdag 16 april 2003 18:20 To: iesg-secretary@ietf.org Cc: iesg@ietf.org Subject: draft-ietf-ccamp-gmpls-architecture Nit: section 4 says Re-using existing IP routing protocols allows for non-PSC layers to take advantages of all the valuable developments that took place since years for IP routing, which isn't grammatically correct. Serious issue: The Security Considerations section hints at, but doesn't follow through with, the difference between authentication and authorization. The requirement for cryptographic authentication or encryption depends on the risk of attackers being able to inject and/or snoop on traffic. This may or may not be correlated with intra-domain vs. inter-domain GMPLS. The physical characteristics and exposure of the link matter more; there may be additional exposure since it appears that the control plane link may be more than one hop long. The authorization question is what resources a given node may request of another. This may indeed be differ for inter-domain and intra-domain GMPLS. On the other hand, imposing such limits even internally helps guard against spreading break-ins, and has useful effects with regard to configuration errors. The more important question raised by this latter point is whether or not a security architecture is needed that specifies what sorts of restrictions can be applied. I don't know the answer to that one; clearly, though, implementors are going to have to decide. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Apr 2003 13:36:20 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550159ACB7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: FW: draft-ietf-ccamp-gmpls-architecture-05.txt Date: Wed, 16 Apr 2003 15:30:25 +0200 MIME-Version: 1.0 Content-Type: text/plain While review is taking place in the IESG, we've got this comment. Does it warrant a small piece of text to be added, or do we believe it has been addressed properly already? If text is to be added, then pls send suggested text in an email with an indication as to where we want to put it. Do not send a new revision of the ID (yet). Thanks, Bert At 04:47 AM 4/16/2003 -0700, Randy Bush wrote: >> one immediate question comes to mind ... they talk of a link >> management protocl (lmp) (eg in chap 8) it seems to do just >> about what ppp does. the obvious question is 'why not use >> ppp?' > >ppp control is done in-band. LMP supports the out-of-band mode, which >is important in optical networks where you can't simultaneously switch >some things through (user data) and take a look at other (control >messages). The out-of-band nature places some unique requirements >(such as 1:n control to data link ratio, link property correlation, >failure detection) that warrant a separate protocol. If it isn't already explained in the document, one might want to add such an explanation. Documenting _why_ things are done is just as important as document _what_ is done. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Apr 2003 13:35:57 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550159ACB8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: FW: draft-ietf-ccamp-tracereq-01.txt Date: Wed, 16 Apr 2003 15:30:26 +0200 MIME-Version: 1.0 Content-Type: text/plain Please consider these comments and let me know if they wrrant some additional text in the ID. Thanks, Bert >***** o Tracing Requirements for Generic Tunnels (None) > > Token: Wijnen, Bert > Note: New revision Addresses comments. > Now on IESG agenda for April 17th > Responsible: Bert 1. this document looks like it might be the union of all the "i want it to do " requests. an important part of requirements documents is knowing what to not require. do they have any? 2. i am concerned about the security stuff that they've buried in their requirements. nothing definite. it seems unwieldy. but then, so many security things do... 3. section 4.1 and 4.2 seem to be worded with a particular implementation in mind. requirements documents ought not specify solutions (eg, 4.2 talks about udp, why can't i use icmp?) 4. justification of requirements might be nice. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Apr 2003 13:27:20 +0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80109D201@baker.datcon.co.uk> From: Edward Harrison To: 'Anca Zamfir' , Yakov Rekhter Cc: Sameer K , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: Repost: RFC 3471: IF ID specification WRT component link. Date: Tue, 15 Apr 2003 14:21:27 +0100 Deferred-Delivery: Tue, 15 Apr 2003 14:21:00 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi, I think I missed the answer to Anca's last question. Could someone please confirm the expected use of the IF_ID TLVs? My reading of the following text in section 8.1 of RFC 3473 (the capitalisation is mine) " For bidirectional LSPs, the sender chooses the data interface in each direction. In all cases but bundling, the upstream interface is implied by the downstream interface. For bundling, the path sender EXPLICITLY identifies the component interface used in each direction." is as follows: - For LSPs not using component links IF_ID TLVs type 1, 2 or 3 should be used. - Moreover, for bi-directional LSPs not using component links, the upstream interface is always implied by the downstream interface (and, hence, IF_ID TLVs type 1, 2 or 3 should still be used). - When using component links for a uni-directional LSP, IF_ID TLV type 4 should be used. - For bi-directional LSPs using component links, both TLVs 4 and 5 should be present - even if the upstream and downstream component links are the same. Is this what was intended or I have I misinterpreted the text? I notice that this is not what was described in (the now expired) draft-ietf-mpls-bundle-04 (section 4.3) where - component links could be numbered, in which case IF ID TLVs type 1 or 2 are used - component links could be unnumbered, in which case IF ID TLV type 3 was used - there was no provision for different upstream and downstream component links to be indicated. Is draft-ietf-mpls-bundle going to be re-issued (and, in the process iron out the inconsistencies with RFC 3473)? Thanks, Ed -----Original Message----- From: Anca Zamfir [mailto:ancaz@cisco.com] Sent: 10 March 2003 15:54 To: Yakov Rekhter Cc: Sameer K; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: Repost: RFC 3471: IF ID specification WRT component link. Yakov, At 07:37 AM 3/10/2003 -0800, Yakov Rekhter wrote: >Anca, > > > Yakov, > > What goes in the IF-ID RSVP_HOP TLVs if upstream and downstream directions > > use different numbered component links? > >draft-ietf-mpls-bundle-04.txt does *not* support this. It looks like draft-ietf-mpls-bundle-04.txt does not support different links (numbered or unnumbered) for the upstream and downstream directions. On the other hand, RFC3471 seems to allow different unnumbered links for the upstream and downstream LSP directions, but no equivalent support for the numbered case, so it looks like a small inconsistency. Any reasons for this? Thanks, Anca >Yakov. > > > Thanks, > > Anca > > > > At 06:58 AM 3/10/2003 -0800, Yakov Rekhter wrote: > > >Sameer, > > > > > > > > > > > Reposting, as I did not get any response. Could > > > > someone please answer the question. > > > > > >from draft-ietf-mpls-bundle-04.txt: > > > > > > If the component link is numbered, the IF_ID RSVP_HOP object, or > > > IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6 > > > address) TLVs (see [GMPLS-SIG]). The address carried in the TLV > > > identifies the link for which label allocation must be done. > > > > > > If the component link is unnumbered, the IF_ID RSVP_HOP object, or > > > IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The > > > value carried in Type 3 TLV contains the identifier of the selected > > > component link assigned to the link by the sender of the Path/REQUEST > > > message. Processing this object is the same as specified in Section > > > "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV" > > > of [RSVP-UNNUM]/[CRLDP-UNNUM]. > > > > > >Yakov. > > > > > > > > > > > Thanks > > > > - Sameer > > > > > > > > --- Sameer K wrote: > > > > > Hello All, > > > > > > > > > > From the RFC 3471 - GMPLS Signaling Functional > > > > > Description, Section 9.1.1, it appears that there is > > > > > no way for upstream node, to specify component links > > > > > that are numbered, in the IF-ID HOP object. > > > > > > > > > > The TLV format for IF-ID Types 4 and 5 assumes that > > > > > the component link is always un-numbered. > > > > > > > > > > Is this the way it was planned to be?. If yes, then > > > > > what should IF-ID look like for numbered component > > > > > link (which is a valid scenario per the Link > > > > > Bundling > > > > > draft). > > > > > > > > > > Or did I get it all wrong? > > > > > TIA > > > > > - Sameer > > > > > > > > > > > > > > > __________________________________________________ > > > > > Do you Yahoo!? > > > > > Yahoo! Tax Center - forms, calculators, tips, more > > > > > http://taxes.yahoo.com/ > > > > > > > > > > > > > > > > > __________________________________________________ > > > > Do you Yahoo!? > > > > Yahoo! Tax Center - forms, calculators, tips, more > > > > http://taxes.yahoo.com/ > > > > > > > > -------------------------------------------- > > Anca Zamfir Public Carrier IP > > Cisco Systems, Inc. email: ancaz@cisco.com > > 2000 Innovation Dr., Kanata tel#: (613) 254-3484 > > Ontario, CANADA K2K 3E8 fax: (613) 254-3717 > > > > > > -------------------------------------------- Anca Zamfir Public Carrier IP Cisco Systems, Inc. email: ancaz@cisco.com 2000 Innovation Dr., Kanata tel#: (613) 254-3484 Ontario, CANADA K2K 3E8 fax: (613) 254-3717 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Apr 2003 14:59:19 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt Date: Mon, 14 Apr 2003 10:57:02 -0400 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA65B@OCCLUST02EVS1.ugd.att.com> Thread-Topic: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt Thread-Index: AcMCbUfn28DwXy61RVOGQ+EGplQWfgAJ2HkQ From: "Brungard, Deborah A, ALABS" To: Cc: "Wijnen, Bert (Bert)" , "Dimitri Papadimitriou" , , , Hi Sergio, If no autodiscovery;-), try with Internet Explorer open, or with = Explorer open/cut and paste the link. Also can do via the t1x1 file = link, then scan down the list for file: 3x100110: http://www.t1.org/filemgr/FileList.taf?Directory=3Dt1x1%5Cx1.0&ShowTitle=3D= New%20T1X1%20Files Regards, Deborah -----Original Message----- From: Sergio.Belotti@alcatel.it [mailto:Sergio.Belotti@alcatel.it] Sent: Monday, April 14, 2003 5:57 AM To: Brungard, Deborah A, ALABS Cc: Wijnen, Bert (Bert); Dimitri Papadimitriou; sjtrowbridge@lucent.com; ccamp@ops.ietf.org; t1x15@t1.org Subject: Re: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt Sorry Deborah, are you sure about the link address since I'm unable to connect to and = retrieve the document. Regards Sergio "Brungard, Deborah A, ALABS" wrote: > Bert, > > T1X1.5 reviewed the draft at our meeting last week and prepared a = response. The T1X1 Chair will be sending the liaison to you, for those = interested in reviewing before it is uploaded to the IETF site, here's a = link to the T1X1 site: > > ftp://ftp.t1.org/T1X1/X1.0/3X100110.doc > > Regards, > Deborah > > -----Original Message----- > From: Brungard, Deborah A, ALABS > Sent: Friday, March 28, 2003 4:53 PM > To: Wijnen, Bert (Bert); Dimitri Papadimitriou; = sjtrowbridge@lucent.com > Cc: ccamp@ops.ietf.org; t1x15@t1.org > Subject: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt > > Bert, > > Sorry for the late response, I was out for vacation and just catching = up. > > Lacking a formal liaison process for IETF to communicate with T1X1/ITU = (hopefully we will have a process soon;-)), I think the best approach to = handle your request will be for me to upload the draft to the t1x15 = files. As we have a meeting next week, I will introduce the draft for = discussion and provide you with a response asap. > > At our September meeting, Jonathan was able to attend and present the = IETF lmp bootstrap proposal. It was extremely helpful to have him there, = as we all know, the difference in our terminology can be fatal to = communication. Lacking LMP representation at next week's meeting, it = would be helpful to ensure we understand your request. My understanding = is your request is to understand if there are any issues with the use of = the sonet-sdh overhead bytes as proposed by LMP. To help T1X1.5 = understand the application, I've summarized as follows. Please = comment/clarify if I have misunderstood. > > - lmp-test-sonet-sdh is a GMPLS protocol-specific method to manage = GMPLS control plane neighboring nodes. Management includes managing of = the GMPLS control channel and TE links (GMPLS control plane logical = constructs). > > - LMP test messages are defined for link verification and correlation. = Two options are defined, one using the Jx bytes, the other using an = "out-of-band" trace correlation. The out-of-band trace correlation = (using the LMP control channel) has no impact on the Jx bytes, Jx use is = per the currently defined T1.105/G.707 Access Point Identifier = application. In addition, a trace monitor capability is defined to = detect mis-connections, this capability also uses the currently defined = G.707/G.783 Jx and trace mismatch process. > > - "in-band" test messages using the Jx bytes are defined based on the = G.707 16-byte multi-frame. The test messages are used to identify GMPLS = links i.e. populate the GMPLS database as links available for use = (routing/signalling). This process is a pre-service application i.e. the = method is used to determine the available links to use for routing user = traffic (i.e. the links are not carrying user traffic during this test = phase). Whereas the G.707/T1.105 Jx Access Point Identifier is an = "in-service" application. > > - an earlier draft version included the 64-byte J1 format. Was it = intentionally or unintentionally deleted as part of the updates to = remove the incorrect reference for the 64-byte J0? The 64-byte J1 is the = ANSI defined format. The 16-byte format support is considered optional = to support international applications. > > - LMP link verification and correlation are GMPLS-specific i.e. = different application than the G.7714.1 layer adjacency discovery. > > Thanks, > Deborah > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, March 18, 2003 6:13 PM > To: Dimitri Papadimitriou; sjtrowbridge@lucent.com > Cc: ccamp@ops.ietf.org > Subject: RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt > > Dimitri says: > > hi steve, > > > > > All, > > > Bert asked me to have a look at this from an ITU-T perspective. > > > > what does that really mean ? > > > This means that I got an IETF document from one of the WGs for which > I am the responsible AD. It also means that this document is about > using SONET/SDH overhead bytes, which I think are under control of = ITU. > So I want to check for such type of documents if there are issues > from the "owning SDO" with the proposed use of such overhead bytes > > Seems to be doing due diligence on my part. > > And since Steve is often (one of) the interface people from SG15 > to IETF (he is vice chair of SG15), that is why I asked him. > > I also asked Deborah Brungard (T1X1) with the same question. > > Hope this explains. > Bert Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Apr 2003 10:09:08 +0000 Message-ID: <3E9A85F8.E4191AD6@alcatel.it> Date: Mon, 14 Apr 2003 11:57:12 +0200 From: Sergio.Belotti@alcatel.it Reply-To: sergio.belotti@alcatel.it Organization: OND MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" Cc: "Wijnen, Bert (Bert)" , Dimitri Papadimitriou , sjtrowbridge@lucent.com, ccamp@ops.ietf.org, t1x15@t1.org Subject: Re: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt Content-Type: multipart/mixed; boundary="------------0B609BA75BEE99BDCA813F0F" This is a multi-part message in MIME format. --------------0B609BA75BEE99BDCA813F0F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sorry Deborah, are you sure about the link address since I'm unable to connect to and retrieve the document. Regards Sergio "Brungard, Deborah A, ALABS" wrote: > Bert, > > T1X1.5 reviewed the draft at our meeting last week and prepared a response. The T1X1 Chair will be sending the liaison to you, for those interested in reviewing before it is uploaded to the IETF site, here's a link to the T1X1 site: > > ftp://ftp.t1.org/T1X1/X1.0/3X100110.doc > > Regards, > Deborah > > -----Original Message----- > From: Brungard, Deborah A, ALABS > Sent: Friday, March 28, 2003 4:53 PM > To: Wijnen, Bert (Bert); Dimitri Papadimitriou; sjtrowbridge@lucent.com > Cc: ccamp@ops.ietf.org; t1x15@t1.org > Subject: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt > > Bert, > > Sorry for the late response, I was out for vacation and just catching up. > > Lacking a formal liaison process for IETF to communicate with T1X1/ITU (hopefully we will have a process soon;-)), I think the best approach to handle your request will be for me to upload the draft to the t1x15 files. As we have a meeting next week, I will introduce the draft for discussion and provide you with a response asap. > > At our September meeting, Jonathan was able to attend and present the IETF lmp bootstrap proposal. It was extremely helpful to have him there, as we all know, the difference in our terminology can be fatal to communication. Lacking LMP representation at next week's meeting, it would be helpful to ensure we understand your request. My understanding is your request is to understand if there are any issues with the use of the sonet-sdh overhead bytes as proposed by LMP. To help T1X1.5 understand the application, I've summarized as follows. Please comment/clarify if I have misunderstood. > > - lmp-test-sonet-sdh is a GMPLS protocol-specific method to manage GMPLS control plane neighboring nodes. Management includes managing of the GMPLS control channel and TE links (GMPLS control plane logical constructs). > > - LMP test messages are defined for link verification and correlation. Two options are defined, one using the Jx bytes, the other using an "out-of-band" trace correlation. The out-of-band trace correlation (using the LMP control channel) has no impact on the Jx bytes, Jx use is per the currently defined T1.105/G.707 Access Point Identifier application. In addition, a trace monitor capability is defined to detect mis-connections, this capability also uses the currently defined G.707/G.783 Jx and trace mismatch process. > > - "in-band" test messages using the Jx bytes are defined based on the G.707 16-byte multi-frame. The test messages are used to identify GMPLS links i.e. populate the GMPLS database as links available for use (routing/signalling). This process is a pre-service application i.e. the method is used to determine the available links to use for routing user traffic (i.e. the links are not carrying user traffic during this test phase). Whereas the G.707/T1.105 Jx Access Point Identifier is an "in-service" application. > > - an earlier draft version included the 64-byte J1 format. Was it intentionally or unintentionally deleted as part of the updates to remove the incorrect reference for the 64-byte J0? The 64-byte J1 is the ANSI defined format. The 16-byte format support is considered optional to support international applications. > > - LMP link verification and correlation are GMPLS-specific i.e. different application than the G.7714.1 layer adjacency discovery. > > Thanks, > Deborah > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, March 18, 2003 6:13 PM > To: Dimitri Papadimitriou; sjtrowbridge@lucent.com > Cc: ccamp@ops.ietf.org > Subject: RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt > > Dimitri says: > > hi steve, > > > > > All, > > > Bert asked me to have a look at this from an ITU-T perspective. > > > > what does that really mean ? > > > This means that I got an IETF document from one of the WGs for which > I am the responsible AD. It also means that this document is about > using SONET/SDH overhead bytes, which I think are under control of ITU. > So I want to check for such type of documents if there are issues > from the "owning SDO" with the proposed use of such overhead bytes > > Seems to be doing due diligence on my part. > > And since Steve is often (one of) the interface people from SG15 > to IETF (he is vice chair of SG15), that is why I asked him. > > I also asked Deborah Brungard (T1X1) with the same question. > > Hope this explains. > Bert --------------0B609BA75BEE99BDCA813F0F Content-Transfer-Encoding: 7bit Content-Type: text/x-vcard; charset=us-ascii; name="sergio.belotti.vcf" Content-Description: Card for sergio belotti Content-Disposition: attachment; filename="sergio.belotti.vcf" begin:vcard n:belotti;sergio x-mozilla-html:FALSE org:;OND- Product Strategy adr:;;via Trento 30;vimercate;Milano;20059;Italy version:2.1 email;internet:sergio.belotti@alcatel.it title:Product Manager x-mozilla-cpt:;-200 fn:Sergio Belotti end:vcard --------------0B609BA75BEE99BDCA813F0F-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Apr 2003 18:02:44 +0000 Date: Fri, 11 Apr 2003 11:01:12 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org cc: sob@harvard.edu Subject: Proposed response to the Liaison Statement on ASON Routing Message-ID: <20030411105304.A28716@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi All, Here's a proposed response to the Liaison Statement from the ITU-T Study Group 15, Q 12, 14/15 on ASON Routing Activities, dated January 31, 2003. Please post any comments you have to the CCAMP list; we would like to send this by COB Friday April 18. Kireeti. -------------------------------------------------------------------- Dear Mr. Lam, > Q.14/15 would like to inform the IETF CCAMP Working Group and the Sub-IP > Area Directors that Q.14/15 is beginning work in defining the connection > routing protocols for use in ASON networks, and requests the benefit of > the IETF's expertise in this area. The IETF CCAMP WG would be glad to help. > Q.12/15 has also developed an amendment to ITU-T Recommendation G.8080 > (Architecture for the Automatically Switched Optical Network) to provide > clarification on naming and structure of the network for routing and > signalling and add architectural support for discovery procedures and > protection/restoration. > > A set of protocol-independent high level routing architecture and > requirements has already been specified in ITU-T Recommendation G.7715 > (see below) and Q. 14/15 has initiated work on a new draft recommendation > (numbered G.7715.1) describing the requirements for a link-state method > routing protocol for ASON. > > Some of the following requirements have been identified: > > 1. The routing protocol should support partitioning of transport > networks that may be controlled by using multiple instances of different > routing protocols at different levels. > > 2. The routing protocol should support separation of control and > data (i.e, transport) planes such that data and control entities are not > required to be co-located, and the scope of the data plane resources seen > by a routing function is not limited. > > 3. The routing protocol should support distribution, abstraction and > filtering of information within hierarchical and partitioning > relationships. > > 4. The routing protocol should support independence of inter-domain > and intra-domain routing protocols. > > It should be noted that the scope of this work is limited to routing of > transport connections within ASON networks. We believe that the link-state routing paradigm that is being progressed at the IETF in the CCAMP WG in conjunction with the OSPF and ISIS WGs, does meet the above requirements. Some of this has not been articulated as well as it should be; we are addressing this. > Q.12 and Q.14/15 wish to work cooperatively with IETF in order to reach a > common understanding of respective terminology and available mechanisms. That is an excellent goal. We would be glad to work with you to achieve this; similar work is already under way for signaling and protection & restoration. > An interim meeting of Q.14/15 will be held on 9-13 June 2003, located in > Chicago . The Rapporteur for Q.14/15 invites the participation of > interested IETF members in discussions of ASON routing protocols at this > meeting, and invites comments and input from IETF community to progress > this work. Those interested in attending the interim meeting should > contact the Rapporteur for Q.14/15 (H. Kam Lam, hklam@lucent.com) by May > 27, 2003. Any contributions directed to the meeting must be submitted by > June 2, 2003. Thank you for the invitation. Several interested participants from the CCAMP WG are making arrangments to attend; if at all possible, the chairs of the CCAMP WG will attend as well. In particular, we plan to make a presentation stating how the proposed link-state routing structure in the IETF addresses the requirements for ASON networks. > Approved Recommendation G.7715 and the consented amendment to > Recommendation G.8080 may be obtained from the ccamp link at: > > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/in dex.html Thank you for making this available. Kireeti Kompella & Ron Bonica CCAMP WG chairs Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Apr 2003 17:52:44 +0000 Date: Fri, 11 Apr 2003 10:50:10 -0700 (PDT) From: Kireeti Kompella To: "Brungard, Deborah A, ALABS" cc: "Wijnen, Bert (Bert)" , Dimitri Papadimitriou , "" , "" , "" Subject: RE: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt Message-ID: <20030411103709.L28716@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks Deborah for posting this! I would like to encourage those interested in LMP link verification to read this soon, and help formulate a response. If anyone has a problem reading Word files, I can post a PDF version. There is a deadline of June 9, 2003, but let's try to get a response we have consensus well before that. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Apr 2003 16:50:15 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt Date: Fri, 11 Apr 2003 12:47:24 -0400 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA656@OCCLUST02EVS1.ugd.att.com> Thread-Topic: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt Thread-Index: AcLtpGmMgpGxyYSXRtqW4PiO4IzqTQHzzNhgArVle7A= From: "Brungard, Deborah A, ALABS" To: "Brungard, Deborah A, ALABS" , "Wijnen, Bert (Bert)" , "Dimitri Papadimitriou" , Cc: , Bert, T1X1.5 reviewed the draft at our meeting last week and prepared a = response. The T1X1 Chair will be sending the liaison to you, for those = interested in reviewing before it is uploaded to the IETF site, here's a = link to the T1X1 site: ftp://ftp.t1.org/T1X1/X1.0/3X100110.doc Regards, Deborah -----Original Message----- From: Brungard, Deborah A, ALABS=20 Sent: Friday, March 28, 2003 4:53 PM To: Wijnen, Bert (Bert); Dimitri Papadimitriou; sjtrowbridge@lucent.com Cc: ccamp@ops.ietf.org; t1x15@t1.org Subject: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt Bert, Sorry for the late response, I was out for vacation and just catching = up. Lacking a formal liaison process for IETF to communicate with T1X1/ITU = (hopefully we will have a process soon;-)), I think the best approach to = handle your request will be for me to upload the draft to the t1x15 = files. As we have a meeting next week, I will introduce the draft for = discussion and provide you with a response asap. At our September meeting, Jonathan was able to attend and present the = IETF lmp bootstrap proposal. It was extremely helpful to have him there, = as we all know, the difference in our terminology can be fatal to = communication. Lacking LMP representation at next week's meeting, it = would be helpful to ensure we understand your request. My understanding = is your request is to understand if there are any issues with the use of = the sonet-sdh overhead bytes as proposed by LMP. To help T1X1.5 = understand the application, I've summarized as follows. Please = comment/clarify if I have misunderstood. - lmp-test-sonet-sdh is a GMPLS protocol-specific method to manage GMPLS = control plane neighboring nodes. Management includes managing of the = GMPLS control channel and TE links (GMPLS control plane logical = constructs). - LMP test messages are defined for link verification and correlation. = Two options are defined, one using the Jx bytes, the other using an = "out-of-band" trace correlation. The out-of-band trace correlation = (using the LMP control channel) has no impact on the Jx bytes, Jx use is = per the currently defined T1.105/G.707 Access Point Identifier = application. In addition, a trace monitor capability is defined to = detect mis-connections, this capability also uses the currently defined = G.707/G.783 Jx and trace mismatch process. - "in-band" test messages using the Jx bytes are defined based on the = G.707 16-byte multi-frame. The test messages are used to identify GMPLS = links i.e. populate the GMPLS database as links available for use = (routing/signalling). This process is a pre-service application i.e. the = method is used to determine the available links to use for routing user = traffic (i.e. the links are not carrying user traffic during this test = phase). Whereas the G.707/T1.105 Jx Access Point Identifier is an = "in-service" application. - an earlier draft version included the 64-byte J1 format. Was it = intentionally or unintentionally deleted as part of the updates to = remove the incorrect reference for the 64-byte J0? The 64-byte J1 is the = ANSI defined format. The 16-byte format support is considered optional = to support international applications. - LMP link verification and correlation are GMPLS-specific i.e. = different application than the G.7714.1 layer adjacency discovery. Thanks, Deborah -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, March 18, 2003 6:13 PM To: Dimitri Papadimitriou; sjtrowbridge@lucent.com Cc: ccamp@ops.ietf.org Subject: RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt Dimitri says: > hi steve, > =20 > > All, > > Bert asked me to have a look at this from an ITU-T perspective. >=20 > what does that really mean ? >=20 This means that I got an IETF document from one of the WGs for which I am the responsible AD. It also means that this document is about using SONET/SDH overhead bytes, which I think are under control of ITU. So I want to check for such type of documents if there are issues from the "owning SDO" with the proposed use of such overhead bytes Seems to be doing due diligence on my part. And since Steve is often (one of) the interface people from SG15 to IETF (he is vice chair of SG15), that is why I asked him. I also asked Deborah Brungard (T1X1) with the same question. Hope this explains. Bert Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Apr 2003 03:25:51 +0000 Date: Thu, 10 Apr 2003 23:20:05 -0400 From: Ron Bonica Subject: FW: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, 2003) To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit FYI > -----Original Message----- > From: owner-ietf-announce@ietf.org > [mailto:owner-ietf-announce@ietf.org]On Behalf Of Internet-Drafts > Administrator > Sent: Thursday, April 10, 2003 8:25 AM > To: IETF-Announce: > Subject: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, > 2003) > > > > NOTE: There are two (2) Internet-Draft Cutoff dates > > June 23rd: Cutoff for Initial Submissions (new documents) > > All initial submissions(-00) must be submitted by Monday, June 23rd, > at 09:00 ET. Initial submissions received after this time will NOT be > made available in the Internet-Drafts directory, and will have to be > resubmitted. > > > As before, all initial submissions (-00.txt) with a filename beginning > with a draft-ietf MUST be approved by the appropriate WG Chair prior to > processing and announcing. WG Chair approval must be received by > Monday, June 16th. > > Please do NOT wait until the last minute to submit. > > Be advised: NO placeholders. Updates to initial submissions received > the week of June 23rd will NOT be accepted. > > June 30st: FINAL Internet-Draft Cutoff > > All revised Internet-Draft submissions must be submitted by Monday, > July 30st, 2003 at 09:00 ET. Internet-Drafts received after this > time will NOT be announced NOR made available in the Internet-Drafts > Directories. > > We will begin accepting Internet-Draft submissions the week of the > meeting, though announcements will NOT be sent until the IETF meeting > is over. > > Thank you for your understanding and cooperation. Please do not hesitate > to contact us if you have any questions or concenrs. > > FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_57.html > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Apr 2003 18:37:59 +0000 Message-Id: <200304101832.OAA29779@ietf.org> To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: The IESG SUBJECT: Last Call: Link Management Protocol (LMP) to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 10 Apr 2003 14:32:21 -0400 The IESG has received a request from the Common Control and Measurement Plane Working Group to consider Link Management Protocol (LMP) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-4-24. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-08.txt Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2003 14:36:44 +0000 Message-ID: <200304081403.KAA10568@ietf.org> From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-tracereq-01.txt Date: Tue, 8 Apr 2003 15:03:55 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2FDDB.642B0000" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2FDDB.642B0000 Content-Type: text/plain; charset="iso-8859-1" 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 : Tracing Requirements for Generic Tunnels Author(s) : R. Bonica, K. Kompella, D. Meyer Filename : draft-ietf-ccamp-tracereq-01.txt Pages : 0 Date : 2003-4-7 This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support the generic route-tracing application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They also use the generic route-tracing application to discover details regarding tunnels that support IP forwarding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-01.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-tracereq-01.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-tracereq-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C2FDDB.642B0000 Content-Type: application/octet-stream; name="ATT150061.TXT" Content-Disposition: attachment; filename="ATT150061.TXT" Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-7125006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-tracereq-01.txt ------_=_NextPart_000_01C2FDDB.642B0000 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-ccamp-tracereq-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_000_01C2FDDB.642B0000-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2003 14:07:07 +0000 Message-Id: <200304081403.KAA10568@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-tracereq-01.txt Date: Tue, 08 Apr 2003 10:03:55 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Tracing Requirements for Generic Tunnels Author(s) : R. Bonica, K. Kompella, D. Meyer Filename : draft-ietf-ccamp-tracereq-01.txt Pages : 0 Date : 2003-4-7 This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support the generic route-tracing application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They also use the generic route-tracing application to discover details regarding tunnels that support IP forwarding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-01.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-tracereq-01.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-tracereq-01.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: <2003-4-7125006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-tracereq-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-tracereq-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-7125006.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2003 13:44:20 +0000 Message-ID: <000a01c2fd9c$db5ac640$044aa8c0@rinconnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" From: Jonathan.Lang@RinconNetworks.com To: sugadeeshg@netplane.com, ccamp@ops.ietf.org Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08) Date: Tue, 8 Apr 2003 08:02:45 +0100 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Sugadeesh, > -----Original Message----- > From: Gudipalli, Sugadeesh [mailto:sugadeeshg@netplane.com] > Sent: Monday, April 07, 2003 9:55 PM > To: 'Jonathan Lang'; ccamp@ops.ietf.org; 'jplang@ieee.org' > Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08) > > Jonathan, > > Thanks for the quick response, The following sentence you > sent is still not clear to me. > > "LMP link verification procedure is a mechanism that can be used to > dynamically bind the local/remote identifiers." > ^^^^^^^^^^^^^^^^^^^^^^^^^ > What identifiers, if they are component id,port id or interface id there > is > no issue. I have an issue only regarding TE link id. "identifiers" includes TE link id and Interface Id. (the latter often refers to port ids or component ids) > > Thanks for clarifying that property correlation need not be done > before link verification, then what is the use of "Link > Verification Supported" flag in the linksummary message which is > sent after the link verification procedures are already done for the TE > link. Link verification can also be done after the LinkSummary exchange. E.g., support for this procedure can be added/removed after the TE link is brought up. > > In 7.Message_Id Usage section there is no discussion of message id for > BeginVerify Message but it has field in it. Do we have to > ignore the message id field. If not since this is TE link specific > message, we will be needed to identify the local TE link for > message id validation when a beginverify is received. If the mapping is > already not configured on the two nodes for TE links, the identification > of the local TE link id when beginverify arrives with no > REMOTE_LINK_ID will be impossible. Please reread Section 7 and Section 12.5 to see the discussion of message id for BeginVerify message. Specifically, Section 7 states, "for TE link specific messages, the Message_Id field is within the scope of the LMP adjacency." Note that an "LMP adjacency" is formed between two nodes when at least one bi-directional control channel is established between them (see Section 2). Thanks, Jonathan > > Please clarify > > Regards > Sugadeesh > > -----Original Message----- > From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com] > Sent: Monday, April 07, 2003 10:22 PM > To: 'Gudipalli, Sugadeesh'; ccamp@ops.ietf.org; jplang@ieee.org > Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08) > > > Sugadeesh, > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf > > Of Gudipalli, Sugadeesh > > Sent: Monday, April 07, 2003 5:16 AM > > To: 'ccamp@ops.ietf.org'; 'jplang@ieee.org' > > Cc: Gudipalli, Sugadeesh > > Subject: questions in LMP (draft-ietf-ccamp-lmp-08) > > > > Hi Lang and all, > > > > Are the link verification procedures required to generate > automatic > > remote TE link id and > > local TE link ID mapping along with the local interface id and remote > > interface id mapping. > LMP link verification procedure is a mechanism that can be used to > dynamically bind the local/remote identifiers. > > > I got the above understanding from the following statement: > > > > "5. Verifying Link Connectivity In this section, an optional procedure > is > > described that may be used > > to verify the physical connectivity of the data links and dynamically > > learn (i.e., discover) the TE link and Interface_Id associations. " > > > > > > From my understanding of the LMP spec the mapping of the remote and > local > > TE-link ID can't be discovered it needs to be configured, > you misunderstand the procedure. See below. > > > due to the following points: > > > > i) > > "Support for this procedure is indicated by setting the "Link > > Verification Supported" flag in the TE_LINK object of the > > LinkSummary message." > The next sentence says: > " If a BeginVerify message is received and link verification is not > supported for the TE link, then a BeginVerifyNack message MUST be > transmitted with Error Code indicating, "Link Verification Procedure > not supported for this TE Link." > You do not need to send a LinkSummary message before you send a > BeginVerify message. > > > > > If the remote TE link ID is not mentioned in the link summary message > sent > > to the remote node with the verification supported flag set, > This is not allowed. See Section 13.11. > > > how will the > > remote > > node identify for which local TE-link id link verification procedure > is > > supported. > > Since there is no 1 to 1 map between the control channel and TE link, > the > > remote node has no way of identifying the TE-link for which this link > > summary message is addressed. > > > > ii) > > "If the message is a LinkSummary message and the Message_Id value is > > less than the largest Message_Id value previously received from the > > sender for the TE Link, then the message SHOULD be treated as being > > out-of-order." > > > > If the remote TE link ID is not mentioned in the link summary message > sent > > to the remote node, > This is not allowed. See Section 13.11. > > > how will the remote node identify for which local > > TE-link id > > the message id in the linksummary has to be verified. > > Since there is no 1 to 1 map between the control channel and TE link, > the > > remote node has no way of identifying the TE-link for which this link > > summary message is addressed. Also for sending the linksummaryack or > > linksummarynack you need the message id specific to the local TE link, > > which > > we can't identify if the remote link id is 0. > > > > > > Can you please clarify. > Hope this helps. > > -Jonathan > > > > > > > Regards > > Sugadeesh Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2003 13:24:47 +0000 Message-ID: <000a01c2fd9c$db5ac640$044aa8c0@rinconnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit From: "Jonathan Lang" To: "'Gudipalli, Sugadeesh'" , Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08) Date: Tue, 8 Apr 2003 00:02:45 -0700 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Sugadeesh, > -----Original Message----- > From: Gudipalli, Sugadeesh [mailto:sugadeeshg@netplane.com] > Sent: Monday, April 07, 2003 9:55 PM > To: 'Jonathan Lang'; ccamp@ops.ietf.org; 'jplang@ieee.org' > Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08) > > Jonathan, > > Thanks for the quick response, The following sentence you > sent is still not clear to me. > > "LMP link verification procedure is a mechanism that can be used to > dynamically bind the local/remote identifiers." > ^^^^^^^^^^^^^^^^^^^^^^^^^ > What identifiers, if they are component id,port id or interface id there > is > no issue. I have an issue only regarding TE link id. "identifiers" includes TE link id and Interface Id. (the latter often refers to port ids or component ids) > > Thanks for clarifying that property correlation need not be done > before link verification, then what is the use of "Link > Verification Supported" flag in the linksummary message which is > sent after the link verification procedures are already done for the TE > link. Link verification can also be done after the LinkSummary exchange. E.g., support for this procedure can be added/removed after the TE link is brought up. > > In 7.Message_Id Usage section there is no discussion of message id for > BeginVerify Message but it has field in it. Do we have to > ignore the message id field. If not since this is TE link specific > message, we will be needed to identify the local TE link for > message id validation when a beginverify is received. If the mapping is > already not configured on the two nodes for TE links, the identification > of the local TE link id when beginverify arrives with no > REMOTE_LINK_ID will be impossible. Please reread Section 7 and Section 12.5 to see the discussion of message id for BeginVerify message. Specifically, Section 7 states, "for TE link specific messages, the Message_Id field is within the scope of the LMP adjacency." Note that an "LMP adjacency" is formed between two nodes when at least one bi-directional control channel is established between them (see Section 2). Thanks, Jonathan > > Please clarify > > Regards > Sugadeesh > > -----Original Message----- > From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com] > Sent: Monday, April 07, 2003 10:22 PM > To: 'Gudipalli, Sugadeesh'; ccamp@ops.ietf.org; jplang@ieee.org > Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08) > > > Sugadeesh, > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf > > Of Gudipalli, Sugadeesh > > Sent: Monday, April 07, 2003 5:16 AM > > To: 'ccamp@ops.ietf.org'; 'jplang@ieee.org' > > Cc: Gudipalli, Sugadeesh > > Subject: questions in LMP (draft-ietf-ccamp-lmp-08) > > > > Hi Lang and all, > > > > Are the link verification procedures required to generate > automatic > > remote TE link id and > > local TE link ID mapping along with the local interface id and remote > > interface id mapping. > LMP link verification procedure is a mechanism that can be used to > dynamically bind the local/remote identifiers. > > > I got the above understanding from the following statement: > > > > "5. Verifying Link Connectivity In this section, an optional procedure > is > > described that may be used > > to verify the physical connectivity of the data links and dynamically > > learn (i.e., discover) the TE link and Interface_Id associations. " > > > > > > From my understanding of the LMP spec the mapping of the remote and > local > > TE-link ID can't be discovered it needs to be configured, > you misunderstand the procedure. See below. > > > due to the following points: > > > > i) > > "Support for this procedure is indicated by setting the "Link > > Verification Supported" flag in the TE_LINK object of the > > LinkSummary message." > The next sentence says: > " If a BeginVerify message is received and link verification is not > supported for the TE link, then a BeginVerifyNack message MUST be > transmitted with Error Code indicating, "Link Verification Procedure > not supported for this TE Link." > You do not need to send a LinkSummary message before you send a > BeginVerify message. > > > > > If the remote TE link ID is not mentioned in the link summary message > sent > > to the remote node with the verification supported flag set, > This is not allowed. See Section 13.11. > > > how will the > > remote > > node identify for which local TE-link id link verification procedure > is > > supported. > > Since there is no 1 to 1 map between the control channel and TE link, > the > > remote node has no way of identifying the TE-link for which this link > > summary message is addressed. > > > > ii) > > "If the message is a LinkSummary message and the Message_Id value is > > less than the largest Message_Id value previously received from the > > sender for the TE Link, then the message SHOULD be treated as being > > out-of-order." > > > > If the remote TE link ID is not mentioned in the link summary message > sent > > to the remote node, > This is not allowed. See Section 13.11. > > > how will the remote node identify for which local > > TE-link id > > the message id in the linksummary has to be verified. > > Since there is no 1 to 1 map between the control channel and TE link, > the > > remote node has no way of identifying the TE-link for which this link > > summary message is addressed. Also for sending the linksummaryack or > > linksummarynack you need the message id specific to the local TE link, > > which > > we can't identify if the remote link id is 0. > > > > > > Can you please clarify. > Hope this helps. > > -Jonathan > > > > > > > Regards > > Sugadeesh Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2003 04:55:36 +0000 Message-ID: From: "Gudipalli, Sugadeesh" To: "'Jonathan Lang'" , ccamp@ops.ietf.org, "'jplang@ieee.org'" Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08) Date: Tue, 8 Apr 2003 00:55:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Jonathan, Thanks for the quick response, The following sentence you sent is still not clear to me. "LMP link verification procedure is a mechanism that can be used to dynamically bind the local/remote identifiers." ^^^^^^^^^^^^^^^^^^^^^^^^^ What identifiers, if they are component id,port id or interface id there is no issue. I have an issue only regarding TE link id. Thanks for clarifying that property correlation need not be done before link verification, then what is the use of "Link Verification Supported" flag in the linksummary message which is sent after the link verification procedures are already done for the TE link. In 7.Message_Id Usage section there is no discussion of message id for BeginVerify Message but it has field in it. Do we have to ignore the message id field. If not since this is TE link specific message, we will be needed to identify the local TE link for message id validation when a beginverify is received. If the mapping is already not configured on the two nodes for TE links, the identification of the local TE link id when beginverify arrives with no REMOTE_LINK_ID will be impossible. Please clarify Regards Sugadeesh -----Original Message----- From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com] Sent: Monday, April 07, 2003 10:22 PM To: 'Gudipalli, Sugadeesh'; ccamp@ops.ietf.org; jplang@ieee.org Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08) Sugadeesh, > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Gudipalli, Sugadeesh > Sent: Monday, April 07, 2003 5:16 AM > To: 'ccamp@ops.ietf.org'; 'jplang@ieee.org' > Cc: Gudipalli, Sugadeesh > Subject: questions in LMP (draft-ietf-ccamp-lmp-08) > > Hi Lang and all, > > Are the link verification procedures required to generate automatic > remote TE link id and > local TE link ID mapping along with the local interface id and remote > interface id mapping. LMP link verification procedure is a mechanism that can be used to dynamically bind the local/remote identifiers. > I got the above understanding from the following statement: > > "5. Verifying Link Connectivity In this section, an optional procedure is > described that may be used > to verify the physical connectivity of the data links and dynamically > learn (i.e., discover) the TE link and Interface_Id associations. " > > > From my understanding of the LMP spec the mapping of the remote and local > TE-link ID can't be discovered it needs to be configured, you misunderstand the procedure. See below. > due to the following points: > > i) > "Support for this procedure is indicated by setting the "Link > Verification Supported" flag in the TE_LINK object of the > LinkSummary message." The next sentence says: " If a BeginVerify message is received and link verification is not supported for the TE link, then a BeginVerifyNack message MUST be transmitted with Error Code indicating, "Link Verification Procedure not supported for this TE Link." You do not need to send a LinkSummary message before you send a BeginVerify message. > > If the remote TE link ID is not mentioned in the link summary message sent > to the remote node with the verification supported flag set, This is not allowed. See Section 13.11. > how will the > remote > node identify for which local TE-link id link verification procedure is > supported. > Since there is no 1 to 1 map between the control channel and TE link, the > remote node has no way of identifying the TE-link for which this link > summary message is addressed. > > ii) > "If the message is a LinkSummary message and the Message_Id value is > less than the largest Message_Id value previously received from the > sender for the TE Link, then the message SHOULD be treated as being > out-of-order." > > If the remote TE link ID is not mentioned in the link summary message sent > to the remote node, This is not allowed. See Section 13.11. > how will the remote node identify for which local > TE-link id > the message id in the linksummary has to be verified. > Since there is no 1 to 1 map between the control channel and TE link, the > remote node has no way of identifying the TE-link for which this link > summary message is addressed. Also for sending the linksummaryack or > linksummarynack you need the message id specific to the local TE link, > which > we can't identify if the remote link id is 0. > > > Can you please clarify. Hope this helps. -Jonathan > > > Regards > Sugadeesh Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2003 03:54:31 +0000 Date: Mon, 7 Apr 2003 23:52:46 -0400 (EDT) From: Jim Boyle To: mpls@uu.net, , , cc: te-wg@ops.ietf.org Subject: Notice of WG last call on Diff Serv TE Protocol draft in TEWG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In May 2001 the TEWG adopted the development of the requirements and necessary protocol extensions for Diff-Serv TE. Upon completion, TEWG was to notify the various protocol WGs of the proposal to allow review of the proposed protocol changes (if any). This note serves that purpose. Please find the pointer for the protocol specification draft below and review the proposed changes required in the routing and signaling protocols. A WG last call on the protocol draft will start by separate email to the TEWG. Be sure to follow-up with any discussion to the te-wg list. http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-proto-03.txt It specifies extensions outlined as follows: - IGP Reuse of unreserved bandwidth sub-tlv to carry BW available per TE-Class - IGP Optional use bandwidth constraints sub-tlv - IGP Optional use local overbooking multiplier sub-tlv - RSVP Class Type Object for signaling class-types other than 0. - RSVP Diffserv TE error codes The protocol supports the use of a variety of different bandwidth constraint models. The following drafts are examples listed here for reference only. http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-russian-02.txt http://www.ietf.org/internet-drafts/draft-lefaucheur-diff-te-mam-00.txt http://www.ietf.org/internet-drafts/draft-ash-mpls-dste-bcmodel-max-alloc-resv-01.txt Also for reference, the requirements are developed and with RFC-ED now. http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-07.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Apr 2003 16:55:47 +0000 Message-ID: <000001c2fd26$0f518320$6b01000a@rinconnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: "Jonathan Lang" To: "'Gudipalli, Sugadeesh'" , , Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08) Date: Mon, 7 Apr 2003 09:52:22 -0700 Sugadeesh, > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Gudipalli, Sugadeesh > Sent: Monday, April 07, 2003 5:16 AM > To: 'ccamp@ops.ietf.org'; 'jplang@ieee.org' > Cc: Gudipalli, Sugadeesh > Subject: questions in LMP (draft-ietf-ccamp-lmp-08) > > Hi Lang and all, > > Are the link verification procedures required to generate automatic > remote TE link id and > local TE link ID mapping along with the local interface id and remote > interface id mapping. LMP link verification procedure is a mechanism that can be used to dynamically bind the local/remote identifiers. > I got the above understanding from the following statement: > > "5. Verifying Link Connectivity In this section, an optional procedure is > described that may be used > to verify the physical connectivity of the data links and dynamically > learn (i.e., discover) the TE link and Interface_Id associations. " > > > From my understanding of the LMP spec the mapping of the remote and local > TE-link ID can't be discovered it needs to be configured, you misunderstand the procedure. See below. > due to the following points: > > i) > "Support for this procedure is indicated by setting the "Link > Verification Supported" flag in the TE_LINK object of the > LinkSummary message." The next sentence says: " If a BeginVerify message is received and link verification is not supported for the TE link, then a BeginVerifyNack message MUST be transmitted with Error Code indicating, "Link Verification Procedure not supported for this TE Link." You do not need to send a LinkSummary message before you send a BeginVerify message. > > If the remote TE link ID is not mentioned in the link summary message sent > to the remote node with the verification supported flag set, This is not allowed. See Section 13.11. > how will the > remote > node identify for which local TE-link id link verification procedure is > supported. > Since there is no 1 to 1 map between the control channel and TE link, the > remote node has no way of identifying the TE-link for which this link > summary message is addressed. > > ii) > "If the message is a LinkSummary message and the Message_Id value is > less than the largest Message_Id value previously received from the > sender for the TE Link, then the message SHOULD be treated as being > out-of-order." > > If the remote TE link ID is not mentioned in the link summary message sent > to the remote node, This is not allowed. See Section 13.11. > how will the remote node identify for which local > TE-link id > the message id in the linksummary has to be verified. > Since there is no 1 to 1 map between the control channel and TE link, the > remote node has no way of identifying the TE-link for which this link > summary message is addressed. Also for sending the linksummaryack or > linksummarynack you need the message id specific to the local TE link, > which > we can't identify if the remote link id is 0. > > > Can you please clarify. Hope this helps. -Jonathan > > > Regards > Sugadeesh Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Apr 2003 12:18:46 +0000 Message-ID: From: "Gudipalli, Sugadeesh" To: "'ccamp@ops.ietf.org'" , "'jplang@ieee.org'" Cc: "Gudipalli, Sugadeesh" Subject: questions in LMP (draft-ietf-ccamp-lmp-08) Date: Mon, 7 Apr 2003 08:15:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Lang and all, Are the link verification procedures required to generate automatic remote TE link id and local TE link ID mapping along with the local interface id and remote interface id mapping. I got the above understanding from the following statement: "5. Verifying Link Connectivity In this section, an optional procedure is described that may be used to verify the physical connectivity of the data links and dynamically learn (i.e., discover) the TE link and Interface_Id associations. " >From my understanding of the LMP spec the mapping of the remote and local TE-link ID can't be discovered it needs to be configured, due to the following points: i) "Support for this procedure is indicated by setting the "Link Verification Supported" flag in the TE_LINK object of the LinkSummary message." If the remote TE link ID is not mentioned in the link summary message sent to the remote node with the verification supported flag set, how will the remote node identify for which local TE-link id link verification procedure is supported. Since there is no 1 to 1 map between the control channel and TE link, the remote node has no way of identifying the TE-link for which this link summary message is addressed. ii) "If the message is a LinkSummary message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the TE Link, then the message SHOULD be treated as being out-of-order." If the remote TE link ID is not mentioned in the link summary message sent to the remote node, how will the remote node identify for which local TE-link id the message id in the linksummary has to be verified. Since there is no 1 to 1 map between the control channel and TE link, the remote node has no way of identifying the TE-link for which this link summary message is addressed. Also for sending the linksummaryack or linksummarynack you need the message id specific to the local TE link, which we can't identify if the remote link id is 0. Can you please clarify. Regards Sugadeesh Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 06 Apr 2003 02:44:04 +0000 Date: Sat, 05 Apr 2003 21:41:16 -0500 From: Ron Bonica Subject: RE: AD review for: draft-ietf-ccamp-tracereq-00.txt To: "Wijnen, Bert (Bert)" , "Ccamp-wg (E-mail)" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Bert, I have corrected these problems and submitted an updated version of the draft. Until the draft editor processes it, the updated version can be found at www.bonica.org/docs/draft-ietf-ccamp-tracereq-01.txt Ron > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Wijnen, Bert (Bert) > Sent: Friday, April 04, 2003 10:46 AM > To: Ccamp-wg (E-mail) > Subject: AD review for: draft-ietf-ccamp-tracereq-00.txt > > > Sorry for the dealy. Here we go. > > - The status of memo and abstract should NOT be numbered, > see draft-rfc-editor-rfc2223bis-04.txt > - I wonder why section 3 and the reference to RFC2119 > is present. You do NOT use any of those terms... or am I > missing something? > - In the abstract, I do not see the word "tunnel" at all. > Is that not something to be described? The title and > the rest of the document seem to make it clear that > tracing of tunnels needs special consideration and > features > - first bullet section 6. > Is the priviledge (i.e. security token) also not imporant > for bullet 9?? > - bullet 3 sect 6. > Is it worth to point to RFC2925, that allows for such a > function for traditional traceroute? > - Sect 7.4 > Mmm... section title is "Maintaining State" and it explains > or prescribes that the protocol should be "stateless". > Maybe title should be "Stateless Requirement" ?? > - Security considerations: I assume it is also a requirement to > prevent replay attacks? > - I am surprised with the reference to RFC2026. It will go away > when this turns into an RFC. Maybe your boilerplate should > use just RFC 2026 instead of [RFC-2026] > - You have reference to RFC-2637 in the references section, > But I do not see it anywhere in the text. > It might actually be good to refence all of the tunneling > protocols that you mention. > - I wonder why there is a reference to RFC2434? It is not > cited in the text anywhere. > > Bert > > > Thanks, > Bert > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Apr 2003 07:47:16 -0800 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501484182@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: AD review for: draft-ietf-ccamp-tracereq-00.txt Date: Fri, 4 Apr 2003 17:45:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sorry for the dealy. Here we go. - The status of memo and abstract should NOT be numbered, see draft-rfc-editor-rfc2223bis-04.txt - I wonder why section 3 and the reference to RFC2119 is present. You do NOT use any of those terms... or am I missing something? - In the abstract, I do not see the word "tunnel" at all. Is that not something to be described? The title and the rest of the document seem to make it clear that tracing of tunnels needs special consideration and features - first bullet section 6. Is the priviledge (i.e. security token) also not imporant for bullet 9?? - bullet 3 sect 6. Is it worth to point to RFC2925, that allows for such a function for traditional traceroute? - Sect 7.4 Mmm... section title is "Maintaining State" and it explains or prescribes that the protocol should be "stateless". Maybe title should be "Stateless Requirement" ?? - Security considerations: I assume it is also a requirement to prevent replay attacks? - I am surprised with the reference to RFC2026. It will go away when this turns into an RFC. Maybe your boilerplate should use just RFC 2026 instead of [RFC-2026] - You have reference to RFC-2637 in the references section, But I do not see it anywhere in the text. It might actually be good to refence all of the tunneling protocols that you mention. - I wonder why there is a reference to RFC2434? It is not cited in the text anywhere. Bert Thanks, Bert Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Apr 2003 04:26:38 -0800 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155014840EB@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: FW: AD review of draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt Date: Fri, 4 Apr 2003 14:25:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" In case you didn't know, based on a comment that was send to me, I have asked (via INT AD Thomas Narten) a check by the PPPEXT WG. The issue was proper use of RFC1662/1661. Those who want to follow the discussions whould join the PPPEXT mailing list. The archive is at: ftp://ftp.merit.edu/mail.archives/ietf-ppp-archive/ietf-ppplog.2003.04 Thanks, Bert Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Apr 2003 03:44:06 -0800 Message-Id: <200304041137.GAA14823@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-oki-ccamp-gmpls-ip-interworking-00.txt Date: Fri, 04 Apr 2003 06:37:58 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : GMPLS and IP/MPLS Interworking Architecture Author(s) : E. Oki et al. Filename : draft-oki-ccamp-gmpls-ip-interworking-00.txt Pages : 6 Date : 2003-4-3 Generalized MPLS extends MPLS to support various transport technologies. One GMPLS target is to seamlessly integrate IP/MPLS networks with vari- ous transport networks such as SONET/SDH and wavelength networks. How- ever, in the migration from IP/MPLS networks to GMPLS networks, both kinds of networks will coexist at some point. IP/MPLS nodes that do not support GMPLS protocols must also work with GMPLS networks. This docu- ment addresses the GMPLS and IP/MPLS interworking architecture, and examples both routing and signaling aspects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-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-oki-ccamp-gmpls-ip-interworking-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-oki-ccamp-gmpls-ip-interworking-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: <2003-4-4065049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-oki-ccamp-gmpls-ip-interworking-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-4065049.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 03 Apr 2003 07:40:12 -0800 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501483F4C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: FW: Protocol Action: Generalized Multiprotocol Label Switching Ex tensions for SONET and SDH Control to Proposed Standard Date: Thu, 3 Apr 2003 17:38:47 +0200 MIME-Version: 1.0 Content-Type: text/plain So as you can see... over the last few days, the IESG approved the document. The extra review by the security AD did not reveal any issues to stop the document. Thanks, Bert -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: donderdag 3 april 2003 16:55 Cc: RFC Editor; Internet Architecture Board; ccamp@ops.ietf.org Subject: Protocol Action: Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control to Proposed Standard The IESG has approved the Internet-Draft 'Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Scott Bradner. Technical Summary This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. Working Group Summary The WG has consensus on this document. Protocol Quality This document was reviewed for the IESG by Bert Wijnen. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 03 Apr 2003 06:59:42 -0800 Message-Id: <200304031455.JAA21985@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ccamp@ops.ietf.org From: The IESG Subject: Protocol Action: Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control to Proposed Standard Date: Thu, 03 Apr 2003 09:55:17 -0500 The IESG has approved the Internet-Draft 'Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control' as a Proposed Standard. This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bert Wijnen and Scott Bradner. Technical Summary This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. Working Group Summary The WG has consensus on this document. Protocol Quality This document was reviewed for the IESG by Bert Wijnen. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 02 Apr 2003 11:55:59 -0800 Message-Id: <200304021954.OAA29131@bifocal.cisco.com> To: ccamp@ops.ietf.org, te-wg@ops.ietf.org Reply-To: mpls@uu.net Subject: Last call in MPLS WG on TC MIB Date: Wed, 02 Apr 2003 14:54:32 -0500 From: George Swallow The MPLS TC MIB is referred to by documents in CCAMP and TE-WG. This is to inform you that a last call is in progress in the MPLS WG on Definitions of Textual for Multiprotocol Label Switching (MPLS) Management draft-ietf-mpls-tc-mib-06.txt The last call closes 4/16 24:00 GMT. Please make any and all comments to the MPLS list only (mpls@uu.net). Thanks, ...George ====================================================================== George Swallow Cisco Systems (978) 936-1398 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Apr 2003 10:44:57 -0800 Message-ID: <3E89DD8B.A2F32E84@alcatel.com> Date: Tue, 01 Apr 2003 13:42:19 -0500 From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com MIME-Version: 1.0 To: Ron Bonica CC: ccamp@ops.ietf.org, minutes@ietf.org Subject: Re: IETF 56 CCAMP minutes - UPDATE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ron, I think Kireeti also said the CCAMP chairs will look for a WG for this : > Adrian: draft-lee-ccamp-rsvp-te-exclude-route-01 > ------------------------------------------------ > ..... > > Questions to room: > ~15 have read the draft > ~20 find it useful > ~30 think it should become wg doc in some wg > 0 find it not ready thanks Cheng-Yin Ron Bonica wrote: > > Folks, > > Please accept the following updated minutes from IETF 56 - CCAMP. There is > one minor change. > > Ron > > ============================================ > > Kireeti: WG status > ------------------ > > Short overview on status of WG documents as listed on web page. > > Questions: > - framework for sonet/sdh control draft ready for LC? -> unclear > - LMP MIB to Last Call? > Bert asked for checkup > Authors will provide new version and then last call on mailing list > - non-standard sonet/sdh extensions? -> no interest in room > Bert Wijnen: There is still no document describing what exactly > is signaled. If that is not provided, this draft should go to wastebin. > **no referenced document** > > Wesam Alanqar: ITU liaison report > --------------------------------- > > ITU-T SG15 update to ccamp. This presentation has also been sent > to the mailing list. > 3 liaison statements exist: ason routing, discovery, restoration/re-routing. > > IETF routing experts are invited to come to next ITU meeting. > > Dimitri Papadimitriou: Ext. in support of end-to-end GMPLS-based recovery > ------------------------------------------------------------------------- > > draft-lang-ccamp-gmpls-recovery-e2e-signaling-00 > > After 1 year of work: terminology starts to be widely adopted, > analysis i-d still too largely scoped. > Still needs to be covered: bulk lsp recovery, reversion (switch back) > > Next steps: > next report April 03, func spec ready for LC > Functional spec to be ready for LC *in April'03* > protocol spec expected to be ready in July 03 > > Should the terminology doc become PS? > - AD will check whether it should be informational or PS > > Peter Czezowski: recovery requirements, fault notification protocol and LMP > ---------------------------------------------------------------------------- > > Presenting 3 drafts and changes to them: > - draft-czezowski-optical-recovery-reqs-01.txt > - draft-rabbat-fault-notification-protocol-02.txt > - draft-soumiya-lmp-fault-notification-ext-00.txt > > The first 2 drafts believed to be ready. There is running code for > the third draft, but is there any interest? > Comments are requested from mailing list. > > George: Changing pt-to-pt protocol to a flooding protocol is more than > just adding a message. It results in a different implementation > model for LMP. > Kireeti: Don't start by modifying LMP, first look into problem and > requirements. Need mailing list discussion whether LMP is right. > Alex: It took several net meltdowns to learn how to do flooding right. > > Dimitri: draft-lang-ccamp-lmp-bootstrap-03 > ------------------------------------------ > > Changes: modified J0/J1/J2-16 string to fit within 80 bits, > added layer adjacency discovery > Next steps: believes all technical issues raised on the mailing list solved, > accept as wg doc? > > Is this a worthwhile LMP extension (apart from questions about format > details)? > > Kireeti: needs discussion on list > Jonathan Sadler: mechanism worthwhile, encoding still has problems > Dimitri: suggest to create document with common bootstrap mechanism, > then sonet/sdh specific doc, where sonet/sdh encoding specifics would be > specified > Jonathan Lang: is feature desired by community? find out before splitting > docs and put more work in it > > Question to room: ~7 think it's useful, nobody against -> take to list > > George: draft-ietf-ccamp-gmpls-overlay-01 > ----------------------------------------- > > Question to room: "ready for WG LC?": > ~20 yes, 0 no > -> check consensus on list > -> start WG last call after meeting > > Dimitri: technology specific routing extensions to GMPLS routing > ---------------------------------------------------------------- > > draft-mannie-ccamp-gmpls-sonet-sdh-{ospf,isis} > > Changes: discussion concerning bandwidth encoding, section on scalability > and backward compatibility consideration. > > Falls within Sonet/SDH basket. Some assertions have been made on list, > addressed one-by-one in the presentation. > > Jonathan Sadler: need discussion on list instead of rhetorical questions > here > > A layering discussion ensued. > > Kireeti: need layer relationship document (refering to the mrn i-d) > > Poll of the room: ~15 think it's a useful idea, ~5 against making it wg doc > Kireeti: reasonable support, take to list > > Adrian Farrel: GMPLS MIBs > ------------------------- > > 3 drafts became WG drafts in June 02, nothing happened since. > Waiting for MPLS MIBS to go to LC before republishing GMPLS MIBs. > Plan: > wait for MPLS MIBs republication and LC > quick editorial respin to bring in line (~4 weeks after MPLS MIBs) > content additions, republish before Vienna > chairs would like LC in August (but need WG feedback) > > Adrian: draft-lee-ccamp-rsvp-te-exclude-route-01 > ------------------------------------------------ > > Why in gmpls? > think is ccamp charter item, increasing interest (inter-AS/area), > is mpls extension but is generalized and should be part of GMPLS > Why needed? > needed where path computation is not only in one place > Changes: > identification of new work items > Actions: > got useful feedback > solicit input from providers > look for convergence with JP's draft > WG item? > > George: should talk about it in sub-ip directorate meeting > > Questions to room: > ~15 have read the draft > ~20 find it useful > ~30 think it should become wg doc in some wg > 0 find it not ready > > Osama Aboul-Magd: a transport view to LMP > ----------------------------------------- > > draft-aboulmagd-ccamp-transport-lmp-00.txt > > Kireeti: What does control plane discovery mean? > Is LMP + LMP bootstrap close enough to what this draft does? > Very useful spec, provides "language translation". > > Malcolm Betts: progress this draft before LMP bootstrap draft > > Ron Bonica: generic tunnel tracing > ---------------------------------- > > Requirements doc is stable, WG LC complete. > Time to work on solution, IANA has assigned UDP port, > new context object added. > > Solicit feedback from implementers. > Adopt as ccamp work item? > > Room poll: ~10 have read the draft -> need to take to list > > Ron (for Loa): MPLS and GMPLS change process > -------------------------------------------- > > Status: lots of lively discussion, topics: > - is this merely a reaffirmation of IETF process? > - what is the role of a liaison? > - when all approvals are not obtained? Is there any alternative > to the dust bin? > > Don Fedyk: need better understanding, common model/language > > Monique Morrow: ITU/IETF need to work together > > Jerry Ash: document describing liaisons? > > Kireeti: there already is such as doc (may be insufficient), separate > from this > > Bert: liaison process is wider issue (not specific to this WG) > > Malcolm Betts: draft fine for IP applications, how about non-IP apps? How > can get those requirements recognized in IETF? > > Ron: requirements must be stated clearly to be understood by IETF WG > > Kireeti: Draft documents how ietf process works. > The process may need a dust bin for bad ideas and another > bin for "not in IETF scope, but not really broken". > It is not addressed yet how to handle stuff the IETF doesn't like. > > Alex: Need interest by IETF community to make things happen, > same thing applicable to anyone coming to IETF. > People need to be convinced. > > Bert: subip area initially had problem with too many drafts, > was fixed by requiring problem statements > > Marten: Process is very mature dealing with submissions by individuals, > but not from other organizations. > I-Ds not suited to deal with peer standardization organization. > ITU can't do ascii diagrams or read through mailing list > to gather IETF opinion. > Need a way to apply IETF protocols to non-IETF problem. > > Kireeti: GMPLS work did step out of traditional ietf scope > > George: coopeation would work a lot better if clear requirements would > be communicated instead of sending in solutions > (even applies within IETF) > > Sharam Davari: another standardization organization should not have > same weight as an individual submission > > Ron: I-D should be evaluated on its merit, author irrelevant > > Kireeti: ccamp charter update > ----------------------------- > > - not done by WG consensus > - proposed by chairs to AD, AD takes it to IESG/IAB > > Alex: correction: WG consensus *is* required but is not enough > > under consideration: > - inter-area signaling and routing of generalized paths > - crackback wrt inter-area > - inter-as on hold until tewg produces requirements > - explicitely put tunnel tracing in charter > - routing extensions for Sonet/SDH > - signaling for G.709 signaling > - further LMP extensions > - optical vpn *not* in charter > > milestones: > - GMPLS MIB to WG LC in Aug 03 > - protection/restoration functional spec and protocol changes > to WG LC by Apr and Jul 03 (respectively) > - tunnel tracing protocol to WG LC by Sep 03 > - set milestones for inter-area path setup when ratified as charter changes > > need active discussion on list > > JP: combination of inter-area and inter-as is a good idea > > Kireeti: it is great if a common solution is available, but that is not > reason enough to put inter-as on charter > > Marco: O-VPN started in ITU-T, on ppvpn charter, good chance for cooperation > > Kireeti: ccamp should keep an eye on solution > > =========================================== > Ronald P. Bonica Ph: 703 886 1681 > vBNS Engineering page: 1 888 268 8021 > Ashburn, Va. > =========================================== > "We are not on Earth to guard a museum, but > to cultivate a flourishing garden of life." > -- Angelo Giuseppe Roncalli Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Apr 2003 08:05:41 -0800 Date: Tue, 01 Apr 2003 11:03:07 -0500 From: Ron Bonica Subject: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03 To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Folks, At IETF 55, we agreed to discard the following WG draft unless some of the non-standard extensions that it supports were identified: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03 By the time of IETF 56, no extensions had been identified. So, this draft will be discarded unless someone raises a strenuous objection by 4/14/2003. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "We are not on Earth to guard a museum, but to cultivate a flourishing garden of life." -- Angelo Giuseppe Roncalli