The MPLS WG Archive

[Fong Liaw <FLiaw@zaffire.com>]

draft-bala-mpls-optical-uni-signaling-00.txt
is updated by draft-bala-mpls-optical-uni-signaling-01.txt
already. However it is still subject to change according to
events in OIF. 

Authors of this draft are just being information by the 
carrier group representative that they are working on 
more specific protocol related requirements regarding 
this now ... So let's give them a bit of time to sort 
through it and not burden the list with questions that 
we can not resolve here.  However, if you have input that
does not based on carrier group's requirements, please
do let us know.

I believe we should have some preliminary clarification 
by the time of the IETF meeting ...

-Fong

>  -----Original Message-----
>  From: Papadimitriou Dimitri [mailto:Dimitri.Papadimitriou@alcatel.be]
>  Sent: Thursday, November 30, 2000 1:21 PM
>  To: Fong Liaw
>  Cc: 'Guangzhi Li'; 'Diego Caviglia'; mpls@UU.NET
>  Subject: Re: draft-yu-mpls-rsvp-oif-uni-00
>  
>  
>  Hi,
>  
>  Please check the document 
>  draft-bala-mpls-optical-uni-signaling-00.txt
>  This draft reflects ongoing work at the Optical Interworking Forum
>  (OIF) and the Optical Domain Service Interconnect (ODSI) coalition
>  on the optical UNI [2]. (dixit)
>  
>  In this draft you will find that:
>  
>  Connection ID is explicitly needed in
>  Create response (specified since assigned by the network)
>  Delete request/response
>  Modify request/response
>  Status request/response
>  Notification message
>  
>  Within the Create request the connection ID is unspecified
>  
>  You will find within this draft the definition of lightpath 
>  ID (dixit)
>  Lightpath ID: A network-wide unique identifier for a lightpath.
>  This identifier is assigned by the optical network. It consists
>  of the IP address of an OXC along with a locally unique index.
>  
>  Hope this helps you.
>  
>  Regards,
>  
>  Dimitri.
>  
>  Fong Liaw wrote:
>  
>  > Guangzhi
>  >
>  > I was not in the Maui meeting but what was
>  > advocated (by carrier group members) and agreed
>  > is that the signaling protocol MUST carry a
>  > "network assigned" ID as lightpath identifier.
>  >
>  > I completely agree with you that the Session
>  > object would serve the purpose at UNI, but OIF
>  > carrier group apparently think otherwise.
>  > My proposal in last email is a compromise.
>  >
>  > The MUST part applies only after it is assigned,
>  > most likely by Resv Message from network->user and in
>  > Path message from network->user (i.e. first hop network
>  > node).  We can go though the messages one by one to
>  > see which one really need to carry the connection_ID,
>  > but from what I heard, only ACK and Srefresh can be
>  > exempted from it.
>  >
>  > I would rather we don't have this in UNI ...
>  > So if you can convince your OIF carrier group
>  > representative to take it out, most of us would
>  > have no problem.
>  >
>  > George was in Maui OIF meeting, maybe he can tell
>  > us what's the situation there.
>  >
>  > -Fong
>  >
>  > >  -----Original Message-----
>  > >  From: Guangzhi Li [mailto:gli@research.att.com]
>  > >  Sent: Thursday, November 30, 2000 11:59 AM
>  > >  To: Fong Liaw
>  > >  Cc: 'Diego Caviglia'; mpls@UU.NET
>  > >  Subject: Re: draft-yu-mpls-rsvp-oif-uni-00
>  > >
>  > >
>  > >  Fong:
>  > >
>  > >  From signaling point of view, let's clarify something first:
>  > >  (1) who generate the "Connection_ID" ? The 
>  first-hop-router in the
>  > >  network, right.
>  > >  (2) Suppose that I am a user node and I want to setup a 
>  lightpath. I
>  > >  send out a lightpath request throught UNI. Then the 
>  first-hop-router
>  > >  will try to establish the lightpath.
>  > >  (3) When will I get the connection_ID from the network?
>  > >  (4) You said that a user node MUST carry the object in every
>  > >  subsequent
>  > >  RSVP messages it generates. You mean "refresh messages, teardown
>  > >  messages, or update messages" ?
>  > >  (5) If my understanding is correct, why should a user 
>  node bother
>  > >  "Connection_ID"?
>  > >  (Connection_ID = AS number+source address+local_id). Any ID
>  > >  simpler will
>  > >  work between UNI.
>  > >
>  > >  Please give me more explanation. Thanks,
>  > >
>  > >  -- Guangzhi
>  > >
>  > >
>  > >
>  > >  Fong Liaw wrote:
>  > >
>  > >  > Hi, Diego
>  > >  >
>  > >  > The official name for ligthpath ID is now "Connection_ID".
>  > >  > We are still discussing (among authors) how this
>  > >  > object should be used and therefore where it should
>  > >  > show up in the messages.  Right now, we don't have
>  > >  > a clear definition of these from the requirement
>  > >  > but this will hopefully be resolved between the
>  > >  > carrier group in OIF and the signaling group authors soon.
>  > >  >
>  > >  > Right now our proposal is the following:
>  > >  >
>  > >  > "The Connection_ID object will be an optional
>  > >  > object in all RSVP messages. However, once a
>  > >  > Connection_ID is assigned by the network,
>  > >  > a user node MUST carry the object in every
>  > >  > subsequent RSVP message it generates."
>  > >  >
>  > >  > This phrase gives network the freedom of generating
>  > >  > or not generating a Connection_ID, and if they do
>  > >  > generate one, a user node will play it back to
>  > >  > the network.  A connection is still identified by
>  > >  > RSVP Session object, at the UNI.
>  > >  >
>  > >  > -Fong
>  > >  >
>  > >  > >  -----Original Message-----
>  > >  > >  From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
>  > >  > >  Sent: Thursday, November 30, 2000 5:54 AM
>  > >  > >  To: mpls@UU.NET
>  > >  > >  Subject: draft-yu-mpls-rsvp-oif-uni-00
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >  Fong,
>  > >  > >                 I've seen that w.r.t. the OIF 
>  version of this
>  > >  > >  draft a Lightpath
>  > >  > >  ID object is introduced but in the message definition I
>  > >  > >  can't find it.
>  > >  > >
>  > >  > >  If it is not a mistake, could someone explain in wich
>  > >  > >  message Lightpath ID must
>  > >  > >  be inserted?
>  > >  > >
>  > >  > >  Regards Diego.
>  > >  > >
>  > >  > >
>  > >
>