Re: [Forces-protocol] Progress issue 1: packet encoding

["Wang,Weiming" <[e-mail]>]

Hi,

I agree to currently close issue 1. I think it is quite probable to reach an
agreement on this issue when we write a draft, because there are no essential
differences among the ideas. I evaluate the result for this issue as "an
ageement can be reached in the future with the probability of 90%".

Now the actual problem lies in the issue 0, that is to use a uniform PID or a
tree structured FE ID: LFB ID: LFB Instance ID resolution for the addressing.
The issue 0 needs more discussion before being closed because the difference
there is very essential for the protocol.

Cheers,
Weiming

----- Original Message -----
From: "Jamal Hadi Salim" <[e-mail]>
To: <[e-mail]>
Cc: "Putzolu, David" <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Wednesday, March 10, 2004 12:16 AM
Subject: [Forces-protocol] Re: Progress issue 1: packet encoding


>
> This is a common trick. I thought both FACT and GRMP have it.
> Netlink2 for example has a special command for errors.
> The body will contain an error code and the offending original
> header (similar to ICMP source quench).
>
> These are issues we can settle. Can we please close topic 1?
>
> cheers,
> jamal
>
> On Tue, 2004-03-09 at 11:04, Alex Audu wrote:
> > On Issue 1: packet encoding,  it is easy to come to concensus on this
> > one.  So far, the train
> > thoughts is per the attachment to this e-mail.
> >
> > Issues raised:
> > 1) Avri raised issue of indicating an error with an error flag on the
> > header.
> >
> > Comment:  That is certainly one way to convey error conditions. But
> > experience has
> > shown that if you do that, you force your protocol software to check
> > this flag for every
> > message that comes in (to ascertain if it is error message or not),
> > before proceeding. This
> > is an incredible  wate of processor cycles since an error condition is
> > really an exception
> > condition.
> >
> > Carrying an error indication with an error TLV is much better.   It is
> > like an error color
> > code; you only do error processing if that color shows up.  And all
> > the other messages
> > are handled similarly.  This could easily be the difference between a
> > protocol  that is
> > twice as fast and efficient  compared to an otherwise poorly designed
> > one.
> >
> > Regards,
> > Alex.
> >
> >
> >
> >
> > Jamal Hadi Salim wrote:
> > > On Tue, 2004-03-09 at 01:42, Putzolu, David wrote:
> > >
> > > > Avri wrote >
> > > >
> > > > > I have a general question about headers, is there any feeling in this
> > > > > group that a common header could not be arrived at.  If not then we
> > > > > could move on to other issues.  The reason I ask is that one
> > > > > can spend
> > > > > a whole lot of time fine tuning a header to be just right.  If there
> > > > > are as of yet unresolved issues on the header, can anyone list them?
> > > > >
> > > >
> > > > I agree with Avri,
> > > >
> > >
> > > On the one hand i wanna say lets skip so we can make progress.
> > > OTOH, I am a little worried that the gaps in point of view
> > > are so huge that this will cause problems later.
> > > The only way we can close faster is if ontopic emails are addressed in
> > > the fastest possible way.
> > >
> > > On a personal level i am trying to prioritize responding to things
> > > on this list. But sometime i get a little discouraged. Example my last
> > > emails on topic 0 and topic 1 have not been responded to for at least
> > > 24 hours. Actually they have been a response which happens to be off
> > > topic. This worries me because i dont think we will make the deadline.
> > > If theres 10-12 serious issues and we have about 10 days to go
> > > AND we havent closed a single issue up to now --> theres _no way_
> > > we can meet the deadline. We need to close 2 issues a day.
> > >
> > > Of course a brute force solution is to say theres desire to reach a
> > > compromise and stop there. But this in itself is dangerous and i
> > > would not prefer to go that route.
> > >
> > > So at the moment i am at a loss. Maybe the approach of listing issues
> > > which need to be agreed on is not the right one? What thoughts do people
> > > have on this? Other proposals that have been made so far that received
> > > no traction are:
> > > a) each protocol draft to list what they cant live without,
> > > b) Each protocol draft to list their implementation experiences and
> > > say what they found useful and what wasnt.
> > >
> > >
> > > > and like others I am having a hard time
> > > > keeping up with all the different discussions.
> > > >
> > >
> > > Yes, this has been an issue but is general to any email or usent
> > > discussuions - problem is someone starts going off
> > > topic then other people respond. And the cycle continues.
> > >
> > > The best way to run "meetings" over email are:
> > >
> > > Rule 0: have an agenda (list of topics to discuss). We have this
> > > Rule 1 is to have a running topic (eg currently issue 1 and 0 are
> > > ontopic). No other topic is to be discussed. We are trying this.
> > > Rule 2 is not to respond to currently-offtopic emails. This is typically
> > > the easiest rule to break on email or usenet because of human nature.
> > > Naturally this has been the most broken rule.
> > > Rule 3 is once in a while people need to be reminded they are off topic.
> > > (I have tried to do this in personal emails as well as on the list.)
> > > Rule 4 is if the content does not reflect the subject line, change the
> > > subject line (like i just did with this email).
> > >
> > > I could almost say we are getting close to following the above; I
> > > counted and only 2 emails were offtopic out of last 6 as opposed to
> > > 6 out 10 before that.
> > >
> > > cheers,
> > > jamal
> > >
> > >
> > > _______________________________________________
> > > Forces-protocol mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/forces-protocol
> > >
> >
> >
> > ______________________________________________________________________
> >
> > I don't know what the flags could be used for. The TypeID could be used for
> > siganling the type of data encoding explicitly,  (i.e. XML, ASN.1 etc).
> > My preference will be the following.
> >
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >                     0               1               2             3
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |vers   |eType  | prio| reservd |  msgClass     |   msgType     |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                       message length                          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |          Source xID           | Destination xID               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                        Sequence Number                        |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > 1) version # indicates the version of the protocol.
> > 2) the type of encoding comes next.
> > 3) the priority of the message comes next.
> > 4) the command has been divided into message class and type to ease
management and handling.
> > 5) the source and destination are now both 16 bits each. This allows up to
64K FEs. That is cool!
> > 6) the length is now 32 bits long. This will accommodate flow measurement
messages which
> >    tend to be huge,  from FE to CE.  It will also accommodate large table
dumps from CE to
> >    FE.
> > 7) then comes the sequence number.
> >
> > Any comments?
> >
> > Regards,
> > Alex.
> >
> > > Jamal,
> > >
> > > Before I give my comments, I would like to say that I appreciate the
> > > fact that you did not copy/paste the netlink header from your draft over
> > > here! That is a very positive sign to me, lets try to stick to the best
> > > technical solution rather than pushing our own protocol implementations.
> > > That's the best way to make progress on this merger!!
> > >
> > > Here are my views on this issue, particularly the common header:
> > >
> > > Command: Agree this is needed. We think 8-12 bits will be more than
> > > sufficient for this depending on whether it is subdivided. We have
> > > sub-divided this field into Class/type...this is an OO approach, seemed
> > > pretty neat. However, I am personally fine with having a single field
> > > for this, no problem with that.
> > >
> > > Length: Agree needed and agree with size.
> > >
> > > xIDs: Agree this is needed. More detailed comments on length, semantics
> > > in my previous email.
> > >
> > > Sequence No: Agree needed and agree with size.
> > >
> > > Flags/Priority: We need 2-3 bits for priority in every message. I don't
> > > think we need any other flags in all messages.
> > >
> > > Typeid: This is one field I don't think is needed in all messages. I am
> > > not sure why this is needed at all cause, we will be using the Model and
> > > LFB IDs to address processing functional blocks on the FEs.
> > >
> > > Missing field: Version (2-4 bits): This is present in all protocols, and
> > > is generally included in most IETF protocols. Its usually the 1st field.
> > >
> > > General comment: Lets try to be stingy on the size of the header and its
> > > fields since this will be included in all ForCES messages.
> > >
> > > Jamal's text.......
> > > The Forces Message Header:
> > >     0                   1                   2                   3
> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > >                     0               1               2             3
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |             Command         |               Length            |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                          Source xID                           |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                        Destination xID                        |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                        Sequence Number                        |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |             flags           |             typeid              |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >
> > > XML encoding:
> > > XML encoding may be useful in capabilities definition
> > > (i.e slow path) but not in the configuration of data path tables.
> > > This is because of its nature to require higher bandwith and
> > > CPU computational needs.
> > >
> > > HK Comment: I think we should stick with a single encoding type, namely
> > > TLV. This is also what some of the model team folks have mentioned
> > > before for the protocol. Is there a reason why capabilities cannot be
> > > expressed using TLVs?
> > >
> > >
> > > Thanks
> > > Hormu
>
>
> _______________________________________________
> Forces-protocol mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/forces-protocol



_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol