Subject: ason-routing-reqts: issue 1 addressing

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Mon, 15 Mar 2004 13:29:21 -0600

As noted in the CCAMP minutes and the DT's presentation, the ASON routing DT had three issues regarding GMPLS support for which they lacked agreement and request support of the WG. The issues are identified in Section 7 (Conclusions) of the draft:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt

I will post three separate email threads to cover each issue. The first issue is on address reachability. The following is the text from the draft:

Some members of the Design Team noted that reachability information (as described in Section 4.5.3) may be advertised as a set of UNI Transport Resource address prefixes (assigned and selected consistently in their applicability scope). These members of the Design Team raised a concern that existing methods of advertising reachability may need to be examined (on a per-protocol basis) to determine if they are also applicable for UNI Transport Resource addresses. They invite CCAMP discussion on this aspect.
Deborah

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Thu, 18 Mar 2004 15:26:57 -0500

Hi,

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Thursday, March 18, 2004 2:47 PM
To: Ong, Lyndon
Cc: 'Brungard, Deborah A, ALABS'; [email-masked]
Subject: RE: ason-routing-reqts: issue 1 addressing

Hi Lyndon,

On Tue, 16 Mar 2004, Ong, Lyndon wrote:

> Hi Folks,
>
> Let me kick off some discussion on issue 1 by noting some of the
> concerns with using existing methods of advertising reachability
> for this purpose:
>
> 1) the client system may not be an IP system, but another transport
> device with an IP control interface - for example, an ADM (add-drop
> multiplexer) acting as a client to an optical network.  Advertising
> reachability using normal means might imply that the system can be
> used for IP traffic routing.
xxxxxxxxxxxxxxxxxxxxxxxxxxx
[elv]

Just a quick side note - If one were dealing with routers as the clients, for example, I think there can still be an issue.

Each router has an IP address, which is routable in the IP layer space.  Of course, that's not the routable address in the optical space.  So if it is required that an optical routable address for the remote IP router be provided in the UNI message, the router will need to know:
+ the IP address of the IP router it wants to talk to for its IP layer operations, AND
+ the optical routable address that the router it wants to talk to is associated with.

Aside from making visible the edge optical NE routable addresses (security issue), the router will also need to track the equivalence between the two, as it will need to maintain the other router's IP routable address
in the forwarding table, as well as its optical layer routable address for UNI signaling purposes.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

There is a section in the GMPLS routing document titled:

1.2. Excluding data traffic from control channels

This section proposes one method for achieving this; and finishes by
saying:

   Other techniques for excluding data traffic from control channels may
   also be needed.

So, we all agree that this is a requirement.  I would not put this in
the ASON Routing Reqts doc, though, unless this is written in some
ITU-T Recommendation, given that the ASON Routing Reqts are *not* to
introduce new requirements, however useful or sane they may be for
ASON (or other) networks.

> 2) the client system may use a different addressing space than the
> internal network addressing space.  Carriers may wish to use a
> different addressing space for administrative or policy reasons.
>
> (Note: one model for this is the VPN model, which would allow
> private networks to have their own address spaces.  Another model
> is a telephone number-like model, where clients obtain addresses
> from a space maintained by the carrier.)
>
> 3) the client system may use a non-IP address for compatibility
> reasons, for example, a client with an existing management plane
> address that the carrier wants to access without having to
> add a new address and translation mechanism.

Again, these are both good, but unless you can find text to this
effect in an ITU-T Recommendation on ASON routing requirements, we
cannot put this in the ASON Routing Requirements document.

If there is such text (for any of points 1, 2 or 3), it would be
useful in the context of this debate to post it to this list.

For point 3, I view Recommendation 7713.1 which (in my faint
recollection) has only PNNI addressing, and in particular does not
have IP addressing, as suggesting that it is NOT a requirement that
a given solution cater to all possible address types.  So, while this
might a nice-to-have, it certainly doesn't seem to be an ASON
requirement.  If you think otherwise, please let me know --
Recommendation number & section.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[elv]  In Rec. G.807, Section 7.4 on naming and addressing, I've excerpted some points - hope this is helpful:

Separation of server layer name and client layer name, as well as user domain name and service provider domain name, provides an abstraction barrier between name processing and connection operations. Some properties of the naming and addressing in the switched network are:
.	Name independence: The client (user) name should not make assumptions on what capabilities are offered by the server (service provider) name, and thus the semantics of the two name spaces should be separate and distinct. This does not place any constraints on the syntax of client and server layer name spaces, or on the user and service provider name spaces.
.	Server layer name space: The server layer name space provides identification of the node and the resources available for connection operations at that layer. Server names are applicable at the server layer only, and should not be communicated to the client layer.
.	Service provider name space: The service provider name space provides identification of the node and the resources available for connection operations and is an NNI issue. Service provider names are applicable in the service provider domain, and should not be communicated to the user.
.    Name translation: This provides multiple purposes. The translation function may provide mapping of the client layer name to server layer name (used for routeing decision through the server layer), user domain name to service provider domain name, or provide mapping of connection identifier to a connection in the server layer. These translation functions will likely be performed via one or more directory services.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Thanks,
Kireeti.
-------

---

From: Jonathan Sadler <[email-masked]>
Date: Thu, 18 Mar 2004 15:33:41 -0600

Hi Kireeti -

Let me try and correct what may be a misperception...

> > add a new address and translation mechanism.

<snip>

> Recommendation number & section.

G.7713.1 does not include any special procedures to handle IPv4 and IPv6
addressing because special procedures are unnecessary.   The NSAP addresses
used in G.7713.1 are meta-addresses that incorporate a number of addresses
formats, including IPv4 and IPv6.  This is accomplished through the Address
Format Identifier (AFI) octet that exists at the begining of the NSAP
address format.  AFIs have been defined by ISO/IEC for IPv4 and IPv6 --
therefore the procedures for handling IPv4 and IPv6 addresses in G.7713.1
already exist.

For more information on NSAPs, including all the AFIs allocated, please see
ISO/IEC 8348:1996 and ISO/IEC 8348:1996 Amd.1, available free of charge at:

http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/s027728_ISO_IEC_8348_1996(E).zip

http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c030507_ISO_IEC_8348_1996_Amd_1_1998(E).zip

It should be noted that this standards based approach is different than the
_experimental_ approach taken in RFC 1888.  Since NSAP addresses are
variable length, and allow for lengths longer than any of the address spaces
incorporated, there is no loss of information when using an NSAP version of
an IPv4 or IPv6 address.  Contrast this to RFC 1888, where new addresses are
defined in the IPv6 for each NSAP addressed endpoint, and a mapping function
must be used to do a translation.  This is necessary as IPv6 addresses are
too short to accommodate every NSAP.

Consequently, special procedures (ie. new objects) were necessary in
G.7713.2 and G.7713.3 to fully accommodate NSAP addresses.

Jonathan Sadler

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 18 Mar 2004 23:56:01 -0800

Hi Kireeti,

I would like to put this discussion in some perspective:
we were discussing unsettled areas in the conclusions section, 
which currently states that "no additional 
extensions seem to be required in order to advertise reachable 
end-points within an ASON control plane."

I'm concerned that this can be read as a conclusion about the
routing protocols rather than routing requirements, and if
so seems premature and out of scope of the requirements document.

As Jon has pointed out, the specific requirement in ASON
is to advertise reachability in terms of a set of SNPP IDs
or UNI Transport Resource Addresses or associated prefixes.

ASON does not specify in detail how UNI Transport Resource
Addresses are formatted or allocated (apart from specifying 
that they are globally unique and network assigned).  If
GMPLS has restrictions that affect reachability advertisement
it would be helpful to understand this.

Cheers,

Lyndon

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Thursday, March 18, 2004 11:47 AM
To: Ong, Lyndon
Cc: [email-masked]
Subject: RE: ason-routing-reqts: issue 1 addressing

Hi Lyndon,

On Tue, 16 Mar 2004, Ong, Lyndon wrote:

> Maybe the issue needs to be worded more clearly...
>
> Can existing address reachability mechanisms support
> (and if so, how)
>
> a) distinguishing between the control plane address
> for a client and the data plane address for a client
> which might be two different things?
>
> b) distinguishing between the internal network address
> space and an external client address space?
>
> c) advertising reachability to a client whose address
> space is non-IP?

All excellent questions.  Thanks for the summary.

I'll go back to my meta-question:

Are these ASON routing requirements?  If so, can you quote chapter and
verse?  The clear charter of the ASON Routing Reqts DT is to take
*existing* ASON routing requirements, evaluate them against what's in
GMPLS routing, and come up with a list of remaining requirements to
set the stage for an ASON Routing Extensions document.  Not to come up
with new requirements, however excellent they may be.

Kireeti.
-------

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 19 Mar 2004 00:17:10 -0800

Hi Kireeti,

Please see below.

Lyndon

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Thursday, March 18, 2004 11:47 AM
To: Ong, Lyndon
Cc: 'Brungard, Deborah A, ALABSHi '; [email-masked]
Subject: RE: ason-routing-reqts: issue 1 addressing

Hi Lyndon,

[LYO] OK, point taken.  This is already a GMPLS requirement.

[LYO]  Well, I was not asking for this to be put into the 
requirements document, just trying to present some of the
concerns with the conclusions section.

[LYO] G.7713.1 is a signaling document (and as Jon points out does
have a mechanism for carrying IP addresses).  PNNI routing extensions
for ASON would need a mechanism for advertising UNI
reachability.

Thanks,
Kireeti.
-------