Subject: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt

From: Papadimitriou Dimitri <[email-masked]>
Date: Thu, 30 Nov 2000 22:05:54 +0100

Hello,

I have some questions concerning the draft:
draft-yu-mpls-rsvp-oif-uni-00.txt

The official name for ligthpath ID is now "Connection_ID", So
By refering to the draft: draft-many-carrier-framework-uni-00.txt

3.3.1 Identification Attributes

   [...]

   - connection identifier: a globally unique identifier for the
     connection.  This identifier will be assigned by the network.  The
     globally unique connection identifier will be created using a
     globally unique carrier identifier (identifying the carrier from
     which the connection request is sourced) and a carrier unique
     connection identifier.  This attribute is not modifiable (i.e.
     cannot be modified using the modify command).

By refering to the draft: draft-yu-mpls-rsvp-oif-uni-00.txt

3.2.4 Lightpath_ID Object

   The Lightpath_ID object is used to uniquely determine a lightpath
   within the optical network. Lightpath_ID object has the following
   format:
  - IPv4 source address: This is the address (32 bits) for the source
     UNI-C who originates the lightpath.
  - IPv4 destination address: This is the address (32 bits) for the
     destination UNI-C who terminates the lightpath.
  - Ligthpath number: This is the unique identifier (64 bits) in the
     network to be associated with the lightpath.

Questions are the following:

I think that carrier identifier means 'optical network identifier' not
the
client network (so the UNI-Client address should not be the included
within the lightpath ID) ?

Secondly i do not understand why the ONE has to assign an IP address
belonging
to the signaling plane. Imagine that the address space of the signaling
plane
(i.e. control plane) changes then you have to change all the identifiers
of
the lightpaths (or connections) which by definitions are included within
the
transport plane. This solution does not guarantee the independancy
between
the signaling and the transport plane. Do you agree ?

Imagine that you may use the UNI-C as identifier, then I do not
understand why
you need to include the destination UNI-C IP address within the
lightpath ID.
Moreover, how do you know the relationship between UNI-C and the
destination
client address (or name) ?

Regards,

Dimitri.

---

From: Fong Liaw <[email-masked]>
Date: Thu, 30 Nov 2000 18:27:22 -0800

Hello 

>  -----Original Message-----
>  From: Papadimitriou Dimitri [mailto:[email-masked]]
>  Sent: Thursday, November 30, 2000 4:52 PM
>  To: Fong Liaw
>  Cc: mpls
>  Subject: Re: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt
>  
>  
>  Hi,
>  
>  If refer to the new version of this draft:
>  draft-many-carrier-framework-uni-01.txt
>  (Thanks Yangguang to make the remark.)
>  
>  Concerning the lightpath Identifier:
>  
>  The lightpath ID is identified as: A network-wide unique 64-bit
>  identifier for a
>  lightpath. This identifier is assigned by the optical network (dixit)
>  
>  And in fact most of the parameter definitions map the carrier
>  requirement
>  draft which is the following: carrier-ID - identifier whose draft is
>  'the guideline'
>  for the definition of the parameters at the OIF as far as i 
>  now (or it
>  has change
>  from the last OIF meeting in MAUI until now)

It is already coded as 64 bits in draft-yu. Look for "Connection_ID".

>  
>  Moreover, there is no relationship between the source and destination
>  address (of the client address space) and the lightpath identifiers.
>  

Yes.

>  The UNI-C and UNI-N IP addresses are dedicated to IP 
>  signaling between
>  the client and the network not to identify the lightpaths 
>  nor the source
>  and
>  destination address of the lightpath create requests.
>  

But not precluded. I.e. IP can be one of the format that 
the network would take, and if so the UNI-C's IP address
can be used to construct a globally unique identifier.
The spec allows it, there is no mandate that the operator
has to deploy it this way.  I would rather we not get into
peer or overlay model discussion if this is where it is
leading to :-(

>  Source and destination included within the create request 
>  are defined as
>  (dixit 6.3.1)
>  3. Source/destination client point of attachment: This has two
>      components, an optical-network-administered IP address and an
>      optional logical port information. The latter consists of a port
>      index, a channel index and a sub-channel index.
>  

This is already been covered in draft-yu which is based on GMPLS.

>  You wrote:
>  >How do you know the destination client's address, just like
>  telephonenumbers, you get it from
>  >other source.-Fong
>  
>  The question related to destination UNI-C, is that the 
>  source ONE does
>  not know the destination
>  UNI-C address (simply it does not have to know this address). The
>  lightpath create request is sent
>  from the source to the destination IP address of the source and
>  destination ONE.
>  
>  The question is not how the source client address knows the 
>  destination
>  client address (transport
>  plane) it is related to the knowledge of the destination 
>  UNI-C client by
>  the source UNI-C address
>  (signaling plane) ? I don't know where you find this 
>  requirement ? From
>  what it is currently proposed
>  ONA-IP addresses are defined to virtualize 'client address 
>  space' at the
>  UNI.

Allow me to paraphrase what you said in different way:
Two things here - one is the IP address where the control messages
are sent to (the signaling plan)at UNI, and the other is where the 
connection should be connect to (the transport plan). The former
is in IP header and the latter is in Session Object. We can
allow Session object to use different address format, and the
address in IP header can be the adjacent UNI node (instead of 
destination UNI-C's IP address). This is what John is trying to
propose and incorporate into oif2000.125, not an OIF approved
mechanism. I hope this address your question. 

>  
>  Even in case of unnumbered client end-point, the address you 
>  should not
>  assign the UNI-C of the client
>  as a potential identifier (since belonging to the signaling 
>  plane - this
>  is currently under study); however
>  the address resolution request (for the destination) will give the
>  corresponding address within the optical
>  network which is the ONA-IP corresponding to this client 
>  end-point, so
>  your request won't contain the UNI-C
>  destination address of the CNE.
>  

The spec. allows different format, such as IPv4, IPv6, MAC, 
I don't see why it can't be UNI-C's address if the network
is native IP. By the end of the day, it is up to network 
operators to decide what address format they want to use and 
deploy an address resolution server (ATMARP, NHRP, DNS) if
necessary. 

Regards,
-Fong

>  Dimitri.
>  
>  
>  Fong Liaw wrote:
>  
>  >  Dimitri Regarding the address format. There is an agreed
>  > requirementto do "address resolution" for exactly the reason you
>  > mentioned.If the network's native address format is not IP, then it
>  > may makesense to use another format in Session object. This can be
>  > easily extended, but  they will still be assigned by user, not the
>  > network. John is in the process of writing this up which 
>  would include
>  > proceduresand object format.  Note that the UNI optical nodes still
>  > needto have an IP address since all the control messages 
>  using IP.How
>  > do you know the destination client's address, just like
>  > telephonenumbers, you get it from other source.-Fong
>  >
>  >      -----Original Message-----
>  >      From: Papadimitriou Dimitri
>  >      [mailto:[email-masked]]
>  >      Sent: Thursday, November 30, 2000 1:06 PM
>  >      To: [email-masked]; mpls
>  >      Subject: Questions concerning:
>  >      I think that carrier identifier means 'optical network
>  >      identifier' not the
>  >      Secondly i do not understand why the ONE has to assign an IP
>  >      address belonging
>  >      to the signaling plane. Imagine that the address space of
>  >      the signaling plane
>  >      (i.e. control plane) changes then you have to change all the
>  >      identifiers of
>  >      the lightpaths (or connections) which by definitions are
>  >      included within the
>  >      transport plane. This solution does not guarantee the
>  >      independancy between
>  >      Imagine that you may use the UNI-C as identifier, then I do
>  >      not understand why
>  >      you need to include the destination UNI-C IP address within
>  >      the lightpath ID.
>  >      Moreover, how do you know the relationship between UNI-C and
>  >      the destination