headers
Wang,Weiming | 4 Jan 2005 13:30
Picon

Re: [issue6] Summary of Path

Hi,

Happy New Year!

Incidentally this may be the first post for 2005 :)

While I agree the path-data issue may become an important issue for further
protocol issue resolution, I just find that we may not in a very efficient way
to deal with it. Recalling the argument we'v had, I have a feeling that to
resolve this issue quickly we may need the model team to proceed one step ahead,
that is,  to define at least one LFB(e.g., a LPF IPv4 LFB) with all its
attributes presented, based on the model defined schema for LFBs. Let's think
that if we have such an LFB, I suppose it will be much easier for the protocol
team to proceed with its encoding as well as the path-data PDU for protocol.

Best regards,
Weiming

----- Original Message -----
From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi <at> INTEL.COM>
Subject: Re: [issue6] Summary of Path

Jamal, Joel, Weiming,

Firstly, v. sorry about my late response on this issue.
I went thru this thread, but it wasn't clear to me what the final
summary was or which email I should respond to. I think this is a very
important issue so if one of you could summarize this and point out the
outstanding aspects, etc., it would make it easy for myself and others
to comment on this. Even if you could point me to one of your previous
(Continue reading)

Permalink | Reply | 502 comments |
headers
Jamal Hadi Salim | 5 Jan 2005 17:00

Re: 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?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jamal Hadi Salim | 5 Jan 2005 17:16

Re: [issue6] Summary of Path

On Tue, 2005-01-04 at 07:30, Wang,Weiming wrote: 
> Hi,
> 
> Happy New Year!
> 
> Incidentally this may be the first post for 2005 :)
> 

And this is the third ;->

> While I agree the path-data issue may become an important issue for further
> protocol issue resolution, I just find that we may not in a very efficient way
> to deal with it.

We need to make progress. If progress requires that we go with some
basic stuff initially, then thats the path we should take. It seems very
apparent that using basic indexing is very simple and no complaints
whatsoever about it. Block paths was the next simple thing. Keying and
interleaving with above is so far the outstanding issue. 
I believe were approaching closure before you got busy.
So if you have time now, please lets go back to where we left off.
Otherwise we need to put a time limit on this so we can move on. Chairs
please chip in here.

>  Recalling the argument we'v had, I have a feeling that to
> resolve this issue quickly we may need the model team to proceed one step ahead,
> that is,  to define at least one LFB(e.g., a LPF IPv4 LFB) with all its
> attributes presented, based on the model defined schema for LFBs.

Something like IPV4 LFB would be too complicated (because it needs
(Continue reading)

Permalink | Reply | 22 comments |
headers
Khosravi, Hormuzd M | 6 Jan 2005 20:31
Picon
Favicon

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

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:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
Sent: Wednesday, January 05, 2005 8:01 AM
To: FORCES <at> PEACH.EASE.LSOFT.COM
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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Khosravi, Hormuzd M | 6 Jan 2005 21:39
Picon
Favicon

Re: [issue2] feedback on section 6.3

Jamal,

Other than the editorial changes below, can we close this issue ?
I'll be sending email to Avri with all the editorial changes.

Thanks
Hormuzd 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
Sent: Friday, December 17, 2004 12:20 PM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] [issue2] feedback on section 6.3

On Wed, 2004-12-15 at 19:19, Khosravi, Hormuzd M wrote:
> Issue 2 is also editorial changes...pls see my comments below,
> 
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
> 
> - 6.3.1  Config Message
> 
> + "Config data"   should be "Config data and path" [will do]
> 
> + Type is bad to describe operations. That should be operations
> [Type=Operations, since it's a nested TLV]

I think more readable to say operation = XXXX
(Continue reading)

Permalink | Reply | 501 comments |
headers
Wang,Weiming | 8 Jan 2005 05:45
Picon

Re: [issue6] Summary of Path

Hi Jamal,

----- Original Message -----
From: "Jamal Hadi Salim" <hadi <at> ZNYX.COM>
Subject: Re: [issue6] Summary of Path
> On Tue, 2005-01-04 at 07:30, Wang,Weiming wrote:
 > > While I agree the path-data issue may become an important issue for further
> > protocol issue resolution, I just find that we may not in a very efficient
way
> > to deal with it.
>
> We need to make progress. If progress requires that we go with some
> basic stuff initially, then thats the path we should take. It seems very
> apparent that using basic indexing is very simple and no complaints
> whatsoever about it. Block paths was the next simple thing. Keying and
> interleaving with above is so far the outstanding issue.
> I believe were approaching closure before you got busy.
> So if you have time now, please lets go back to where we left off.
> Otherwise we need to put a time limit on this so we can move on. Chairs
> please chip in here.
[Weiming]I'm sorry I didn't reply too often laterly, but I think I'v clearly
expressed my views regarding things like the Key that Joel proposed.  To repeat
my views,
1. the Key is actually a kind of things to substitute a subpath with another ID,
like
        keyValue=f1.g1.h2, keyID=1
Therefore it's a kind of duplicating for IDs, if the subpath is something like a
purely a f1, then the key becomes
        keyValue=f1, keyID=1
Therefore, my thinking is it's really a duplicating work.
(Continue reading)

Permalink | Reply | 21 comments |
headers
Joel M. Halpern | 8 Jan 2005 06:24

Re: [issue6] Summary of Path

There are a couple of specific aspects that I think it may help to spell out.

1) Remember that the fileds may be defined in a data type that is 
imported.  That is, an array may be defined as having as content a 
structure of type "IP-information" which in turn has a field of type "IP 
address prefix".  It seems clear to me that the structure definition can 
not include the indiciation as to whether IP address prefix is a key in 
some array, since the structure is used in many places.
2) I believe that the FE implementation needs the information as to what 
keys are likely to be used by the CE>  The model is the only thing that can 
give this guidance.
3) While the FE can return errors, the CE is helped by knowing what kinds 
of indexing are likely to work.  While this can be done with capabilities, 
I have several concerns with that
3a) representing the legal keys as capabilities just gets messy
3b) I think that CE implementors will be helped by knowing what keying the 
FE will support.  Interoperability requires some common core set.  If FE 
implementors get to chose, multi-vendor CEs will just use that core 
set.  Hence, if we want this keying to be used and usable, we need to 
define what will be supported.  The model is the right place to do that.

Given that we are going to define keying in the model, there are several 
possible approaches.  Zsolt and I have batted a couple back and forth, but 
I doubt if we have found them all.  I actually don't like any of these ideas.
a) the key-id approach I suggested
b) have a key TLV consist of a sequence of path-fragment / value pairs, 
(similar to what I think Weiming is proposing) with a restriction that only 
those combinations which have been declared to be keys may be used.
c) restrict keying to path identifiable fields, and restrict it to being 
used only with full array element references at the end of the path.  Then
(Continue reading)

Permalink | Reply | 20 comments |
headers
Jamal Hadi Salim | 10 Jan 2005 05:21

Re: [issue6] Summary of Path

On Sat, 2005-01-08 at 00:24, Joel M. Halpern wrote:
> There are a couple of specific aspects that I think it may help to spell out.
[..]
> I think that the exact mechanism is less important than the questions of 
> whether the keying must be pre-declared in the model, and whether key 
> elements must be unique.
> If we can agree on those two questions, we can sketch enough protocol to 
> keep moving.

The predeclared keys are a good hint to the CE, but without capabilities
(which i also have strong distate for in this case) the backup is to for
the FE to reject a requested content operation. In other words, I do
think that it is practical to say have a ASIC vendor implementing the
some LFB not supporting any content searches.
So given that, the only value to predeclaring is giving a good hint to
the CE. I think its still a good thing to have and we should add it.

Heres where i think the two biggest discrepancies so far are and that
need to be resolved:

1) interleaving of path-data-path-data ..
So far Joel and myself have been saying you have
path [pathfilter] [data]
This is for simplicty reasons (and that a path leads to data)

Weiming is asking for:
path pathfilter data pathfilter data ...

subpath is what is refered as a pathfilter above (content or block
refinement of the path).
(Continue reading)

Permalink | Reply | 19 comments |
headers
Jamal Hadi Salim | 10 Jan 2005 05:23

Re: [issue2] feedback on section 6.3

Hormuzd,

On Thu, 2005-01-06 at 15:39, Khosravi, Hormuzd M wrote:
> Jamal,
> 
> Other than the editorial changes below, can we close this issue ?
> I'll be sending email to Avri with all the editorial changes.
> 

That would be good nuf to close it.

cheers,
jamal
Permalink | Reply | 501 comments |
headers
Jamal Hadi Salim | 10 Jan 2005 05:25

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

On Thu, 2005-01-06 at 14:31, Khosravi, Hormuzd M wrote:
> 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.

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
Permalink | Reply | 2 comments |

Gmane