Subject: FW: draft-ietf-ccamp-lmp-08.txt
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Date: Wed, 30 Apr 2003 05:20:31 +0200

More IESG comments

Thanks,
Bert 

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]]
Sent: woensdag 30 april 2003 3:32
To: [email-masked]; [email-masked]
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:

Delivery-date: Tue, 29 Apr 2003 21:53:59 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: draft-ietf-ccamp-lmp-08
Date: Tue, 29 Apr 2003 23:52:00 +0200

More IESG review comments

Thanks,
Bert 

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: dinsdag 29 april 2003 23:14
To: [email-masked]
Cc: [email-masked]
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.

Delivery-date: Tue, 29 Apr 2003 19:26:47 +0000
Date: Tue, 29 Apr 2003 12:25:28 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, "" <[email-masked]>, Kireeti Kompella <[email-masked]>
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation

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.

Delivery-date: Tue, 29 Apr 2003 16:45:27 +0000
From: John Drake <[email-masked]>
To: 'Jonathan Sadler' <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked],  George Newsome <[email-masked]>, [email-masked],  "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked],  [email-masked], "Ron Bonica (E-mail)" <[email-masked]>,  [email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Tue, 29 Apr 2003 09:43:08 -0700

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:[email-masked]]
> Sent: Tuesday, April 29, 2003 1:47 PM
> To: John Drake
> Cc: Brungard, Deborah A, ALABS; Stephen Trowbridge;
> [email-masked]; George Newsome;
> [email-masked]; Wijnen, Bert (Bert);
> [email-masked]; [email-masked]; Ron Bonica (E-mail);
> [email-masked]
> 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.

> 
> <SNIP>
> 
> ============================================================
> The information contained in this message may be privileged 
> and confidential and protected from disclosure.  If the 
> reader of this message is not the intended recipient, or an 
> employee or agent responsible for delivering this message to 
> the intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
> 

Delivery-date: Tue, 29 Apr 2003 15:53:03 +0000
Date: Tue, 29 Apr 2003 15:46:44 -0500
From: Jonathan Sadler <[email-masked]>
To: John Drake <[email-masked]>
CC: "Brungard, Deborah A, ALABS" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], George Newsome <[email-masked]>, [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked], "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
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.

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

<SNIP>

============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

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

Delivery-date: Tue, 29 Apr 2003 11:44:09 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 29 Apr 2003 04:37:46 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: Evaluation: draft-ietf-ccamp-lmp - Link Management Protocol ( LMP) to Proposed Standard 
Date: Tue, 29 Apr 2003 06:36:53 +0200

Issues from IESG review

-----Original Message-----
From: Steven M. Bellovin [mailto:[email-masked]]
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)

Delivery-date: Tue, 29 Apr 2003 03:57:18 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Ron Bonica <[email-masked]>, [email-masked], [email-masked]
Subject: RE: draft-ietf-ccamp-tracereq-01.txt
Date: Tue, 29 Apr 2003 05:54:22 +0200

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:[email-masked]]
> Sent: maandag 28 april 2003 18:58
> To: [email-masked]; [email-masked]
> 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: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Ron Bonica
> > Sent: Monday, April 21, 2003 5:51 PM
> > To: [email-masked]; [email-masked]
> > 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: [email-masked] [mailto:[email-masked]]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)
> > > >            <draft-ietf-ccamp-tracereq-01.txt>
> > > >         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 <foo>" 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.
> >
> >
> >
> 

Delivery-date: Tue, 29 Apr 2003 03:57:11 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: CCAMP WG Last Call for Overlay document
Date: Tue, 29 Apr 2003 05:54:30 +0200

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:[email-masked]]
> Sent: zaterdag 26 april 2003 5:06
> To: [email-masked]
> 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.
> 

Delivery-date: Mon, 28 Apr 2003 21:57:35 +0000
From: John Drake <[email-masked]>
To: 'Jonathan Sadler' <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked],  George Newsome <[email-masked]>, [email-masked],  "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked],  [email-masked], "Ron Bonica (E-mail)" <[email-masked]>,  [email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Mon, 28 Apr 2003 14:56:16 -0700

> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Monday, April 28, 2003 3:08 PM
> To: John Drake
> Cc: Brungard, Deborah A, ALABS; Stephen Trowbridge;
> [email-masked]; George Newsome;
> [email-masked]; Wijnen, Bert (Bert);
> [email-masked]; [email-masked]; Ron Bonica (E-mail);
> [email-masked]
> 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 ... 

Delivery-date: Mon, 28 Apr 2003 17:11:28 +0000
Date: Mon, 28 Apr 2003 17:08:17 -0500
From: Jonathan Sadler <[email-masked]>
To: John Drake <[email-masked]>
CC: "Brungard, Deborah A, ALABS" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], George Newsome <[email-masked]>, [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked], "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
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)

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

Delivery-date: Mon, 28 Apr 2003 16:59:28 +0000
Date: Mon, 28 Apr 2003 12:57:47 -0400
From: Ron Bonica <[email-masked]>
Subject: RE: draft-ietf-ccamp-tracereq-01.txt
To: [email-masked], [email-masked]

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Ron Bonica
> Sent: Monday, April 21, 2003 5:51 PM
> To: [email-masked]; [email-masked]
> 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: [email-masked] [mailto:[email-masked]]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)
> > >            <draft-ietf-ccamp-tracereq-01.txt>
> > >         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 <foo>" 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.
>
>
>

Delivery-date: Mon, 28 Apr 2003 15:32:23 +0000
Date: Mon, 28 Apr 2003 11:31:05 -0400
From: George Newsome <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
CC: Jonathan Sadler <[email-masked]>, John Drake <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked], "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Proposed response to the Liaison Statement on LMP Link Verific ation

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

Delivery-date: Mon, 28 Apr 2003 14:58:16 +0000
content-class: urn:content-classes:message
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verific ation
Date: Mon, 28 Apr 2003 10:54:40 -0400
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Jonathan Sadler" <[email-masked]>, "John Drake" <[email-masked]>
Cc: "Stephen Trowbridge" <[email-masked]>, <[email-masked]>, "George Newsome" <[email-masked]>, <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, <[email-masked]>

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:[email-masked]]
Sent: Friday, April 25, 2003 11:43 PM
To: John Drake
Cc: Brungard, Deborah A, ALABS; Stephen Trowbridge;
[email-masked]; George Newsome;
[email-masked]; Wijnen, Bert (Bert);
[email-masked]; [email-masked]; Ron Bonica (E-mail);
[email-masked]
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

Delivery-date: Sat, 26 Apr 2003 03:07:06 +0000
Date: Fri, 25 Apr 2003 20:05:46 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
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.

Delivery-date: Fri, 25 Apr 2003 23:31:52 +0000
Date: Sat, 26 Apr 2003 01:38:13 +0200
From: [email-masked]
To: Jonathan Sadler <[email-masked]>
Cc: John Drake <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], George Newsome <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked], "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Proposed response to the Liaison Statement on LMP Link Verific ation

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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Fri, 25 Apr 2003 23:25:04 +0000
From: John Drake <[email-masked]>
To: 'Jonathan Sadler' <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked],  George Newsome <[email-masked]>, [email-masked],  "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked],  [email-masked], "Ron Bonica (E-mail)" <[email-masked]>,  [email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi c ation
Date: Fri, 25 Apr 2003 16:24:19 -0700

> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Friday, April 25, 2003 8:43 PM
> To: John Drake
> Cc: Brungard, Deborah A, ALABS; Stephen Trowbridge;
> [email-masked]; George Newsome;
> [email-masked]; Wijnen, Bert (Bert);
> [email-masked]; [email-masked]; Ron Bonica (E-mail);
> [email-masked]
> 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
> ============================================================
> 

Delivery-date: Fri, 25 Apr 2003 22:48:29 +0000
Date: Fri, 25 Apr 2003 22:43:12 -0500
From: Jonathan Sadler <[email-masked]>
To: John Drake <[email-masked]>
CC: "Brungard, Deborah A, ALABS" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], George Newsome <[email-masked]>, [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked], "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
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.)

============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

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

Delivery-date: Fri, 25 Apr 2003 21:45:17 +0000
From: John Drake <[email-masked]>
To: 'Jonathan Sadler' <[email-masked]>,  "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: Stephen Trowbridge <[email-masked]>,  [email-masked], George Newsome <[email-masked]>,  [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked],  "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Fri, 25 Apr 2003 14:44:04 -0700

Comments inline

> -----Original Message-----
> From: Jonathan Sadler [mailto:[email-masked]]
> Sent: Friday, April 25, 2003 1:49 PM
> To: Brungard, Deborah A, ALABS
> Cc: Stephen Trowbridge; [email-masked]; George
> Newsome; [email-masked]; Wijnen, Bert (Bert);
> [email-masked]; [email-masked]; Ron Bonica (E-mail);
> [email-masked]
> 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.

Delivery-date: Fri, 25 Apr 2003 20:52:15 +0000
Date: Fri, 25 Apr 2003 15:48:52 -0500
From: Jonathan Sadler <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
CC: Stephen Trowbridge <[email-masked]>, [email-masked], George Newsome <[email-masked]>, [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked], "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
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.

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

Delivery-date: Fri, 25 Apr 2003 17:56:43 +0000
Date: Fri, 25 Apr 2003 10:55:34 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Re: CCAMP WG Last Call for Overlay document

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.

Delivery-date: Fri, 25 Apr 2003 16:54:35 +0000
Date: Fri, 25 Apr 2003 18:58:04 +0200
From: [email-masked]
To: "Ccamp-wg (E-mail)" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, Dimitrios Pendarakis <[email-masked]>, "Steven M. Bellovin" <[email-masked]>
Subject: Re: draft-ietf-ccamp-gmpls-architecture

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:[email-masked]]
>>Sent: dinsdag 22 april 2003 18:31
>>To: Dimitrios Pendarakis
>>Cc: 'Wijnen, Bert (Bert)'; Ccamp-wg (E-mail); [email-masked]
>>Subject: Re: draft-ietf-ccamp-gmpls-architecture 
>>
>>
>>In message 
>><[email-masked]>, 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:[email-masked]]
>>>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:[email-masked]]
>>>Sent: woensdag 16 april 2003 18:20
>>>To: [email-masked]
>>>Cc: [email-masked]
>>>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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 24 Apr 2003 16:14:24 +0000
Date: Thu, 24 Apr 2003 18:12:39 +0200
From: [email-masked]
To: "Razdan, Rajender" <[email-masked]>
Cc: "'John Drake'" <[email-masked]>, "'George Newsome'" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked], "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation

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:[email-masked]]
> Sent: Thursday, April 24, 2003 9:50 AM
> To: 'George Newsome'; Brungard, Deborah A, ALABS
> Cc: Stephen Trowbridge; [email-masked];
> [email-masked]; Wijnen, Bert (Bert);
> [email-masked]; [email-masked]; Ron Bonica (E-mail);
> [email-masked]
> 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:[email-masked]]
>  > Sent: Wednesday, April 23, 2003 9:24 AM
>  > To: Brungard, Deborah A, ALABS
>  > Cc: Stephen Trowbridge; [email-masked];
>  > [email-masked]; Wijnen, Bert (Bert);
>  > [email-masked]; [email-masked]; Ron Bonica (E-mail);
>  > [email-masked]
>  > 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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 24 Apr 2003 15:29:40 +0000
From: John Drake <[email-masked]>
To: "'Razdan, Rajender'" <[email-masked]>, 'George Newsome' <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: Stephen Trowbridge <[email-masked]>,  [email-masked], [email-masked],  "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked],  [email-masked], "Ron Bonica (E-mail)" <[email-masked]>,  [email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Thu, 24 Apr 2003 08:27:56 -0700

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:[email-masked]]
Sent: Thursday, April 24, 2003 7:44 AM
To: John Drake; 'George Newsome'; Brungard, Deborah A, ALABS
Cc: Stephen Trowbridge; [email-masked];
[email-masked]; Wijnen, Bert (Bert); [email-masked];
[email-masked]; Ron Bonica (E-mail); [email-masked]
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:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, April 24, 2003 9:50 AM 
To: 'George Newsome'; Brungard, Deborah A, ALABS 
Cc: Stephen Trowbridge; [email-masked]; 
[email-masked]; Wijnen, Bert (Bert); 
[email-masked]; [email-masked]; Ron Bonica (E-mail); 
[email-masked] 
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:[email-masked] <mailto:[email-masked]>
] 
> Sent: Wednesday, April 23, 2003 9:24 AM 
> To: Brungard, Deborah A, ALABS 
> Cc: Stephen Trowbridge; [email-masked]; 
> [email-masked]; Wijnen, Bert (Bert); 
> [email-masked]; [email-masked]; Ron Bonica (E-mail); 
> [email-masked] 
> 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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Proposed response to the Liaison Statement on LMP Link Verifi cation</TITLE>

<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=994030515-24042003><FONT face=Arial color=#0000ff 
size=2>Raj,</FONT></SPAN></DIV>
<DIV><SPAN class=994030515-24042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=994030515-24042003><FONT face=Arial color=#0000ff size=2>I 
don't think I was suggesting what you thought I was suggesting.&nbsp; My point 
was simply</FONT></SPAN></DIV>
<DIV><SPAN class=994030515-24042003><FONT face=Arial color=#0000ff size=2>that 
when using&nbsp; the trace correlation transport mechanism, the Jx bytes are 
opaque</FONT></SPAN></DIV>
<DIV><SPAN class=994030515-24042003><FONT face=Arial color=#0000ff size=2>from a 
GMPLS perspective.</FONT></SPAN></DIV>
<DIV><SPAN class=994030515-24042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=994030515-24042003><FONT face=Arial color=#0000ff size=2>Wrt 
your original question, does G.7714.1 carry the LMP Test procedure Verify 
ID?</FONT></SPAN></DIV>
<DIV><SPAN class=994030515-24042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=994030515-24042003><FONT face=Arial color=#0000ff 
size=2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=994030515-24042003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=994030515-24042003><FONT face=Arial color=#0000ff 
size=2>John</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Razdan, Rajender 
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, April 24, 2003 7:44 
  AM<BR><B>To:</B> John Drake; 'George Newsome'; Brungard, Deborah A, 
  ALABS<BR><B>Cc:</B> Stephen Trowbridge; [email-masked]; 
  [email-masked]; Wijnen, Bert (Bert); [email-masked]; 
  [email-masked]; Ron Bonica (E-mail); [email-masked]<BR><B>Subject:</B> RE: 
  Proposed response to the Liaison Statement on LMP Link Verifi 
  cation<BR><BR></FONT></DIV>
  <P><FONT size=2>John,</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; I don't think anyone out here is stipulating that 
  deployment of</FONT> <BR><FONT size=2>GMPLS is gated by the deployment of 
  G.7714.1. Your suggestion below</FONT> <BR><FONT size=2>amounts to saying that 
  we will use the LMP discovery trace byte</FONT> <BR><FONT size=2>pattern for 
  discovery purposes in GMPLS and change to G.7714.1</FONT> <BR><FONT 
  size=2>pattern when dealing with systems where G.7714.1 is deployed. 
  But</FONT> <BR><FONT size=2>that is precisely what I'm arguing against the 
  need for doing. As</FONT> <BR><FONT size=2>I said in one of my earlier emails, 
  it would seem common-sense to</FONT> <BR><FONT size=2>avoid having to support 
  two different message formats, especially</FONT> <BR><FONT size=2>if it can be 
  avoided.</FONT> </P>
  <P><FONT size=2>&nbsp; So let me re-paraphrase my original question, which I 
  have yet to</FONT> <BR><FONT size=2>see anyone answer: Is there anything about 
  the G.7714.1 discovery </FONT><BR><FONT size=2>trace message that makes it 
  unsuitable for your discovery protocol </FONT><BR><FONT size=2>within LMP? If 
  not, I don't see what problem there is in changing </FONT><BR><FONT size=2>the 
  LMP trace message format to match that of G.7714.1. It seems</FONT> <BR><FONT 
  size=2>to me that an earnest attempt to match these formats has already</FONT> 
  <BR><FONT size=2>been undertaken in the LMP bootstrap draft document. So what 
  then</FONT> <BR><FONT size=2>is the problem with doing the same for the LMP 
  trace draft document?</FONT> </P>
  <P><FONT size=2>Rajender</FONT> </P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: John 
  Drake [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
  <BR><FONT size=2>Sent: Thursday, April 24, 2003 9:50 AM</FONT> <BR><FONT 
  size=2>To: 'George Newsome'; Brungard, Deborah A, ALABS</FONT> <BR><FONT 
  size=2>Cc: Stephen Trowbridge; [email-masked];</FONT> 
  <BR><FONT size=2>[email-masked]; Wijnen, Bert (Bert);</FONT> 
  <BR><FONT size=2>[email-masked]; [email-masked]; Ron Bonica 
  (E-mail);</FONT> <BR><FONT size=2>[email-masked]</FONT> <BR><FONT 
  size=2>Subject: RE: Proposed response to the Liaison Statement on LMP 
  Link</FONT> <BR><FONT size=2>Verifi cation</FONT> </P><BR>
  <P><FONT size=2>George,</FONT> </P>
  <P><FONT size=2>The LMP test procedure is used to exchange GMPLS control plane 
  identifiers</FONT> <BR><FONT size=2>in support of</FONT> <BR><FONT 
  size=2>subsequent RSVP-TE signalling and it will be needed in networks that 
  don't</FONT> <BR><FONT size=2>support G.7714.1,</FONT> <BR><FONT size=2>such 
  as legacy SDH/SONET networks.&nbsp; I.e., I don't think one can 
  stipulate</FONT> <BR><FONT size=2>that deployment</FONT> <BR><FONT size=2>of 
  GMPLS is gated by the deployment of G.7714.1.</FONT> </P>
  <P><FONT size=2>It should also be noted that if the trace correlation 
  transport mechanism is</FONT> <BR><FONT size=2>used in a </FONT><BR><FONT 
  size=2>network in which G.7714.1 is deployed, then G.7714.1 will be 
  supported</FONT> <BR><FONT size=2>transparently;&nbsp; i.e.,</FONT> <BR><FONT 
  size=2>the G.7714.1 bit pattern will be used as the correlating bit 
  pattern.</FONT> </P>
  <P><FONT size=2>Thanks,</FONT> </P>
  <P><FONT size=2>John</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: George Newsome [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> <BR><FONT 
  size=2>&gt; Sent: Wednesday, April 23, 2003 9:24 AM</FONT> <BR><FONT 
  size=2>&gt; To: Brungard, Deborah A, ALABS</FONT> <BR><FONT size=2>&gt; Cc: 
  Stephen Trowbridge; [email-masked];</FONT> <BR><FONT 
  size=2>&gt; [email-masked]; Wijnen, Bert (Bert);</FONT> 
  <BR><FONT size=2>&gt; [email-masked]; [email-masked]; Ron Bonica 
  (E-mail);</FONT> <BR><FONT size=2>&gt; [email-masked]</FONT> <BR><FONT 
  size=2>&gt; Subject: Re: Proposed response to the Liaison Statement on LMP 
  Link</FONT> <BR><FONT size=2>&gt; Verification</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Deborah,</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I've snipped the earlier 
  stuff to reduce the length of this thread.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Brungard, Deborah A, ALABS wrote:</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; I support the liaison 
  response as proposed by Jonathan. It may be</FONT> <BR><FONT size=2>&gt; &gt; 
  helpful to add further clarification on the lmp-test format choice.</FONT> 
  <BR><FONT size=2>&gt; &gt; - suggest instead of saying "not restricted to 
  printable characters"</FONT> <BR><FONT size=2>&gt; &gt; which implies a choice 
  of character/format, say "LMP needs </FONT><BR><FONT size=2>&gt; to 
  support</FONT> <BR><FONT size=2>&gt; &gt; use of various types of control 
  plane identifiers and control plane</FONT> <BR><FONT size=2>&gt; &gt; 
  information, this information is not restricted to the use </FONT><BR><FONT 
  size=2>&gt; of printable</FONT> <BR><FONT size=2>&gt; &gt; characters. In 
  addition, the LMP message structures can not </FONT><BR><FONT size=2>&gt; be 
  supported</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Had you forgotten that G.7714.1 also supports 
  various </FONT><BR><FONT size=2>&gt; identifiers, and </FONT><BR><FONT 
  size=2>&gt; those identifiers are also not restricted to the printable set. 
  Its </FONT><BR><FONT size=2>&gt; coding that creates the printable set. LMP 
  messages can also </FONT><BR><FONT size=2>&gt; be passed </FONT><BR><FONT 
  size=2>&gt; as printable chars after coding.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; It would help if you were clear about which 
  messages and why. What I </FONT><BR><FONT size=2>&gt; read is just another 
  statement that says that LMP is different.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; by the G7714.1 
  format". And on the use of a format distinguishing</FONT> <BR><FONT 
  size=2>&gt; &gt; character, "LMP uses a prior negotiation before use, the 
  </FONT><BR><FONT size=2>&gt; in-band is not</FONT> <BR><FONT size=2>&gt; &gt; 
  used in parallel with other Jx applications. The </FONT><BR><FONT size=2>&gt; 
  correlation procedure</FONT> <BR><FONT size=2>&gt; &gt; will be used."</FONT> 
  <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; This is not a reason that LMP must be different - just a 
  </FONT><BR><FONT size=2>&gt; statement that </FONT><BR><FONT size=2>&gt; it 
  is.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; &gt; There seems to be three discussion threads (all related to 
  </FONT><BR><FONT size=2>&gt; lmp-test):</FONT> <BR><FONT size=2>&gt; &gt; - 
  confusion on lmp-test and G7714.1 as providing procedures for the</FONT> 
  <BR><FONT size=2>&gt; &gt; "same purpose"</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Its really hard for 
  me to see how the purpose of the inband </FONT><BR><FONT size=2>&gt; message 
  is </FONT><BR><FONT size=2>&gt; different, even if the whole application is 
  subtly different.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt; We discussed this both in T1X1 and ITU-T 
  Q14. Both the T1X1 liaison</FONT> <BR><FONT size=2>&gt; &gt; and the ITU-T Q14 
  liaison clearly identify the two procedures as</FONT> <BR><FONT size=2>&gt; 
  &gt; different applications. And the ITU-T Q14 liaison states </FONT><BR><FONT 
  size=2>&gt; "The control</FONT> <BR><FONT size=2>&gt; &gt; plane protocol 
  specific format is outside of the scope of </FONT><BR><FONT size=2>&gt; 
  G.7714.1. We</FONT> <BR><FONT size=2>&gt; &gt; invite IETF to propose the 
  message format suitable to exchange these</FONT> <BR><FONT size=2>&gt; &gt; 
  information elements." I don't view this thread of discussion as</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; You will recall that this was NOT about the Jx inband messages, 
  but </FONT><BR><FONT size=2>&gt; about the out of band exchanges that take 
  place after the inband </FONT><BR><FONT size=2>&gt; exchanges. This has 
  nothing to do with our current discussion </FONT><BR><FONT size=2>&gt; about 
  the </FONT><BR><FONT size=2>&gt; Jx bytes and the use of a single format for 
  those few messages.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt; impacting the liaison. Suggest continuing 
  this discussion </FONT><BR><FONT size=2>&gt; on transport</FONT> <BR><FONT 
  size=2>&gt; &gt; plane discovery vs. control plane discovery on the ITU 
  exploders as</FONT> <BR><FONT size=2>&gt; &gt; Q12/Q14 have already identified 
  a related work item.</FONT> <BR><FONT size=2>&gt; &gt; - confusion on why the 
  G7714.1 format can not be used for lmp-test</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; &gt; See my above suggestion. And note, many of today's 
  management</FONT> <BR><FONT size=2>&gt; &gt; interfaces (Corba) are not 
  constrained by TL1/printability. </FONT><BR><FONT size=2>&gt; 
  Performance,</FONT> <BR><FONT size=2>&gt; &gt; etc need to be 
  considered.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; It is very unfortuanate that you didn't bring 
  this up at the </FONT><BR><FONT size=2>&gt; proper time </FONT><BR><FONT 
  size=2>&gt; in Q14. The fact is that all the information needed is able 
  </FONT><BR><FONT size=2>&gt; to be passed </FONT><BR><FONT size=2>&gt; in the 
  printable set, and you agreed to it together with the </FONT><BR><FONT 
  size=2>&gt; rest of us.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; - equipment 
  functionality/configurations/impact on legacy</FONT> <BR><FONT size=2>&gt; 
  &gt; Again, this was identified in the T1X1 liaison. It doesn't impact</FONT> 
  <BR><FONT size=2>&gt; &gt; lmp-test (if we model the scope of lmp-test as 
  similar to </FONT><BR><FONT size=2>&gt; G7714.1, which</FONT> <BR><FONT 
  size=2>&gt; &gt; also does not address these topics). Suggest moving this 
  </FONT><BR><FONT size=2>&gt; discussion to</FONT> <BR><FONT size=2>&gt; &gt; 
  the ITU exploders (discussion on G7714.1 equipment impacts </FONT><BR><FONT 
  size=2>&gt; just kicked</FONT> <BR><FONT size=2>&gt; &gt; off this 
  morning).</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
  And I could not resist some comments (refer to db below), though I</FONT> 
  <BR><FONT size=2>&gt; &gt; will move on to the ITU exploder to continue 
  ;-)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Regards</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; George</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C30A76.14750D60--

Delivery-date: Thu, 24 Apr 2003 14:44:54 +0000
From: "Razdan, Rajender" <[email-masked]>
To: 'John Drake' <[email-masked]>, 'George Newsome' <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: Stephen Trowbridge <[email-masked]>,  [email-masked], [email-masked],  "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked],  [email-masked], "Ron Bonica (E-mail)" <[email-masked]>,  [email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Thu, 24 Apr 2003 10:43:49 -0400

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:[email-masked]]
Sent: Thursday, April 24, 2003 9:50 AM
To: 'George Newsome'; Brungard, Deborah A, ALABS
Cc: Stephen Trowbridge; [email-masked];
[email-masked]; Wijnen, Bert (Bert);
[email-masked]; [email-masked]; Ron Bonica (E-mail);
[email-masked]
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:[email-masked]]
> Sent: Wednesday, April 23, 2003 9:24 AM
> To: Brungard, Deborah A, ALABS
> Cc: Stephen Trowbridge; [email-masked];
> [email-masked]; Wijnen, Bert (Bert);
> [email-masked]; [email-masked]; Ron Bonica (E-mail);
> [email-masked]
> 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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Proposed response to the Liaison Statement on LMP Link Verifi cation</TITLE>
</HEAD>
<BODY>

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

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

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

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

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: John Drake [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, April 24, 2003 9:50 AM</FONT>
<BR><FONT SIZE=2>To: 'George Newsome'; Brungard, Deborah A, ALABS</FONT>
<BR><FONT SIZE=2>Cc: Stephen Trowbridge; [email-masked];</FONT>
<BR><FONT SIZE=2>[email-masked]; Wijnen, Bert (Bert);</FONT>
<BR><FONT SIZE=2>[email-masked]; [email-masked]; Ron Bonica (E-mail);</FONT>
<BR><FONT SIZE=2>[email-masked]</FONT>
<BR><FONT SIZE=2>Subject: RE: Proposed response to the Liaison Statement on LMP Link</FONT>
<BR><FONT SIZE=2>Verifi cation</FONT>
</P>
<BR>

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

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

<P><FONT SIZE=2>It should also be noted that if the trace correlation transport mechanism is</FONT>
<BR><FONT SIZE=2>used in a </FONT>
<BR><FONT SIZE=2>network in which G.7714.1 is deployed, then G.7714.1 will be supported</FONT>
<BR><FONT SIZE=2>transparently;&nbsp; i.e.,</FONT>
<BR><FONT SIZE=2>the G.7714.1 bit pattern will be used as the correlating bit pattern.</FONT>
</P>

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

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

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

</BODY>
</HTML>
------_=_NextPart_001_01C30A6F.EAA86D20--

Delivery-date: Thu, 24 Apr 2003 13:53:02 +0000
From: John Drake <[email-masked]>
To: 'George Newsome' <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: Stephen Trowbridge <[email-masked]>,  [email-masked], [email-masked],  "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked],  [email-masked], "Ron Bonica (E-mail)" <[email-masked]>,  [email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Thu, 24 Apr 2003 06:49:47 -0700

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:[email-masked]]
> Sent: Wednesday, April 23, 2003 9:24 AM
> To: Brungard, Deborah A, ALABS
> Cc: Stephen Trowbridge; [email-masked];
> [email-masked]; Wijnen, Bert (Bert);
> [email-masked]; [email-masked]; Ron Bonica (E-mail);
> [email-masked]
> 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
> 
> 
> 
> 

Delivery-date: Wed, 23 Apr 2003 16:27:58 +0000
Date: Wed, 23 Apr 2003 12:23:51 -0400
From: George Newsome <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
CC: Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked], "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
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

Delivery-date: Wed, 23 Apr 2003 16:04:59 +0000
From: John Drake <[email-masked]>
To: 'Dieter Beller' <[email-masked]>
Cc: "'Brungard, Deborah A, ALABS'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked],  George Newsome <[email-masked]>, [email-masked],  "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked],  [email-masked], "Ron Bonica (E-mail)" <[email-masked]>,  [email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Wed, 23 Apr 2003 09:04:08 -0700

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.

Delivery-date: Wed, 23 Apr 2003 15:44:53 +0000
Date: Wed, 23 Apr 2003 17:43:00 +0200
From: Dieter Beller <[email-masked]>
Organization: Alcatel SEL AG, OND Stuttgart, Germany
To: John Drake <[email-masked]>
CC: "'Brungard, Deborah A, ALABS'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], George Newsome <[email-masked]>, [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked], "Ron Bonica (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation

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

Delivery-date: Wed, 23 Apr 2003 15:04:47 +0000
From: John Drake <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked]
Cc: George Newsome <[email-masked]>, [email-masked],  "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked],  [email-masked], "Ron Bonica (E-mail)" <[email-masked]>,  [email-masked]
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verifi cation
Date: Wed, 23 Apr 2003 08:03:40 -0700

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 

Delivery-date: Wed, 23 Apr 2003 14:20:22 +0000
content-class: urn:content-classes:message
Subject: RE: Proposed response to the Liaison Statement on LMP Link Verification
Date: Wed, 23 Apr 2003 10:17:46 -0400
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Stephen Trowbridge" <[email-masked]>, <[email-masked]>
Cc: "George Newsome" <[email-masked]>, <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Ron Bonica (E-mail)" <[email-masked]>, <[email-masked]>

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:[email-masked]]
Sent: Tuesday, April 22, 2003 11:45 AM
To: [email-masked]
Cc: 'George Newsome'; [email-masked]; 'Wijnen, Bert
(Bert)'; [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]; 'Ron Bonica (E-mail)'; [email-masked]
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: [email-masked]
> > [mailto:[email-masked]] On Behalf Of George Newsome
> > Sent: Monday, April 21, 2003 12:27 PM
> > To: [email-masked]; =
[email-masked]
> > Cc: Wijnen, Bert (Bert); [email-masked]; Deborah Brungard
> > (E-mail); Steve Trowbridge (E-mail); [email-masked];
> > 'Ron Bonica (E-mail)'; [email-masked]
> > 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:[email-masked]]
> > >>Sent: vrijdag 18 april 2003 22:25
> > >>To: [email-masked]
> > >>Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked];
> > >>[email-masked]; [email-masked]
> > >>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.
> > >>
> >
> > 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
> > >>>
> > >><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.
> > >>
> > >> 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.

Delivery-date: Tue, 22 Apr 2003 19:54:11 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Dimitrios Pendarakis <[email-masked]>, "Dimitri Papadimitriou (E-mail)" <[email-masked]>, "Steven M. Bellovin" <[email-masked]>
Cc: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: RE: draft-ietf-ccamp-gmpls-architecture 
Date: Tue, 22 Apr 2003 21:49:03 +0200

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:[email-masked]]
> Sent: dinsdag 22 april 2003 18:31
> To: Dimitrios Pendarakis
> Cc: 'Wijnen, Bert (Bert)'; Ccamp-wg (E-mail); [email-masked]
> Subject: Re: draft-ietf-ccamp-gmpls-architecture 
> 
> 
> In message 
> <[email-masked]>, 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:[email-masked]]
> >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:[email-masked]]
> >Sent: woensdag 16 april 2003 18:20
> >To: [email-masked]
> >Cc: [email-masked]
> >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)
> 
> 

Delivery-date: Tue, 22 Apr 2003 15:56:22 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Ron Bonica <[email-masked]>, "Ccamp-wg (E-mail)" <[email-masked]>
Subject: RE: draft-ietf-ccamp-tracereq-01.txt
Date: Tue, 22 Apr 2003 17:54:57 +0200

Some comments from my side inline

> > -----Original Message-----
> > From: Ron Bonica [mailto:[email-masked]]
> > 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: [email-masked] [mailto:[email-masked]]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)
> > > >            <draft-ietf-ccamp-tracereq-01.txt>
> > > >         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 <foo>" 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
> > 
> 

Delivery-date: Tue, 22 Apr 2003 15:50:51 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Ron Bonica <[email-masked]>, "Ccamp-wg (E-mail)" <[email-masked]>
Subject: RE: draft-ietf-ccamp-tracereq-01.txt
Date: Tue, 22 Apr 2003 17:47:44 +0200

Thjanks Ron, I am checking with the people who raised the issues.

Thanks,
Bert 

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]]
> 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: [email-masked] [mailto:[email-masked]]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)
> > >            <draft-ietf-ccamp-tracereq-01.txt>
> > >         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 <foo>" 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
> 

Delivery-date: Tue, 22 Apr 2003 15:47:58 +0000
Date: Tue, 22 Apr 2003 09:44:37 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
CC: "'George Newsome'" <[email-masked]>, [email-masked], "'Wijnen, Bert (Bert)'" <[email-masked]>, [email-masked], "'Deborah Brungard (E-mail)'" <[email-masked]>, [email-masked], "'Ron Bonica (E-mail)'" <[email-masked]>, [email-masked]
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.

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: [email-masked]
> > [mailto:[email-masked]] On Behalf Of George Newsome
> > Sent: Monday, April 21, 2003 12:27 PM
> > To: [email-masked]; [email-masked]
> > Cc: Wijnen, Bert (Bert); [email-masked]; Deborah Brungard
> > (E-mail); Steve Trowbridge (E-mail); [email-masked];
> > 'Ron Bonica (E-mail)'; [email-masked]
> > 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:[email-masked]]
> > >>Sent: vrijdag 18 april 2003 22:25
> > >>To: [email-masked]
> > >>Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked];
> > >>[email-masked]; [email-masked]
> > >>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.
> > >>
> >
> > 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
> > >>>
> > >><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.
> > >>
> > >> 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.

Delivery-date: Tue, 22 Apr 2003 15:12:52 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Razdan, Rajender'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "'Deborah Brungard (E-mail)'" <[email-masked]>, "'Steve Trowbridge (E-mail)'" <[email-masked]>
Cc: [email-masked], "'Ron Bonica (E-mail)'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Proposed response to the T1X1 Liaison Statement on LMP Link V erification
Date: Tue, 22 Apr 2003 11:11:03 -0400

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:[email-masked]]
Sent: Tuesday, April 22, 2003 10:38 AM
To: [email-masked]'; 'Wijnen, Bert (Bert)'; [email-masked]; 'Deborah Brungard (E-mail)'; 'Steve Trowbridge (E-mail)'
Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked]; [email-masked]
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:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, April 22, 2003 12:27 AM 
To: Razdan, Rajender; 'Wijnen, Bert (Bert)'; [email-masked]; 
'Deborah Brungard (E-mail)'; 'Steve Trowbridge (E-mail)' 
Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked]; 
[email-masked] 
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:[email-masked] <mailto:[email-masked]> ] 
Rajender, 

>Sent: Monday, April 21, 2003 8:35 AM 
>To: 'Wijnen, Bert (Bert)'; [email-masked]; Deborah Brungard 
(E-mail); Steve 
>Trowbridge (E-mail) 
>Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked]; 
>[email-masked]; [email-masked] 
>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:[email-masked] <mailto:[email-masked]> ] 
>>Sent: Saturday, April 19, 2003 11:53 AM 
>>To: [email-masked]; Deborah Brungard (E-mail); Steve Trowbridge 
>>(E-mail) 
>>Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked]; 
>>[email-masked]; [email-masked]; 
>>[email-masked] 
>>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:[email-masked] <mailto:[email-masked]> ] 
>>> Sent: vrijdag 18 april 2003 22:25 
>>> To: [email-masked] 
>>> Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked]; 
>>> [email-masked]; [email-masked] 
>>> 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
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Proposed response to the T1X1 Liaison Statement on LMP Link Verification</TITLE>

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

------_=_NextPart_001_01C308E1.63E1CE74--

Delivery-date: Tue, 22 Apr 2003 14:40:24 +0000
From: "Razdan, Rajender" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, [email-masked], "'Deborah Brungard (E-mail)'" <[email-masked]>, "'Steve Trowbridge (E-mail)'" <[email-masked]>
Cc: [email-masked], "'Ron Bonica (E-mail)'" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Proposed response to the T1X1 Liaison Statement on LMP Link V erification
Date: Tue, 22 Apr 2003 10:37:59 -0400

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:[email-masked]]
Sent: Tuesday, April 22, 2003 12:27 AM
To: Razdan, Rajender; 'Wijnen, Bert (Bert)'; [email-masked];
'Deborah Brungard (E-mail)'; 'Steve Trowbridge (E-mail)'
Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked];
[email-masked]
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:[email-masked]]
Rajender,

>Sent: Monday, April 21, 2003 8:35 AM
>To: 'Wijnen, Bert (Bert)'; [email-masked]; Deborah Brungard
(E-mail); Steve
>Trowbridge (E-mail)
>Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked];
>[email-masked]; [email-masked]
>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:[email-masked]]
>>Sent: Saturday, April 19, 2003 11:53 AM
>>To: [email-masked]; Deborah Brungard (E-mail); Steve Trowbridge
>>(E-mail)
>>Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked];
>>[email-masked]; [email-masked];
>>[email-masked]
>>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:[email-masked]]
>>> Sent: vrijdag 18 april 2003 22:25
>>> To: [email-masked]
>>> Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked];
>>> [email-masked]; [email-masked]
>>> 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
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Proposed response to the T1X1 Liaison Statement on LMP Link =
Verification</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Jonathan,</FONT>
</P>

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

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Rajender</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jonathan Lang [<A =
HREF=3D"mailto:[email-masked]">mailto:Jonathan.Lang@Ri=
nconNetworks.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 22, 2003 12:27 AM</FONT>
<BR><FONT SIZE=3D2>To: Razdan, Rajender; 'Wijnen, Bert (Bert)'; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>'Deborah Brungard (E-mail)'; 'Steve Trowbridge =
(E-mail)'</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; 'Ron Bonica (E-mail)'; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Proposed response to the T1X1 Liaison =
Statement on LMP Link</FONT>
<BR><FONT SIZE=3D2>Verification</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Rajender,</FONT>
<BR><FONT SIZE=3D2>&nbsp; Please see inline for comment.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; (Note: I changed the subject header to reflect =
the correct liason.)</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Razdan, Rajender [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Rajender,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Sent: Monday, April 21, 2003 8:35 AM</FONT>
<BR><FONT SIZE=3D2>&gt;To: 'Wijnen, Bert (Bert)'; [email-masked]; =
Deborah Brungard</FONT>
<BR><FONT SIZE=3D2>(E-mail); Steve</FONT>
<BR><FONT SIZE=3D2>&gt;Trowbridge (E-mail)</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: [email-masked]; 'Ron Bonica (E-mail)'; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>&gt;[email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE: Proposed response to the Liaison =
Statement on ASON Routing</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I, for one, find the response very =
unsatisfactory. The T1X1, in</FONT>
<BR><FONT SIZE=3D2>&gt;their liaison statement, put in a lot of effort =
in explaining</FONT>
<BR><FONT SIZE=3D2>&gt;the rationale behind the discovery message =
format as specified</FONT>
<BR><FONT SIZE=3D2>&gt;in G.7714.1. The response to this liaison, while =
acknowledging</FONT>
<BR><FONT SIZE=3D2>&gt;that the context for the LMP test message and =
the G.7714.1</FONT>
<BR><FONT SIZE=3D2>&gt;discovery message are the same,</FONT>
<BR><FONT SIZE=3D2>Where in proposed response did we acknowledge the =
context is the same</FONT>
<BR><FONT SIZE=3D2>for g7714.1 and lmp?&nbsp; The intention of the =
response was to agree the</FONT>
<BR><FONT SIZE=3D2>&quot;application space&quot; and &quot;scenario of =
use&quot; are different from those</FONT>
<BR><FONT SIZE=3D2>described in the t1x1 liaison.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Jonathan</FONT>
</P>

<P><FONT SIZE=3D2>&gt;perfunctorily dismisses the</FONT>
<BR><FONT SIZE=3D2>&gt;need for alignment between the two documents =
(ITU Rec. G.7714.1</FONT>
<BR><FONT SIZE=3D2>&gt;and the LMP test draft). I would have thought =
that it is common</FONT>
<BR><FONT SIZE=3D2>&gt;sense to avoid having multiple formats for =
essentially the same</FONT>
<BR><FONT SIZE=3D2>&gt;application if that can be avoided. After all, =
it doesn't serve</FONT>
<BR><FONT SIZE=3D2>&gt;either the vendor community or the carriers to =
have to support</FONT>
<BR><FONT SIZE=3D2>&gt;multiple 'discovery' formats. I find it =
intriguing that while</FONT>
<BR><FONT SIZE=3D2>&gt;the LMP bootstrap draft has made attempts to =
align itself with</FONT>
<BR><FONT SIZE=3D2>&gt;G.7714.1 message format, that there should be so =
much resistance</FONT>
<BR><FONT SIZE=3D2>&gt;to doing the same with the LMP test draft =
document. It would be</FONT>
<BR><FONT SIZE=3D2>&gt;useful if the authors of the LMP test draft =
explain why there</FONT>
<BR><FONT SIZE=3D2>&gt;is such reluctance on their parts to align the =
LMP test message</FONT>
<BR><FONT SIZE=3D2>&gt;to match Rec. G.7714.1?</FONT>
<BR><FONT SIZE=3D2>&gt;regards,</FONT>
<BR><FONT SIZE=3D2>&gt;Rajender Razdan</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;From: Wijnen, Bert (Bert) [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt;&gt;Sent: Saturday, April 19, 2003 11:53 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;To: [email-masked]; Deborah Brungard =
(E-mail); Steve Trowbridge</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;(E-mail)</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Cc: [email-masked]; 'Ron Bonica =
(E-mail)'; [email-masked];</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;[email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Subject: RE: Proposed response to the =
Liaison Statement on ASON</FONT>
<BR><FONT SIZE=3D2>Routing</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Thnaks for the proposed response.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;It would be good if people could tell us if =
they agree or disagree</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;and if they disagree, then pls explain =
why.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;If the response is acceptable, then it =
sounds to me that at least</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;there would be no impact on the =
draft-ietf-ccamp-lmp-08.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;document, which is currently in IETF Last =
Call. Since we had split</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;the SONET/SDH material off into a separate =
document, my initial</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;evaluation made me think that the =
draft-ietf-ccamp-lmp-08.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;would not have any ITU-T/T1X1 =
issues/concerns. The liason statement</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;did refer to it a few times and so I started =
to worry, but from</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;the (proposed) response it seems there is no =
isseu.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Would be good to get at least confimration =
of that by the end</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;of the Last Call, and that is April =
24th.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Bert</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; From: Jonathan Lang [<A =
HREF=3D"mailto:[email-masked]">mailto:Jonathan.Lang@Ri=
nconNetworks.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; Sent: vrijdag 18 april 2003 =
22:25</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; Cc: [email-masked]; 'Ron Bonica =
(E-mail)'; [email-masked];</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; Subject: FW: Proposed response to the =
Liaison Statement on</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; ASON Routing</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; Here's a proposed response to the =
Liaison Statement from T1-X1 on</FONT>
<BR><FONT SIZE=3D2>LMP</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; Link Verification, posted April 11, =
2003.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; Jonathan &amp; Dimitri</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; =
--------------------------------------------------------------------</FO=
NT>
</P>

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

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

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

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

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

</BODY>
</HTML>
------_=_NextPart_001_01C308DC.C5299590--

Delivery-date: Tue, 22 Apr 2003 11:45:08 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 21 Apr 2003 21:56:04 +0000
Date: Mon, 21 Apr 2003 17:51:06 -0400
From: Ron Bonica <[email-masked]>
Subject: RE: draft-ietf-ccamp-tracereq-01.txt
To: [email-masked], [email-masked]

Bert,

Sorry to have taken so long to respond. I have been away on vacation.

Comments inline.....

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]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)
> >            <draft-ietf-ccamp-tracereq-01.txt>
> >         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 <foo>" 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.

Delivery-date: Mon, 21 Apr 2003 19:30:33 +0000
Date: Mon, 21 Apr 2003 15:26:45 -0400
From: George Newsome <[email-masked]>
To: [email-masked], [email-masked]
CC: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], "Deborah Brungard (E-mail)" <[email-masked]>, "Steve Trowbridge (E-mail)" <[email-masked]>, [email-masked], "'Ron Bonica (E-mail)'" <[email-masked]>, [email-masked]
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.

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:[email-masked]]
>>Sent: vrijdag 18 april 2003 22:25
>>To: [email-masked]
>>Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked];
>>[email-masked]; [email-masked]
>>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.
>> 

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

Delivery-date: Mon, 21 Apr 2003 15:40:41 +0000
From: "Razdan, Rajender" <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, [email-masked],  "Deborah Brungard (E-mail)" <[email-masked]>,  "Steve Trowbridge (E-mail)" <[email-masked]>
Cc: [email-masked], "'Ron Bonica (E-mail)'" <[email-masked]>, [email-masked],  [email-masked], [email-masked]
Subject: RE: Proposed response to the Liaison Statement on ASON Routing
Date: Mon, 21 Apr 2003 11:35:12 -0400

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:[email-masked]]
Sent: Saturday, April 19, 2003 11:53 AM
To: [email-masked]; Deborah Brungard (E-mail); Steve Trowbridge
(E-mail)
Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked];
[email-masked]; [email-masked];
[email-masked]
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:[email-masked]]
> Sent: vrijdag 18 april 2003 22:25
> To: [email-masked]
> Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked];
> [email-masked]; [email-masked]
> 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
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Proposed response to the Liaison Statement on ASON Routing</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=2>regards,</FONT>
<BR><FONT SIZE=2>Rajender Razdan</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Wijnen, Bert (Bert) [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Saturday, April 19, 2003 11:53 AM</FONT>
<BR><FONT SIZE=2>To: [email-masked]; Deborah Brungard (E-mail); Steve Trowbridge</FONT>
<BR><FONT SIZE=2>(E-mail)</FONT>
<BR><FONT SIZE=2>Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked];</FONT>
<BR><FONT SIZE=2>[email-masked]; [email-masked];</FONT>
<BR><FONT SIZE=2>[email-masked]</FONT>
<BR><FONT SIZE=2>Subject: RE: Proposed response to the Liaison Statement on ASON Routing</FONT>
</P>
<BR>

<P><FONT SIZE=2>Thnaks for the proposed response.</FONT>
</P>

<P><FONT SIZE=2>It would be good if people could tell us if they agree or disagree</FONT>
<BR><FONT SIZE=2>and if they disagree, then pls explain why.</FONT>
</P>

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

<P><FONT SIZE=2>Would be good to get at least confimration of that by the end </FONT>
<BR><FONT SIZE=2>of the Last Call, and that is April 24th.</FONT>
</P>

<P><FONT SIZE=2>Thanks,</FONT>
<BR><FONT SIZE=2>Bert </FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C3081B.993A4D60--

Delivery-date: Sat, 19 Apr 2003 15:55:57 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked], "Deborah Brungard (E-mail)" <[email-masked]>, "Steve Trowbridge (E-mail)" <[email-masked]>
Cc: [email-masked], "'Ron Bonica (E-mail)'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Proposed response to the Liaison Statement on ASON Routing
Date: Sat, 19 Apr 2003 17:52:45 +0200

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:[email-masked]]
> Sent: vrijdag 18 april 2003 22:25
> To: [email-masked]
> Cc: [email-masked]; 'Ron Bonica (E-mail)'; [email-masked];
> [email-masked]; [email-masked]
> 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.
> 
> 

Delivery-date: Sat, 19 Apr 2003 06:15:47 +0000
Date: Fri, 18 Apr 2003 23:10:24 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: [email-masked], "" <[email-masked]>, "" <[email-masked]>, Kireeti Kompella <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>
Subject: Response to the ITU-T SG 15 Liaison Statement on ASON Routing

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: [email-masked]

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, [email-masked]) 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:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/in
dex.html

Thank you for making this available.

Kireeti Kompella & Ron Bonica
CCAMP WG chairs

Delivery-date: Thu, 17 Apr 2003 22:09:46 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: RE: draft-ietf-ccamp-tracereq-01.txt
Date: Fri, 18 Apr 2003 00:04:52 +0200

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:[email-masked]]
> 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)
> >            <draft-ietf-ccamp-tracereq-01.txt>
> >         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 <foo>" 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.
> 
> 

Delivery-date: Thu, 17 Apr 2003 16:45:34 +0000
Date: Thu, 17 Apr 2003 18:41:16 +0200
From: [email-masked]
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: Re: FW: draft-ietf-ccamp-gmpls-architecture-05.txt

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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 17 Apr 2003 16:03:20 +0000
Date: Thu, 17 Apr 2003 10:01:09 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Varma, Eve L (Eve)'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Proposed response to the Liaison Statement on ASON Routing

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.

Delivery-date: Thu, 17 Apr 2003 15:50:49 +0000
Date: Thu, 17 Apr 2003 11:19:35 -0400 (EDT)
From: Scott  Bradner <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Fw: I-D ACTION:draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt
Cc: [email-masked], [email-masked]

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

> 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

Delivery-date: Thu, 17 Apr 2003 15:50:23 +0000
Date: Thu, 17 Apr 2003 17:47:06 +0200
From: [email-masked]
To: John Drake <[email-masked]>
Cc: "'Varma, Eve L (Eve)'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Proposed response to the Liaison Statement on ASON Routing

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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 17 Apr 2003 15:42:25 +0000
content-class: urn:content-classes:message
Subject: RE: Proposed response to the Liaison Statement on ASON Routing
Date: Thu, 17 Apr 2003 10:41:25 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>

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

Delivery-date: Thu, 17 Apr 2003 15:39:43 +0000
From: John Drake <[email-masked]>
To: "'Varma, Eve L (Eve)'" <[email-masked]>, 'Kireeti Kompella' <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Proposed response to the Liaison Statement on ASON Routing
Date: Thu, 17 Apr 2003 08:37:55 -0700

That would be fine.

> -----Original Message-----
> From: Varma, Eve L (Eve) [mailto:[email-masked]]
> Sent: Thursday, April 17, 2003 8:37 AM
> To: John Drake; Varma, Eve L (Eve); 'Kireeti Kompella'; Wijnen, Bert
> (Bert)
> Cc: [email-masked]; [email-masked]
> 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:[email-masked]]
> Sent: Thursday, April 17, 2003 11:32 AM
> To: 'Varma, Eve L (Eve)'; 'Kireeti Kompella'; Wijnen, Bert (Bert)
> Cc: [email-masked]; [email-masked]
> 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.   
> 

Delivery-date: Thu, 17 Apr 2003 15:38:30 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "Varma, Eve L (Eve)" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Proposed response to the Liaison Statement on ASON Routing
Date: Thu, 17 Apr 2003 11:36:42 -0400

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:[email-masked]]
Sent: Thursday, April 17, 2003 11:32 AM
To: 'Varma, Eve L (Eve)'; 'Kireeti Kompella'; Wijnen, Bert (Bert)
Cc: [email-masked]; [email-masked]
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.   

Delivery-date: Thu, 17 Apr 2003 15:33:01 +0000
From: John Drake <[email-masked]>
To: "'Varma, Eve L (Eve)'" <[email-masked]>, 'Kireeti Kompella' <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Proposed response to the Liaison Statement on ASON Routing
Date: Thu, 17 Apr 2003 08:31:55 -0700

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.   

Delivery-date: Thu, 17 Apr 2003 15:27:47 +0000
Date: Thu, 17 Apr 2003 10:57:19 -0400 (EDT)
From: Scott  Bradner <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Proposed response to the Liaison Statement on ASON Routing
Cc: [email-masked], [email-masked]

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

> 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

Delivery-date: Thu, 17 Apr 2003 15:26:38 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Cc: "Russ Housley (E-mail)" <[email-masked]>
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 

Delivery-date: Thu, 17 Apr 2003 15:18:19 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Proposed response to the Liaison Statement on ASON Routing
Date: Thu, 17 Apr 2003 11:17:15 -0400

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:[email-masked]]
Sent: Thursday, April 17, 2003 10:56 AM
To: Wijnen, Bert (Bert)
Cc: [email-masked]; [email-masked]
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.

Delivery-date: Thu, 17 Apr 2003 15:14:16 +0000
Date: Thu, 17 Apr 2003 08:12:45 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: [email-masked], "" <[email-masked]>
Subject: Re: Fw: I-D ACTION:draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt

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.

Delivery-date: Thu, 17 Apr 2003 14:58:39 +0000
Date: Thu, 17 Apr 2003 07:56:10 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: [email-masked], "" <[email-masked]>
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: [email-masked]
Delivery-date: Thu, 17 Apr 2003 13:47:37 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>
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: <[email-masked]>
To: <IETF-Announce: ;>
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

Delivery-date: Thu, 17 Apr 2003 13:45:44 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Proposed response to the Liaison Statement on ASON Routing
Date: Thu, 17 Apr 2003 15:41:52 +0200

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:[email-masked]]
> Sent: vrijdag 11 april 2003 20:01
> To: [email-masked]
> Cc: [email-masked]
> 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, 
> [email-masked]) 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:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/in
dex.html

Thank you for making this available.

Kireeti Kompella & Ron Bonica
CCAMP WG chairs

Delivery-date: Wed, 16 Apr 2003 19:12:32 +0000
From: Dimitrios Pendarakis <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, "Ccamp-wg (E-mail)"  <[email-masked]>
Cc: "Steve Bellovin (E-mail)" <[email-masked]>
Subject: RE: draft-ietf-ccamp-gmpls-architecture
Date: Wed, 16 Apr 2003 15:04:38 -0400

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:[email-masked]]
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:[email-masked]]
Sent: woensdag 16 april 2003 18:20
To: [email-masked]
Cc: [email-masked]
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.
**********************************************************************

Delivery-date: Wed, 16 Apr 2003 16:42:07 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Cc: "Steve Bellovin (E-mail)" <[email-masked]>
Subject: FW: draft-ietf-ccamp-gmpls-architecture
Date: Wed, 16 Apr 2003 18:37:56 +0200

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:[email-masked]]
Sent: woensdag 16 april 2003 18:20
To: [email-masked]
Cc: [email-masked]
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.

Delivery-date: Wed, 16 Apr 2003 13:36:20 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: draft-ietf-ccamp-gmpls-architecture-05.txt
Date: Wed, 16 Apr 2003 15:30:25 +0200

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.

Delivery-date: Wed, 16 Apr 2003 13:35:57 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: draft-ietf-ccamp-tracereq-01.txt
Date: Wed, 16 Apr 2003 15:30:26 +0200

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)
>            <draft-ietf-ccamp-tracereq-01.txt>
>         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 <foo>" 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.

Delivery-date: Tue, 15 Apr 2003 13:27:20 +0000
From: Edward Harrison <[email-masked]>
To: 'Anca Zamfir' <[email-masked]>, Yakov Rekhter <[email-masked]>
Cc: Sameer K <[email-masked]>, [email-masked], [email-masked]
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

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:[email-masked]]
Sent: 10 March 2003 15:54
To: Yakov Rekhter
Cc: Sameer K; [email-masked]; [email-masked]
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 <[email-masked]> 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: [email-masked]
> > 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: [email-masked]
2000 Innovation Dr., Kanata          tel#: (613) 254-3484
Ontario, CANADA  K2K 3E8         fax:  (613) 254-3717

Delivery-date: Mon, 14 Apr 2003 14:59:19 +0000
content-class: urn:content-classes:message
Subject: RE: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
Date: Mon, 14 Apr 2003 10:57:02 -0400
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 14, 2003 5:57 AM
To: Brungard, Deborah A, ALABS
Cc: Wijnen, Bert (Bert); Dimitri Papadimitriou; [email-masked];
[email-masked]; [email-masked]
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; =
[email-masked]
> Cc: [email-masked]; [email-masked]
> 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:[email-masked]]
> Sent: Tuesday, March 18, 2003 6:13 PM
> To: Dimitri Papadimitriou; [email-masked]
> Cc: [email-masked]
> 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

Delivery-date: Mon, 14 Apr 2003 10:09:08 +0000
Date: Mon, 14 Apr 2003 11:57:12 +0200
From: [email-masked]
Reply-To: [email-masked]
Organization: OND
To: "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt

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; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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:[email-masked]]
> Sent: Tuesday, March 18, 2003 6:13 PM
> To: Dimitri Papadimitriou; [email-masked]
> Cc: [email-masked]
> 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:<IMG SRC="http://www.usa.alcatel.com/images/logo/alcatel.gif">;OND- Product Strategy
adr:;;via Trento 30;vimercate;Milano;20059;Italy
version:2.1
email;internet:[email-masked]
title:Product Manager
x-mozilla-cpt:;-200
fn:Sergio Belotti
end:vcard

--------------0B609BA75BEE99BDCA813F0F--

Delivery-date: Fri, 11 Apr 2003 18:02:44 +0000
Date: Fri, 11 Apr 2003 11:01:12 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: [email-masked]
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, [email-masked]) 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:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/in
dex.html

Thank you for making this available.

Kireeti Kompella & Ron Bonica
CCAMP WG chairs

Delivery-date: Fri, 11 Apr 2003 17:52:44 +0000
Date: Fri, 11 Apr 2003 10:50:10 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>
Subject: RE: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt

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.

Delivery-date: Fri, 11 Apr 2003 16:50:15 +0000
content-class: urn:content-classes:message
Subject: RE: [T1X1.5] RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
Date: Fri, 11 Apr 2003 12:47:24 -0400
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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; [email-masked]
Cc: [email-masked]; [email-masked]
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:[email-masked]]
Sent: Tuesday, March 18, 2003 6:13 PM
To: Dimitri Papadimitriou; [email-masked]
Cc: [email-masked]
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

Delivery-date: Fri, 11 Apr 2003 03:25:51 +0000
Date: Thu, 10 Apr 2003 23:20:05 -0400
From: Ron Bonica <[email-masked]>
Subject: FW: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, 2003)
To: [email-masked]

FYI

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]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: [email-masked]
Delivery-date: Thu, 10 Apr 2003 18:37:59 +0000
Message-Id: <[email-masked]>
To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Link Management Protocol (LMP) to Proposed Standard
Reply-to: [email-masked]
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) 
<draft-ietf-ccamp-lmp-08.txt> 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 
[email-masked] or [email-masked] mailing lists by 2003-4-24.

Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-08.txt

Delivery-date: Tue, 08 Apr 2003 14:36:44 +0000
From: [email-masked]
Reply-To: [email-masked]
To: 
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-tracereq-01.txt
Date: Tue, 8 Apr 2003 15:03:55 +0100 

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:
	[email-masked].
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="[email-masked]"

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

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

Delivery-date: Tue, 08 Apr 2003 14:07:07 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 08 Apr 2003 13:44:20 +0000
From: [email-masked]
To: [email-masked], [email-masked]
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 <listname>[email-masked] 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:[email-masked]]
> Sent: Monday, April 07, 2003 9:55 PM
> To: 'Jonathan Lang'; [email-masked]; [email-masked]'
> 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 <MESSAGE_ID> 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:[email-masked]]
> Sent: Monday, April 07, 2003 10:22 PM
> To: 'Gudipalli, Sugadeesh'; [email-masked]; [email-masked]
> Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08)
> 
> 
> Sugadeesh,
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Gudipalli, Sugadeesh
> > Sent: Monday, April 07, 2003 5:16 AM
> > To: [email-masked]'; [email-masked]'
> > 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

Delivery-date: Tue, 08 Apr 2003 13:24:47 +0000
From: "Jonathan Lang" <[email-masked]>
To: "'Gudipalli, Sugadeesh'" <[email-masked]>, <[email-masked]>
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 <listname>[email-masked] 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:[email-masked]]
> Sent: Monday, April 07, 2003 9:55 PM
> To: 'Jonathan Lang'; [email-masked]; [email-masked]'
> 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 <MESSAGE_ID> 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:[email-masked]]
> Sent: Monday, April 07, 2003 10:22 PM
> To: 'Gudipalli, Sugadeesh'; [email-masked]; [email-masked]
> Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08)
> 
> 
> Sugadeesh,
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Gudipalli, Sugadeesh
> > Sent: Monday, April 07, 2003 5:16 AM
> > To: [email-masked]'; [email-masked]'
> > 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

Delivery-date: Tue, 08 Apr 2003 04:55:36 +0000
From: "Gudipalli, Sugadeesh" <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: questions  in LMP (draft-ietf-ccamp-lmp-08)
Date: Tue, 8 Apr 2003 00:55:24 -0400 

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 <MESSAGE_ID> 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:[email-masked]]
Sent: Monday, April 07, 2003 10:22 PM
To: 'Gudipalli, Sugadeesh'; [email-masked]; [email-masked]
Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08)

Sugadeesh,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Gudipalli, Sugadeesh
> Sent: Monday, April 07, 2003 5:16 AM
> To: [email-masked]'; [email-masked]'
> 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

Delivery-date: Tue, 08 Apr 2003 03:54:31 +0000
Date: Mon, 7 Apr 2003 23:52:46 -0400 (EDT)
From: Jim Boyle <[email-masked]>
To: [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>
cc: [email-masked]
Subject: Notice of WG last call on Diff Serv TE Protocol draft in TEWG

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

Delivery-date: Mon, 07 Apr 2003 16:55:47 +0000
From: "Jonathan Lang" <[email-masked]>
To: "'Gudipalli, Sugadeesh'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: questions  in LMP (draft-ietf-ccamp-lmp-08)
Date: Mon, 7 Apr 2003 09:52:22 -0700

Sugadeesh,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Gudipalli, Sugadeesh
> Sent: Monday, April 07, 2003 5:16 AM
> To: [email-masked]'; [email-masked]'
> 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

Delivery-date: Mon, 07 Apr 2003 12:18:46 +0000
From: "Gudipalli, Sugadeesh" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "Gudipalli, Sugadeesh" <[email-masked]>
Subject: questions  in LMP (draft-ietf-ccamp-lmp-08)
Date: Mon, 7 Apr 2003 08:15:41 -0400 

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

Delivery-date: Sun, 06 Apr 2003 02:44:04 +0000
Date: Sat, 05 Apr 2003 21:41:16 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: AD review for: draft-ietf-ccamp-tracereq-00.txt
To: "Wijnen, Bert (Bert)" <[email-masked]>, "Ccamp-wg (E-mail)" <[email-masked]>

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: [email-masked] [mailto:[email-masked]]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
>

Delivery-date: Fri, 04 Apr 2003 07:47:16 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: AD review for: draft-ietf-ccamp-tracereq-00.txt
Date: Fri, 4 Apr 2003 17:45:31 +0200 

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 

Delivery-date: Fri, 04 Apr 2003 04:26:38 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: AD review of draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
Date: Fri, 4 Apr 2003 14:25:49 +0200 

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 

Delivery-date: Fri, 04 Apr 2003 03:44:06 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 03 Apr 2003 07:40:12 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
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 

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:[email-masked]]
Sent: donderdag 3 april 2003 16:55
Cc: RFC Editor; Internet Architecture Board; [email-masked]
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'
<draft-ietf-ccamp-gmpls-sonet-sdh-08.txt> 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: [email-masked]
Delivery-date: Thu, 03 Apr 2003 06:59:42 -0800
Message-Id: <[email-masked]>
To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
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'
<draft-ietf-ccamp-gmpls-sonet-sdh-08.txt> 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: [email-masked]
Delivery-date: Wed, 02 Apr 2003 11:55:59 -0800
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Last call in MPLS WG on TC MIB
Date: Wed, 02 Apr 2003 14:54:32 -0500
From: George Swallow <[email-masked]>

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 ([email-masked]).

Thanks,

...George

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

Delivery-date: Tue, 01 Apr 2003 10:44:57 -0800
Date: Tue, 01 Apr 2003 13:42:19 -0500
From: "Cheng-Yin Lee" <[email-masked]>
Reply-To: [email-masked]
To: Ron Bonica <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: IETF 56 CCAMP minutes - UPDATE

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

Delivery-date: Tue, 01 Apr 2003 08:05:41 -0800
Date: Tue, 01 Apr 2003 11:03:07 -0500
From: Ron Bonica <[email-masked]>
Subject: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03
To: [email-masked]

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