Subject: RE: ason-routing-reqts: issue 1 addressing

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 16 Mar 2004 10:10:43 -0800

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.

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.  

Cheers,

Lyndon

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Monday, March 15, 2004 11:29 AM
To: [email-masked]
Subject: ason-routing-reqts: issue 1 addressing

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: [email-masked]
Date: Tue, 16 Mar 2004 20:42:39 +0100

hi lyndon,

some hints in-line, i start worrying about the arguments
you've been listed here below since here except (2) they
are not related to this issue 1:

Ong, Lyndon wrote:

> concerns with using existing methods of advertising reachability for
> this purpose:
> 

-> the SC capability of the end-point is orthogonal to its
    numbering (in addition, this way of thinking will make us
    advertising MAC addresses when end-points will terminate
    Ethernet)

> different addressing space for administrative or policy reasons.

-> i don't think there is any discussion here, the thread
    focuses on "external" reachability - and this is the
    issue, how this "external" reachability information
    needs to be advertised to maintain the properties of
    the control plane (in particular scalability)

> (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.)
> 
> address that the carrier wants to access without having to add a new
> address and translation mechanism.

-> mapping of MP <-> CP and CP <-> DP are outside the scope
    of the present discussion, note if your argument was valid,
    the argument (2) wouldn't since in this case you would
    have been advertising your management plane addresses

> Cheers,
> 
> Lyndon
> 
> -----Original Message----- From: Brungard, Deborah A, ALABS
> [mailto:[email-masked]] Sent: Monday, March 15, 2004 11:29 AM To:
> [email-masked] Subject: ason-routing-reqts: issue 1 addressing
> 
> 
> 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: 
> 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
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 18 Mar 2004 11:46:53 -0800 (PST)

Hi Lyndon,

> used for IP traffic routing.

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.

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

Thanks,
Kireeti.
-------