Re: spc connections

[Ben Mack-Crane <ben.mack-crane@tellabs.com>]

Dimitri,

See comments in-line below.

Regards,
Ben

Dimitri Papadimitriou wrote:

> ben,
>
> your response is confusing what you say is that
> the operator at the as boundary can accept a call
> that specifies accessing a specific end-point but
> does not accept the connection request associated
> to this call - does this make any sense ? 
Yes, it does.  For instance, an operator receiving a
request for an Ethernet P-P call (service) may decide
to deliver that service over a lambda network or over
a SONET/SDH network using virtual concatenation.
Thus the connection(s) used to realize the service (call)
may be quite different.  Separating call attributes
from connection attributes so that they can be easily
distinguished contributes to a simpler protocol
(and simpler implementation).

> more fundamentally, i don't see where the delivery
> of call functionality for spc's does have to imply 
> some implementation specific restrictions to fulfil
> this functional requirement ? when you point out
> here that the "ERO may be disregarded" it becomes
> a protocol requirement not a functional requirement
> and afaik G.8080 does have nothing to do with any
> implementation specifics
As you say, while it is a requirement that call/connection
separation is provided for SPCs as well as SCs according to G.8080,
this does not create a protocol requirement per se.
My observation is simply that the protocol design will
benefit from separating call and connection information
as this leads to a protocol that simply meets the requirement.
Other (more complex) protocol designs are possible,
though I would like to avoid them.

> now concerning the source of information, you're
> mismatching what lyndon said "passing information
> from the management to the control plane"  with 
> the control plane exchange of information between 
> call/connection controllers
I'm not certain I understand your point here.
I think principles of good information structure apply in any case.

> the conclusion, as also drawn by several people on
> this list seem clear:
>
> "There is no change in protocol to enable this function, 
> merely a description of how it all works."
>
> something that will be addressed in order to avoid
> spreading of misunderstanding
>
> thanks,
> - dimitri.
>
>
> > Dimitri,
> >
> > The reason that the SPC Label (or Egress Label) should be in a separate 
> > object from the ERO
> > is that the ERO may be ignored.
> >
> > This is not unrelated to the source of the information, in that the ERO 
> > is provided by some
> > network control or administrative entity while the call endpoint 
> > identificaiton is provided by the entity
> > requesting the service.  In fulfilling a service request, a service 
> > provider may disregard the ERO
> > but may not disregard the service request.  Thus it makes perfect sense 
> > to keep these pieces
> > of information in separate objects.
> >
> > Regards,
> > Ben
> >
> > Dimitri Papadimitriou wrote:
> >
> >    
> >
> > > lyndon, the fact that you may receive the "information" from an nms/ems, 
> > > manually  configured, or any other means does not have to impact the 
> > > external behaviour of the protocol - what you suggest is the use of a
> > > mechanism that would depend on the originator of the "information" -
> > >
> > > while rfc 3473 specifies in section 5.1.1:
> > > "Procedures by which an LSR at the head-end of an LSP obtains the
> > > information needed to construct the Label subobject are outside the
> > > scope of this document."
> > >
> > > the only thing that needs to be specified for this subobject is the
> > > placement and ordering in the ERO (as specified in the same section)
> > >
> > > in addition - and as far as my understanding goes - there are no 
> > > functional requirements mandating - this should be somewhat obvious -
> > > the implementation specific mechanism you describe here below
> > >
> > > hope this will help you to understand what we're trying to explain
> > > you since last monday (john, adrian, etc. via private and public
> > > e-mails)
> > >
> > > thanks,
> > > - dimitri.
> > >
> > >
> > > <snip>



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