Subject: comments on protocol draft

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 15 Jul 2004 09:30:10 -0400

Folks,
Can we have more comments on the protocol draft. In particular
this appeal goes to the authors of the model draft; i am spending a lot
of energy giving you feedback - so a recipraction would be nice.
Steve, Alistair and Jeff Pickering your comments will also be valuable.

cheers,
jamal

---

From: Alan DeKok <[email-masked]>
Date: Thu, 15 Jul 2004 10:40:00 -0400

> of energy giving you feedback - so a recipraction would be nice.

   I have a number of comments.  They're mostly about packet design &
layout of the draft.

   Section 3.3.1, paragraph 2: "... then all message batch must
arrive..." I'm not sure what this means.

   Section 5, "rsvd 4 bit" field.  When packets are created by a sender,
the field MUST be set to zero.  The receiver SHOULD NOT examine or
interpret this field.

   Section 6.  I think that having the TLV's defined in the sub-sections
for each message is confusing.  It makes it difficult to get a canonical
list of TLV's, and it's not clear what the TLV format is.  Other RFC's
(2865, 3588) follow a similar layout: protocol format, messages,
attribute format, attributes.  I suggest reading RFC 2865 (RADIUS), to
see how they've not only described the protocol, bu also how they've
defined the TLV's within it.

   My suggestion is to remove the TLV definitions from section 6, and
create an additional section, 6', which will contain the TLV
definitions.  Section 6 should be updated to describe the message types,
without referring in detail to the TLV's that they contain.

   The new section 6' should start off by defining the TLV format (which
is not done anywhere currently).  It should describe the fields (type,
length, and value), and should contain text similar to RFC 3588, Section
4, paragraph 3 (edited here to use ForCES terminology):

    Each TLV MUST be padded to align on a 32-bit
    boundary, while some TLV types align naturally.  A number of zero-
    valued bytes are added to the end of the TLV Data field till a word
    boundary is reached.  The length of the padding is not reflected in
    the TLV Length field.

   That is, each TLV in ForCES is 32-bit aligned, but the "length"
contains ONLY the length of the actual data.  Any data not described by
"length" is padding, MUST be set to all zeroes, and is ignored.  This
distinction means that a number of "reserved" fields in the TLV's in the
ForCES protocol draft are no longer necessary.  It also removes comments
about padding from the individual TLV definitions (e.g. 6.4.1)

   The existing TLV definitions in Section 6 can be moved to a section 6'.

   Section 6.1.3 having an optional "reason" field is problematic.  Use
the normal TLV format, and define a 32-bit integer/enum for reasons.
This section should also contain a note saying "reasons to be defined
later".

   Section 6.2: packing multiple pieces of information into one TLV is
problematic.  It makes implementations more awkward, as each TLV is its
own special case.  I suggest defining multiple TLV's, such as one which
contains a "list" of responses, and another which contains "Type Id,
Instance Id".  The type/instance Id TLV can then be re-used, in the
TLV's defined in sections 6.3.1, 6.3.2, 6.4.1, and 6.5.

   I also note that the type/instance data is in a *different* place in
the TLV's for Section 6.2, versus 6.3.{1,2}.  This makes implementing
the protocol MUCH more difficult and prone to error.  having a separate
TLV for type/instance Id ensures that there are fewer special cases, and
fewer implementation errors.

   Sections 6.3.x refer to "config data/result" for LFB data, but don't
define how that data is formatted.  I suggest using a separate TLV for
LFB-specific data.  The format of that data should also be specified, or
a note should be added "LFB data to be defined in another document".

   I also don't see any provisions for vendor extensions.  There should
be a TLV specifically for vendor extensions, using the vendors private
enterprise code, e.g.  "type, length, 32-bits of vendor-code, vendor
data..."

   The "result" field of Sections 6.3.x should be its own TLV.  This
allows the TLV's to be re-used across different kinds of messages, and
makes implementation and parsing easier.  e.g. The message type can tell
the implementation how to interpret the TLV's.  Section 6.3.1 and 6.3.2
could then share a TLV called "LFB data", which would be interpreted as
"config data" in section 6.3.1, and "config result" in section 6.3.2.
This approach simplifies the protocol design.

   Section 6.6.2 (and others), the result field could be to the right of
the reserved field.  This allows it to be later extended to be a 32-bit
result, if that is later necessary.

   That's it for now.  I may have more comments later on the design of
the CE-FE communication, in addition to these comments about packet formats.

   I believe that this draft is should be accepted as a working group
document.  The proposal appears to be technically sound, but I will have
to spend more time understanding the CE-FE protocol to be sure I have a
good grasp of it.

   The document appears to be compatible with the ForCES model, through
the simple expedient of ignoring any specific LFB requirements.  The
model team has been concentrating on describing LFB's and inter-LFB
operations, which is nearly orthogonal to this document.

   I would like to see this draft discuss LFB's and metadata in more
detail, as that information is key to having a ForCES protocol which can
be used to configure a device.  Right now, the focus of the draft
appears to be ensuring that the CE and FE can communicate.  This is a
good start, but we're not done yet.

   Alan DeKok.

---

From: Furquan Ansari <[email-masked]>
Date: Thu, 15 Jul 2004 19:31:37 -0400

Hello,

I have some comments/questions on the protocol draft. Would appreciate
discussion/clarifications.
(Sorry for the long list. Had more, but had to cut it short :)

Thanks,

------------------------------------------------------------
1) Association Setup:
   - Section 3.2.2.1 says that the association setup state starts with
   the FE attempting to join the NE. ...
   - The FE could already be inside the NE (With an association with
   some other CE) and attempt to start a communication channel between the
   FE and a differnt CE (secondary CE).
   - What triggers an FE to initiate an association setup message to a new
   CE that just became available? Shouldn't there be a mechanism for the CE
   to somehow instruct the FE to start an association with it. (Or do we
simply
    rely on the FEM to instruct the FE to start this new association?)

2) FE-Manager/CE-Manager definitions: They are defined as logical entities
   that operate in the "pre-association phase". I do believe that they can
   operate in the post-association phase as well (as seen in sec 3.2.1) -
   although their primary functionality will be in pre-association phase.
   So defining them to be strictly operational during the pre-association
   phase would be mis-leading.

3) High Touch capability definition: Just a nomencleture comment. I assume
   that the "high" in high-touch comes from the touching of higher layer
   (higher than layer 3) information inside the packet. I feel, it would be
   clearer if the nomencleture used was seen from the packet's perspective
   rather than the stack's perspective and as such I think it would be much
   clearer if it were changed to "deep-touch capability" - where "deep"
   implies checking deep inside the packet.

4) ForCES data and control packet paths:
   - From the text in the draft, it certainly looks like the same
     association/channel is used for carrying both the control and the data
     packets. I believe that this shouldn't be the case. The control
     packets and the data packets should use two independent  channels
     (associations) for sending and receiving messages between  the CE and
     the FE. Any effect on one channel should not effect the other.

     a) The control channel setup between the CE and the FE may (will) have
     totally different requirements from the data channel. E.g. we may
     choose to use TCP as the TML layer to tranfer data from the FE to CE
     (and vice-versa). However, the data channel may not require TCP, or
     in fact, should not use TCP. The data delivery reliability of the
     forces data packets (e.g. routing packets) is independently taken
     care of by the routing protocols themselves. The effect on some
protocols
     of reliably delivering data, but that is not timely may be
disastrous -
     i.e. the effects are unknown.

     b) Irrespective of packet priority, if TCP is employed between the
     CE/FE then packets will be delivered in order. The data packets can
     overwhelm the control packets and can lead to DoS. Not being able to
     deliver the data (routing) packets should not prevent the forces
control
     packets from reaching CE/FE.

     The bottom line is, one should be able to independently choose the
     transport mechanism (TML) between the CE and FE for the forces control
     and data packets.

5) Protocol should provide a Finite state machine for  the FE, Primary CE,
    Secondary CE etc. to explain what happens at each state - what happens
    when an association message is accepted/rejected, when moving from one
    primary CE to another primary CE etc.

6) Heartbeat message:
    - Heartbeat message (sec 6.7)  - does the heartbeat "asynchronously"
    notify the other forces element of its liveness or should it be
    "sychronously" notify.
    - Message transger direction: It says "FE to CE, or CE to FE"
     I assume it should read "FE to CE, <and> CE to FE" or is it that you
     would want the heartbeat in only one direction? Doesn't make sense,
     if there is no heartbeat in the reverse direction nor an ack of your
     heartbeat, how do you even know the heartbeats you are sending are not
     ending up in some black-hole?
     (Based on Fig. 29, where heartbeats are only from FE to Seconday CE).

7) Heartbeat:
    - The heartbeat intervals choosen by the FE should be independent of
that
    choosen by the CE - i.e. each element should be able to independently
    choose the values. No such mechanism exists in the current draft.
    The reason for this is obviously, the CE may not be willing to do
    heartbeats at the rate specified by the FE - since it has to do it with
    hundred other FEs.

    - There should be a mechanism to let an element declare the neighbor
    as inactive or "dead" based on certain number of missed heartbeats.
    Otherwise, what is the algorithm to declare an entity as failed or
    inactive? (This value should also be configurable)

    - The values of heartbeat and "dead" intervals should be controllable
    anytime during the operation of the elements - even after the
association
    has been established. It currently looks like this information is only
    exchanged during the association setup message. Any changes to the
    heartbeat interval would require for us to bring down the
association and
    restart it with new values - which is incorrect operation.

8) High-Availability support (section 7)
    - Detecting CE failure needs to be defined (check heartbeat comment
above)
    - This section lacks a lot of details of failover mechanism and
    maintaining consistency.
        a) If TCP is used as the TML layer, the wire connecting the FE to CE
        can be pulled out causing the FE to declare the primary to be dead
        and switch over to the secondary. When the wire is connected back,
        the TCP session will remain alive and heartbeats and other messasges
        from the original primary can continue. Both the original
primary and
        the secondary are informing the FE to be its primary. What happens
        next? There doesn't seem to be a way for the FE to request a
particular
        CE to be its primary..... (which can be accepted/rejected by the
CE).

9) Editorial: FE/CE definitions:
   - Should probably say that FEs use underlying hardware to provide
   per-packet processing "in the data-path". Otherwise the definition
   sounds quite generic (just making the definition a bit more explicit).

10) Editorial: My preference for the CE and FE IDs would be to use flags to
   indicate rather than ID table partioning - mainly becuase of the
   simplicity and the flexbility it provides.

11) Editorial: There is no "protocol scenarios" section in the draft!
but is
   referred to in multiple places (in sec 3.2.2.1, 3.2.2.2)

12) Editorial: Section 3.1.2 (The TML layer):
   ....It is expected more than one TML will be standardized. The different
   TMLs each could implement things differnetly based on capabilities of
....
   ...It is expected <that> more than one TML will be standardized. <The
   next sentence has to be re-written totally>

--------------------------------------

--
Furquan Ansari
Bell Labs Research                      Ph : 732-949-5249
Holmdel, NJ                             Fax: 732-949-4556

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 15 Jul 2004 21:46:19 -0400

Alan,

> arrive..." I'm not sure what this means.

some missing text; should read:

"then all messages in a batch must arrive at the destination .."

> the field MUST be set to zero.  The receiver SHOULD NOT examine or

Ok. Fixed.

> defined the TLV's within it.

I think you make excellent points in the rest of the text; i will let my
coauthors respond and chip in when i can.
Your radius experience is certainly applicable and valuable.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 15 Jul 2004 23:04:56 -0400

Hi there,
thanks for the comments.

> (Sorry for the long list. Had more, but had to cut it short :)

just shoot - there is nothing that can be termed as lengthy feedback ;->

> Thanks,

The scenario you describe is unclear. At the moment it would be a config
plane issue (FEM->FE for example). Section 7 is supposed to talk about
such issues but doesnt cover that example.
I think once we have the sate machines in place this would crystalize
much better.
I would say this would be on the FE a FEM config event.

>    phase would be mis-leading.

I agree.

>    implies checking deep inside the packet.

I think there may be a lot of glossyware already using high-touch as a
term. I am indifferent.

>      the FE. Any effect on one channel should not effect the other.

There is separation but not explicit mandating of such sepration. Is
there some specific text that bothers you?

>      i.e. the effects are unknown.

The data channel could be a switch fabric.
We are not mandating anything on the data path; we are putting TMLs in
the control path.

>      transport mechanism (TML) between the CE and FE for the forces control

Ok, so TML is not really intended for the datapath; rather CE-FE
traffic. FE-FE should be a separate path.

>     primary CE to another primary CE etc.

Agreed. Our challenge was to at least come to some common agreement
first to merge 3 protocols. Hopefully we can add all that stuff in the
next release.

I will cut it here for readability puproses. I plan to respond to the
rest of your message if noone else beats me to it in the morning.
Again thanks for taking the time.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 16 Jul 2004 07:52:32 -0400

Responses to the second half of our email.

> 4) ForCES data and control packet paths:

Hormuzd responded to this and one of us has misunderstood you.
My understanding of what you meant by Forces Data and control is Data
being the traffic being massaged as a result of Forces policies (eg
packets being V4 forwarded) i.e datapath; Hormuzd understood it as
control traffic with a caveat that such control traffic being redirected
to the CE from the FE.
These are two different beasts. Pls clarify.

>     notify the other forces element of its liveness or should it be

Synchronously sounds more correct. I think the idea of a HB being async
comes from desire to have heartbeats being modeled under the roof of
events.
Weiming?

>      I assume it should read "FE to CE, <and> CE to FE" or

It could be an and/or.
I am not sure if we ended up agreeing on this or not (yet) but some of
the discussion we had involved that such a heartbeat would be subsribed
to and unsubscribed from which makes it optional unless parametrized to
be used.

> is it that you

A lot of protocols have unidirectional heartbeats. The advantage being
less traffic involved. In our case an ACK could be explicitly requested
for (in the main header) which makes it bidirectional.

The heartbeat area is still open to discussion. As an example of a still
contentious issue:
-Should the association setup message be negotiating the FE-CE heartbeat
interval or does that belong elsewhere
- Subscribing/unsubscribing
- are HB just to FE/CE or could they be directed to check health status
of other elements like LFBs etc.

>      (Based on Fig. 29, where heartbeats are only from FE to Seconday CE).

I think that we would need a state machine to be more accurate. I would
say that figure shows more of a scenario.

>     heartbeats at the rate specified by the FE - since it has to do it with

Refer to the association message.
My opinion is that the value should actually be negotiated and such
negotiation happen else

>     inactive? (This value should also be configurable)

Thats the plan; the std/classical scheme: x missed heartbeat + a dead
interval applies.

>     restart it with new values - which is incorrect operation.

If we look at it as a capability or as an attribute of an element
then it should be runtime adjustable (just like all other capabilities
are - example new ones being added and old ones dissapearing)
So i think we oughta move it out of the association message.

>         CE to be its primary..... (which can be accepted/rejected by the

A good TML should have its own transport/network/linklevel HA - which is
different from PL level HA.
As an example, should a link towards the CE go down and there is a
redundant link, the TML would use the redundant link to get to the
CE/FE. Only when a transport restoration fails would the TML inform the
PL about the failure.
In any case the PL is not responsible for maintaining the health of that
TCP connection. It is the responsibility of the TML layer.
In case that wasnt clear - just wanted to clarify (it is talked about in
section 7.1).

The PL level layer is responsible for managing the relationship at the
Forces level.
It seemed easier to just have a static list of CEs, you want the FE side
to be as thin as possible. In my opinion as a matter of fact the FE
should not be involved in any election i.e inter-CE decisions should
make the call on which CE takes over next. The consensus, however, went
the direction you see in the text.

>    simplicity and the flexbility it provides.

I actually proposed the same addressing mode;-> It was proven to me that
infact all that will be doing is making the address a 33 bit field.
Assuming you used one flag bit to select between FE or CE. So instead
that bit is picked of the available 32 bits.

>    referred to in multiple places (in sec 3.2.2.1, 3.2.2.2)

Was added in the last update (-01).

>    next sentence has to be re-written totally>

Make suggestions on the wording.

cheers,
jamal

---

From: Furquan Ansari <[email-masked]>
Date: Fri, 16 Jul 2004 13:54:42 -0400

Jamal,
    Thanks for the response. I do believe that you mis-understood me and
Hormuzd got it right.
I was indeed talking about the forces (control  + data) channel between
the CE and FE. I guess
using the term forces data packets was bound to cause confusion - but
there doesn't seem to
be a better word for it (maybe, "non-forces control packets" - implying
control plane/routing
protocol packets such as OSPF/BGP etc.)

I do believe that they should be seperated out - with two independent
transport connections
between the CE and FE. As I mentioned earlier, the TML requirements of
the forces control
channel may not suit well with respect to the TML requirements of the
forces data channel.
Choosing one transport delivery imposes that on the other.

More comments inline......

>of other elements like LFBs etc.
<Furquan>
Unidirectional heartbeats with ack or a reverse unidirectional
heartbeat, I think, would be a bit meaningless.
The mechanism should be such that both the FE and the CE are allowed to
detect the failure of the other.
How do you even ensure that your heartbeats are reaching the other side
if there are no reverse messages?
Other protocols that employ unidirectional heartbeats, I think,
essentially have uni-directional heartbeats in
both directions  (OSPF is a good example here - where there is no
explicit ack of the hello packet received,
but the hello in the reverse direction essentially provides the same
information).

</Furquan>

>Thats the plan; the std/classical scheme: x missed heartbeat + a dead

<Furquan>
I don't see this being described in the draft anywhere - i.e. no such
negotiotion message exists between the CE/FE
in any of the messages listed in the draft. The value has to be a
negotiated or should atleast be informed to the other
side as to when you would deem the other side to be dead.
</Furquan>

>So i think we oughta move it out of the association message.

<Furquan>
OK..
</Furquan>

>In case that wasnt clear - just wanted to clarify (it is talked about in

<Furquan>
My point was, the TML layer may still think that the transport
connection is still up and not inform the PL
layer that a failure has occured - while the PL layer, based on missed
heartbeats, would declare a failure
and switch over to a new (secondary) CE as its primary CE. This can
happen because, if TCP is used as the
TML transport protocol, there are a number of cases where the TCP
session would still be active in
ESTABLISHED state while the underlying link might be down. Once the link
is back up, the TCP session
continues normally - as if nothing happened.

Question: When do you decide to switch over to the new CE?
    a) ONLY when the TML layer has provided the notification to the PL
layer of transport connection being lost; or
    b) PL layer on its own CAN also decide - due to missed heartbeats -
when to switch over?

</Furquan>

>Make suggestions on the wording.
<Furquan>
I don't understand the sentence properly to make a suggestion. However,
something as simple as replacing <The> at
the begining of the sentence with <On> seems to make sense.
</Furquan>

Thanks,

---

From: Furquan Ansari <[email-masked]>
Date: Fri, 16 Jul 2004 14:26:00 -0400

Jamal,
    Thanks for the clarifications. Comments inline....

>I would say this would be on the FE a FEM config event.

<Furquan>
Ok...as I mentioned in the parenthesis, you do rely only on the FEM to
instruct the FE when to start a new
association.
I was just wondering if there would ever be a case where the CE might
want to start the association setup .......
</Furquan>

>Again thanks for taking the time.

<Furquan>
As already pointed out in the other mail, I believe you have
misunderstood me with respect to the forces
data packets - I wasn't talking about the data packets on the datapath,
but the control plane packets from
neighboring NEs redirected as forces data packets from the CE to the FE.
</Furquan>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 16 Jul 2004 19:54:54 -0400

On Fri, 2004-07-16 at 13:54, Furquan Ansari wrote:
> Jamal,
>     Thanks for the response. I do believe that you mis-understood me
> and Hormuzd got it right.
> I was indeed talking about the forces (control  + data) channel
> between the CE and FE. I guess
> be a better word for it (maybe, "non-forces control packets" -
> implying control plane/routing
> between the CE and FE.

Dont mean to restart this discussion all over again; the archives have a
lot of discussion on this topic;->

Ok, why do you think two would be sufficient? Would they be going over
the same link? Why not 8 or 1 if they are going over the same interface?
could we use prioritization of the different messages
over the same link to achieve the same end goal?

>  As I mentioned earlier, the TML requirements of the forces control

Depends really. TCP HOL blocking will be a problem in cases of congested
links. Considering that you could put in place rate controls, and QoS
a lot of things could be made to work.
Do we really wanna start this discussion?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 16 Jul 2004 20:22:53 -0400

> heartbeat, I think, would be a bit meaningless.

Unidirectional heartbeats would be a choice for resource conservation.
You use less bandwidht and processing resources.
quiet a few protocols use them for this precise reason.

> The mechanism should be such that both the FE and the CE are allowed
> to detect the failure of the other.

I wouldnt mind that there is an option (not mandatory) to have both
sides heartbeating the other side.

> How do you even ensure that your heartbeats are reaching the other
> side if there are no reverse messages?

So you dont like ACKs?

> but the hello in the reverse direction essentially provides the same

Off the top of my head look at VRRP or TCP Keepalives for better
examples of unidirectional heartbeats (the later being optional and
including ACKs)

> side as to when you would deem the other side to be dead.

Noted. We should make sure it is well represented in the next release.
Moving the heartbeat to be a capab will help with the negotiation.

> ESTABLISHED state while the underlying link might be down. Once the
> link is back up, the TCP session

I would see the heartbeats as something of a plan B.
In other words, the failure scenario would be discovered first by the
TML at the link level before those heartbeats expire.
This is not unlike OSPF where the hellos would eventually catch a dead
neighbor but a link failure would be caught by say a device driver and
passed on to OSPF as a signal for faster detection.

To summarize: The TML failover detection should be faster by several
orders of magnitude than the configured PL heartbeats.

>     b) PL layer on its own CAN also decide - due to missed heartbeats
> - when to switch over?

My opinion is that when the TML would protect you probably upto
the OSI transport level; i.,e it would take care of
link/network/transport protocol availability and recover those if it can
much faster before the PL layers heartbeats expire.
Of course this is all assuming that the TML has something built in for
availability.
Failure of TML to signal problems to the PL would result in PL missed
heartbeats.
The PL will protect you in case the other PL side dies while the
transport/network/link is healthy.
Not sure if that makes sense.

> I don't understand the sentence properly to make a suggestion.
> However, something as simple as replacing <The> at

How does this rewording sound:
"It is expected that more than one TML will be standardized.
The different proposed TMLs are expected to implement things
differently influenced by capabilities of underlying media
and transport."

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 16 Jul 2004 20:53:56 -0400

> instruct the FE when to start a new

True.

> want to start the association setup .......

Should be doable if you have a FEM-CEM interface.
We actually did implement such a FEM-CEM interface (prorpietary
protocol) in one of the merged proposals and found it added some
complexity.
It did get a little challenging with a few too many CLI interfaces (not
to forget we were also interfacing to SLP for discovery).

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 19 Jul 2004 12:48:14 +0800

Hi  Alan,

Sorry not to make a reply sooner owing to some business.

I think the comments you made and the information supplied reagarding the TLVs
in the protocol PDU are very valube to us.  I will raise a discussion on this in
the design team to consider your suggestions below. I think many of your
suggestions will be reflected in the next update.

Also some replies inline.

Thank you very much.

Weiming

----- Original Message -----
From: "Alan DeKok" <[email-masked]>
> defined the TLV's within it.
[Weiming] Sure.

> without referring in detail to the TLV's that they contain.

[Weiming] It is obvious very valuble to evaluate the scheme to organize the
protocol in the way RFC3588 uses. I also appreciate the ABNF used there. Now I
think what we need to discuss more to decide if we should take the scheme is,

1) how many TLVs we may have in the protocol layer,
2)how the TLVs conform with the Model work.

For 1),  if there are many TLVs that should be defined by protocol layer, I
think it is surely worth using the way as RFC 3588. A little difference of RFC
3588 with ForCES is, we have a specific FE model document associated with the
base protocol. As a result, I just wonder if some of the attributes TLVs should
be defined in the model or not.

For 2),  I just see currently there may be a missing work between the protocol
and the model, that is, how entities (incuding attributes, capabilities, events,
etc) will be eventually coded in protocol and who is in charge of such coding
definition. I think this will affect the PDU definition in protocol also. If
this is defined by model, I think the TLV format can be more uniform and there
will be much less TLVs in protocol, or else, there will be more. We actually
have left this as an open issue in the protocol text.
[/Weiming]

>     boundary is reached.  The length of the padding is not reflected in
[Weiming] Let the length not include the padding is very helpful for correct
message interpreting by a receiver.

> TLV's defined in sections 6.3.1, 6.3.2, 6.4.1, and 6.5.
[Weiming] This actually refers to the question "if we should allow using
recursive TLVs (TLV in TLV)". We will evaluate it. The idea to have a specific
TLV for Type ID and Instance ID is valuable.

> fewer implementation errors.
[Weiming] Agreed.
> enterprise code, e.g.  "type, length, 32-bits of vendor-code, vendor
[Weming] Agreed.

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 19 Jul 2004 14:28:56 +0800

Hi Furquan,

Thank you for the valuable comments. Jamal and Hormuzd have made some replies
and I just have a little more in the lines.

Thank you again.

Weiming

----- Original Message -----
From: "Furquan Ansari" <[email-masked]>
>      i.e. the effects are unknown.
[Weiming] We actually have spent quite a lot time discussing the control channel
and data channel before. The main conclusion is separation of data and control
channel is valuble, especially for grasping more tranmit efficiency and
reliability. But for DoS protection, we may be careful not to purely highly rely
on such separation for every thing. It seems quite case specific. E.g., a C
channel with TCP and D with UDP do not supply  happy results, while two all with
TCPs may be much happier. Some of our results may be a little help for this:
http://www.ietf.org/proceedings/04mar/slides/forces-2.pdf
I believe Hormuzd will also present more results on this soon.

>      would want the heartbeat in only one direction?

[Weiming] a heartbeat message is only in one direction, though the heartbeat
mechanism can be configured bidirectionally.

>      Doesn't make sense,

---

From: Furquan Ansari <[email-masked]>
Date: Mon, 19 Jul 2004 13:59:52 -0400

Hi Jamal,

    It was not my intention to restart something that has already been
discussed in detail. I will try to
go over the archives to determine the rationale. If you have a pointer
on the thread (approx timeframe),
it would be of great help.

Some more comments inline....

>over the same link to achieve the same end goal?
<Furquan>
Well... I am not saying that it "should" be two - I was only pointing
out that it should be more than "one" - independent
associations for control and data. As I previously mentioned, and as you
point out below, TCP HOL blocking would
indeed be an issue.
Anyway, I will try and go over the archives.
</Furquan>

Thanks,

---

From: Steven Blake <[email-masked]>
Date: Tue, 27 Jul 2004 19:56:30 -0400

> Not sure if that makes sense.

Needless to say, standalone TCP isn't going to satisfy this.  So either
there is going to be something on top of TCP that is part of the
"TCP-based TML", or these functions need to live in the PL.

Since there are transports with the capabilities you mentioned, I would
prefer to see these functions remain in the TML (meaning that TCP will
need to be augmented), rather than the PL, to avoid duplication of
functions.

Regards,

// Steve

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 29 Jul 2004 13:58:02 -0400

> "TCP-based TML", or these functions need to live in the PL.

If the underlying transport does some things for me, i dont mind taking
advantage of it. Example if I could use VRRP to move links around
without being notified at the PL layer (by policy choice) then i would
rather do that rather than reinvent the wheel.
Of course there are other approaches such as TIPC or SCTP which are more
feature rich and do everything for you.

> need to be augmented), rather than the PL, to avoid duplication of

It is good there are all sorts of results being presented on TMLs.
They should help us come up with good conclusions on what TMLs
would be useful. It may turn out that TCP with proper QoS tuning may be
good enough even under heavy congestion (such as a DOS); i am going to
keep my fingers crossed. Hormuzd and co are presenting this in SD.

I think eventually what counts in the end will be how fast can your
NE run - and TML choices will have a role to play.

cheers,
jamal