Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 6 Jan 2005 11:31:19 -0800

Happy New Year to All!

Jamal, seems like we have resolved this issue (1) with the exception of
the details of Reason in Teardown msg. I think we can probably work on
that in a conference call with the rest of the team since no one seems
to be responding on the list.

Thanks
Hormuzd 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Wednesday, January 05, 2005 8:01 AM
To: [email-masked]
Subject: Re: [FORCES] Issue Resolution - Issue #1: Feedback, protocol
section 6.2

Happy New Year Hormuzd and everybody else,

On Mon, 2004-12-27 at 02:54, Khosravi, Hormuzd M wrote:

> So the summary of what i am saying is the FE OBject LFB is a source as
> well as sink of the Association msg/response. If there are any
> attributes already known to the FE then it makes sense to notify the
CE
> of their state (the name being one of them). 
> [HK] Yes I agree with that...similar to what I am saying. I think we
> will need both the FE Object and FE Protocol object to be advertised
in
> the Association message. 

Agreed. 

> > Let me know how you would like to resolve this? Any suggestions
would
> be
> > welcome.
> 
> Isnt this discussion the point? If we dont get anywhere i will capture
> it in the tracking database. [I think if we agree with the comments
> above, we have resolved this one...atleast partly]
> 

Indeed.

> > One more thing, you had asked for a special TLV -> FORCES_REASON for
> > the Teardown msg. Since we would both like to avoid this, any
suggestions
> on
> > how this can be accommodated via FE LFBs? May be we remove the
Reason
> > completely from the Teardown msg?...let me know your thoughts?
> 
> This is a hard one. We could send it easily (either direction) if it
is
> an attribute. I think for logging debugging purposes we would need to
> know the departure reasons. But whose attribute is this?
> Maybe other people have opinions.
> [HK] We could use similar mechanism as we do to report all our
results,
> to report the Reason. Let me know your thoughts,

The challenge is that each data sent needs to have a path associated
with it. We need to tie it to some path.
What do other people think? 

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 9 Jan 2005 23:25:08 -0500

> to be responding on the list.

Sounds reasonable.
In any case, if we ever have a conference call i think it should
be to shoot for resolving the path-data issue which in my opinion
is the show stopper. All these other issues outstanding at the moment
are pretty much resolvable each in less than 10 minutes.

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Mon, 10 Jan 2005 16:58:38 +0100

Issue 1 included a discussion of the meaning of the ADVERTISE (or SHOW) 
operation used for instance in the Association Setup messages. Here are 
a few short clarifications:

The idea for this ADVERTISE (or SHOW) operation is for the FE to pass 
the value of an attribute to the CE in the path-data form. This is 
different from an event fired by the FE (for which I think the REPORT 
operation should be kept, btw), and different from a GET RESPONSE (as 
the value is transmitted without the CE asking explicitely for it; Jamal 
had proposed this at some point).

In this context, the issue (raised on the list by Hormuzd) of 
advertising not only one atribute, but the whole LFB at once (for 
instance a core LFB) would require the definition of an "LFB attributes 
serialization" method, which is missing at this point.

And best wishes to all !
-Robert

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 11 Jan 2005 12:12:19 -0500

Robert,

The booting up of an FE (issuing of an association) can be looked at as
an _event_ in my opinion. It asynchronously notifies the CE of the event
of an FE arriving at (and attempting to join) the NE.
The source LFB is clearly the FE Object LFB. Thoughts?

Having said that:
It does seem to be overkill to have this one operation that does get
used for the association; I think Joel presented a similar view as well?
I am however indifferent if we end up keeping that operation.
On the announcement of the two core LFBs in the association message, I
didnt quiet catch the obstacle you are pointing to. We should be able to
announce any parameters we have for the two core LFBs at association
time and have the CE override some of them. I posted an example of where
a cold restart where a FE needs to reassociate - where advertising the
attributes it has for the two LFBs make a lot of sense.

cheers,
jamal