Subject: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-06.txt

From: [email-masked]
Date: Wed, 18 Apr 2007 15:50:02 -0400

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		: Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks
	Author(s)	: K. Shiomoto, et al.
	Filename	: draft-ietf-ccamp-gmpls-addressing-06.txt
	Pages		: 21
	Date		: 2007-4-18
	
This document clarifies the use of addresses in Generalized
   Multi-Protocol Label Switching (GMPLS) networks. The aim is to
   facilitate better interworking of GMPLS-capable Label Switching
   Routers (LSRs). The document is based on experience gained in
   implementation, interoperability testing, and deployment.

   The document describes how to interpret address and identifier fields
   within GMPLS protocols, and how to choose which addresses to set in
   those fields for specific control plane usage models. It also
   discusses how to handle IPv6 sources and destinations in the MPLS and
   GMPLS Traffic Engineering (TE) Management Information Base (MIB)
   modules.

   This document does not define new procedures of processes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-addressing-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 22 Apr 2007 17:00:29 +0100

Hi,

After some delay, this I-D has been updated as requested by the working 
group to move it on to the Informational track.

As well as the obvious change to the front page, all of the 2119 language 
has been removed and references have been inserted to the definitive 
material in other RFCs.

The Abstract now clearly states "This document does not define new 
procedures of processes."

And the Introduction contains...

   This document does not define new procedures of processes and the
   protocol specifications listed above should be treated as definitive.

I think this should be compatible with the working group's wishes, and I 
think that the I-D is now in relatively good shape to be taken to the IESG, 
so...

This begins a two week working group last call. Please send your comments to 
the mailing list.

The last call will end at 6pm GMT on Sunday 6th May 2007.

Thanks,
Adrian

---

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Thu, 26 Apr 2007 17:54:15 +0200

Hi all.

Just a few comments about the ID.

In the abstract and the introduction, the phrase "facilitate better interworking" reads weird to me. I'm not a native English speaker, but wouldn't "facilitate interworking" be more appropriate?

About the IGP terminology, in OSPF and IS-IS RFCs, "OSPF-TE" and "IS-IS-TE" terms are reserved for MPLS-TE extensions (RFC 3630 and 3784) while GMPLS ones (RFC 4203 and 4205) are rather named "GMPLS OSPF" and "GMPLS IS-IS". I believe the ID should follow this terminology more closely.

In section 5.1.1:
   "An unnumbered TE
   link end network-wide identifier is comprised of a TE Router ID
   associated with the link local end, followed by the link local
   identifier"
-> The intent on (TE Router ID, link local ID) is clear to anyone familiar with the context, but I also feel -- due to my mother tongue? -- that this might also be misread as (TE Router ID, link local end, link local ID), which does not make any sense. However, considering this is a clarification document, maybe replacing "associated with" by "corresponding to" or just recalling it's a pair would do the trick.

In section 6.1.2:
   "If the interface was intended to be used as an outgoing
   interface, the path will be broken an may be impossible to resolve."
-> s/an/and/
-> "The path will be broken" looks like a postulate and needs a clarification.

   "This a loose hop that identifies an interface should always identify
   the incoming TE link in the data plane."
-> Something's missing or "This" should be removed.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel

Hi,

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Apr 2007 17:25:58 +0100

Good comments. Thanks.

> In the abstract and the introduction, the phrase "facilitate
> better interworking" reads weird to me. I'm not a native
> English speaker, but wouldn't "facilitate interworking" be
> more appropriate?

OK

> About the IGP terminology, in OSPF and IS-IS RFCs,
> "OSPF-TE" and "IS-IS-TE" terms are reserved for
> MPLS-TE extensions (RFC 3630 and 3784) while
> GMPLS ones (RFC 4203 and 4205) are rather named
> "GMPLS OSPF" and "GMPLS IS-IS". I believe the ID
> should follow this terminology more closely.

No objection.

> The intent on (TE Router ID, link local ID) is clear to anyone
> familiar with the context, but I also feel -- due to my mother
> tongue? -- that this might also be misread as (TE Router ID,
> link local end, link local ID), which does not make any sense.
> However, considering this is a clarification document, maybe
> replacing "associated with" by "corresponding to" or just
> recalling it's a pair would do the trick.

Try...

An unnumbered TE link end network-wide identifier is comprised
of two elements:
- a TE Router ID that is associated with the link local end
- the link local identifier.

> s/an/and/

OK

> "The path will be broken" looks like a postulate and needs a 
> clarification.

Yes, the sentence and the path are broken :-)

Try...

If the interface was intended to be used as an outgoing
interface, the computed path may be unsatisfactory and
the explicit route in the ERO may be impossible to resolve.

>"This a loose hop that identifies an interface should always
> identify the incoming TE link in the data plane."
>
> Something's missing or "This" should be removed.

s/This/Thus,/

Cheers,
Adrian