Subject: Re: [issue 7] All PL messages addressed to only LFBs?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 23 Nov 2004 21:16:40 -0800

Jamal,

I don't think I made myself clear :)
I understand what you're trying to say below however I don't think there
are 2 grammars.
There may be a small clarification needed to the grammar,
I am not sure if MAINHDR<LFBselect>+ means we have a MainHdr followed by
0 or more LFB selects, or 1 or more LFB selects. If it is the latter we
need to use a different BNF notation, other than that the grammar is
still the same.

Let me reiterate the Event example, the Event Report message will
consist of...
MAINHDR<LFB1 Event1 info><LFB1 Event2 info>, etc. This message is sent
from the FE to the CE, it is addressed to the entire CE, it however
contains information about events in different LFBs. There is no
co-relation in the grammar and where the message is addressed.

The pseudo English example which you have given below looks more like
the implementation and in that case it would need to parse the message
Type in the main header before decapsulating the LFBs. This is required
either ways, I am sure you would know this since you have some
implementation.

Anyways, at this point if this is still not clear, I would like to hear
what others think. Robert, Joel have expressed their
opinions...hopefully other protocol team members will chime in soon.
Weiming, Avri, Ram ...let us know your thoughts??

regards
Hormuzd 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Tuesday, November 23, 2004 5:37 AM
To: [email-masked]
Subject: Re: [FORCES] [issue 7] All PL messages addressed to only LFBs?

Hormuzd,

On Tue, 2004-11-23 at 02:13, Khosravi, Hormuzd M wrote:
> Jamal,
>
> I maintain that the grammar does not change. Let me reiterate an
example
> that we have discussed several times before,
>
> HB msg = MAINHDR only...that does not change the grammar.
>
> Another example,
>
> Event Report msg = MAINHDR<LFBselect>+...it is addressed to the entire
> CE for example, but still contains event information in terms of LFBs.
>
> Msgs containing information in terms of LFBs does not require them to
be
> addressed to LFBs.

I dont think i made my point clear,
Let me describe this a different way.

There are two grammars

The first one:
PL level PDU : = MAINHDR <HBexception>|
                         <ASSOCexception>|
                         <YETTOBEDEFINEDexception>|
                         <LFBselect>+
LFBselect := LFBCLASSID LFBInstance <OPER>+
OPER:= <OPERATION [<path-data>]*>+
HBexception := ...
ASSOCexception := ...
YETTOBEFEFINED1exception := ...
YETTOBEFEFINED2exception := ...

The second one:
PL level PDU : = MAINHDR<LFBselect>+
LFBselect := LFBCLASSID LFBInstance <OPER>+
OPER:= <OPERATION [<path-data>]*>+

Or lets put it in pseudo-english:

The first one:

"for all incoming messages,
     if it is a heartbeat, speacial process
     if it is a association, ...
     if it is a TBD1 ...
     if it is a TBD2 ...
        else
            look at LFB selector ...
"

And as you keep adding new ones, you add more exception
handles in message processing loop.

vs, the second one:
"for all incoming messages,
    look at LFB selector ...
"

So question to you:

a) do you agree they are different?
and, if yes:
b) which one do you think is better?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 24 Nov 2004 08:16:54 -0500

The meanings of + | etc are well known in a BNF.
I think it is not fair of you to be making judgement calls all along on
what the BNF says when such syntax is not obvious.

Events need to be mapped to a path. paths belong to LFBs. To select LFBs
you need LFB selectors.

I do not this is gonna lead to a meaningful discussion.
So, I am gonna stop discussing this with you at this point and call for
an intervention from other people or the chairs.

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Thu, 25 Nov 2004 17:56:50 +0100

Hormuzd,
Could you please explain why you now question the content of the latest
protocol draft that we prepared together ? I think that your "small
clarification"  invalidates sections 6.2.1, 6.2.2, 6.2.3, 6.5.1, and
6.5.2, at least.
Regards,
-Robert