|
>On
the Mandatory Flag aspect, there is one key reason why any protocol does;
it is to offload the application from doing base data-element
checking.
How and why ? Sounds
dangerous to me.
-Sanjay
Sanjay,
Inline.... Woj#2
Woj
I agree only
on the following:
- A TLV might be mandatory for
one application or use-case, and optional for another application. We do
need to clearly specify in the draft if a TLV is mandatory or optional for
a given application (which boils down to specifying this per ANCP message
and message type).
Woj#2>
I interpret this to mean that you've taken on the action to clarify the
protocol spec text, and also prepare the table of TLVs indicating where each
TLV is mandatory, and where optional. Please let me know if this is not
so
- We should clearly specify the
behavior for handling missing mandatory TLVs in received
messages.
To me the utility
of flagging a TLV as mandatory or optional via the protocol is at best
debatable. If a buggy implementation on the sender incorrectly sets a
“known” TLV as mandatory (when it is not) or vice-versa, do we want the
receiver to infer the handling of this TLV based on what the sender tells
it? I don’t think so. Ideally, we want the receiver and sender to have a
common understanding of what is mandatory and what is optional based on what
is in the spec, and handle the TLV based on that understanding. As Peter
mentions, the spec clearly spells out TLVs that are mandatory and optional.
Also, I don’t see a major advantage of your proposal with respect to
debuggability.
Typical case where
it does make sense for the sender to set some flag in the TLV to control the
handling of the TLV on the receiver is for “unrecognized” TLV
types…e.g.
- Receiver is an intermediate
node, which consumes the message but also needs to forward it along to
other nodes. Here the sender can flag the handling of the TLV to the
receiver (e.g. discard or forward if the TLV type is not recognized by the
receiver). This doesn’t quite apply to ANCP (messages are confined to be
between two peers).
Woj#2> It
happens that an ANCP relay has already been proposed in the DSL Forum, and
under in some situations it could be a viable entity. By NOT designing
such flags now, we're likely making things more
difficult in the future.
Anyway, since there doesn't seem to be much enthusiasm for "Mandatory"
flags, I'll put the subject to rest for now.
- If handling of an unrecognized
TLV on the receiver needs to be different for an optional TLV versus a
mandatory TLV. Here the receiver doesn’t understand the TLV type, but can
infer the handling based on the flag in the TLV. However, do we want the
treatment of “unrecognized” TLVs on the receiver to be different for
optional and mandatory TLVs (e.g. silently discard an unrecognized
optional TLV…but discard and also send an error back for an unrecognized
mandatory TLV). I don’t think this is necessary. However, if we do want to
do this, then may be the flag in the TLV should explicitly indicate the
handling for the TLV (e.g. “silently discard if un-recognized” versus
“discard and send an error back”)…as opposed to just flagging these as
“mandatory” versus “optional”.
Woj> Of course
it is, the whole spec is about this. The problem comes when people
start to re-use well known TLVs for different applications, and then
trying to make sense of it all >becomes non-trivial. Why do you think
both BGP and Diamater, and a number of other protocols have definied
"Mandatory" flags? Just for kicks? It's a well known protocol design tool,
that >comes handy when re-using same data across multiple
applications.
We should look at
why these protocols are doing this (as opposed to blindly following). For a
counter example, please take a look at OSPF traffic engineering extensions
(RFC 3630).
Woj #2 > The irony of the above statement in view
of the initiators of
ANCP blindly following GSMP is hopefully not lost on you. On the
Mandatory Flag aspect, there is one key reason why any protocol does;
it is to offload the application from doing base data-element
checking. Anyway, we can move on.
-Woj.
Cheers
-Sanjay
From:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec
(wdec)
Sent: Tuesday, April
29, 2008 3:03 PM
To: Peter
Arberg; DE CNODDER Stefaan; Busser, M; ancp at ietf.org
Cc: Haag, T
Subject: Re: [ANCP] Mandatory TLVs in
draft-ietf-ancp-protocol proposal
Hi Peter,
continued
inline...
From:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Peter Arberg
Sent: 29 April 2008 20:39
To: Wojciech Dec (wdec); DE CNODDER
Stefaan; Busser, M; ancp at ietf.org
Cc: Haag, T
Subject: Re: [ANCP] Mandatory TLVs in
draft-ietf-ancp-protocol proposal
Hi
Woj,
please see inline
in your answers
From:
Wojciech Dec (wdec) [mailto:wdec at cisco.com]
Sent: 29. april 2008
11:07
To: Peter Arberg;
DE CNODDER Stefaan; Busser, M; ancp at ietf.org
Cc: Haag, T
Subject: RE: Re: [ANCP] Mandatory
TLVs in draft-ietf-ancp-protocol proposal
Hi Peter,
From:
Peter Arberg [mailto:parberg at redback.com]
Sent: 29 April 2008
19:34
To: Wojciech
Dec (wdec); DE CNODDER Stefaan; Busser, M; ancp at ietf.org
Cc: Haag, T
Subject: RE: Re: [ANCP] Mandatory
TLVs in draft-ietf-ancp-protocol proposal
Hi
Woj,
I agree with
Michael and Stefan on this issue, I do not see a need to change the
existing
implementation
with a mandatory/optional flag.
Woj>
Please indicate where in my proposal did you see anything
about changing
existing implementaions?
PAR> I
might have misunderstood your email, but I read it as if you suggest a
high bit
value in existing
TLV's to be interpreted as a mandatory flag.
Woj#2> Yes, I
suggested (in proposal 2) that *if* the WG found there to be a common set
of TLVs currently in use, then the high-order bit set to "0" (ie as today)
could be interpreted as "mandatory", and the rest of the TLV's redefined
with a high order "1". To extsing implementations, the "new" TLVs would
just look like a different TLV#, while anyone wishing to implement
the more robust error cheking logic based on this bit, would be free
to do so.
If you are simply
talking about new capability type definitions, then why do you not bring
up
the additional
flag in a new internet-draft defining what capability type you have in
mind ?
Woj#2> No, a
new capability was not intended, but could also be
considered.
I think I
understand your arguments, but I do not agree with them. I think most
places in
the draft it
is clear what is defined as mandatory and optional.
I agree on
the point we need to go through the draft and make clarifications to
what TLV's
in what
capability types are mandatory and optional, and make more description
what should
happen if
mandatory TLVs are not included.
Woj>
Exactly.
I think the
DSLF TR-101 document has a good example of such a description in it's
"Table
3 - Access loop characteristics sub-options", and I think if we do the
same for each
capability
types TLV's in the ANCP draft it will be a good
help.
Woj>
Indeed,
pre-ceeded by some rationalization. The appears to be no reason for
some of the DSLF "mandatory" TLVs.
PAR> I do not
see a problem with re-visit in the draft if a TLV should be optional or
mandatory, so if
that is the
intend, then I'm all for an email discussion on a TLV by TLV basis if we
think it is a
manfdatory or
optional information inside the specific capability
type.
Woj#2> Great,
because any change to the mandated set *will* affect existing
implementation .
I do not
agree with your point that it is not listed if "rate" is mandatory or
optional, it is clearly
listed as a
mandatory TLV, and as such it should be included in the port up
message, I really
do not
understand what confusion you have with this.
Woj> The
text states:
5.
Type (DSL Line Attributes = 0x04):
Length
: variable (up to 1024 bytes)
Value
: This consists of one or more Sub-TLVs corresponding to DSL
line
attributes. No sub-TLVs other than the "DSL type" and "DSL
line
state" SHOULD be included in a PORT DOWN message.
The
general format of the sub-TLVs is identical to the general TLV
format.
The value field in each sub-TLV is padded to a 4-octet
alignment.
The Length field in each sub-TLV contains the actual
number
of bytes in the TLV (not including the padding if present).
Current
defined sub-TLV types are start from 0x81.
Maybe you
can point me to where exatly it is stated clearly as being mandatory,
or otherwise explain why you "not agree"?
PAR> I think
you forgot to read the most important part where the actual TLV is
defined.
Woj#2> I
didn't. This part talks about the sub-TLV, not the main TLV 0x04. Do you
see my point now?
Type
(Actual-Net-Data-Upstream = 0x81): Actual upstream net data rate on a
DSL line.
This is a
mandatory TLV.
Length
: (4 bytes)
Type
(Actual-Net-Data-Rate-Downstream = 0x82) : Actual downstream net data rate
on a DSL line.
This is a
mandatory TLV.
Length :
(4 bytes)
The fact you
say "Port UP" and "OAM" is best considered as legacy applications, I
have some
trouble with
this as well, since ANCP running in production networks use them, and
as such
it is a
central part of the ANCP specifications we need to finish as soon as
possible.
Woj> I
should have said legacy applications from a protocol messaging
perspective, not usage, nor support. It's quite clear that GSMP
derived messaging has baggage that is un called for in new
applications.
I think
Stefaan's example is very valid, that we do not need to make mandatory
requirements to
what
receivers of ANCP information use such info. for. I don't think
we should try and make the
ANCP
specifications "mandatory" for box behavior, I think it is much more
important for the
working group
to make the protocol specifications easy to understand and get the
first documentation
finish and
published, so the protocol can be used for different sets of
applications, and make sure
new
applications can be added later.
Woj>
Indeed the aim of the WG to define a protocol that is relatively
simple and easy to understand, not just to implementers but also to
people using it, and across vendors. Currently, having anyone
operating the device be familiar in what cases a TLV is mandatory and
in what optional requires a thorough understanding of the spec, across
applications. This is not easy, but I'll conceede that for the
applications implemented so far we could live with it.
I do think
that by documenting if a TLV is mandatory or optional inside a
specific capability type,
it is easy to
understand what must be sent to support the defined
application/capability type.
Woj> Of
course it is, the whole spec is about this. The problem comes
when people start to re-use well known TLVs for different
applications, and then trying to make sense of it all becomes
non-trivial. Why do you think both BGP and Diamater, and a number of
other protocols have definied "Mandatory" flags? Just for kicks? It's
a well known protocol design tool, that comes handy when re-using same
data across multiple applications.
PAR> I might
be wrong, but I think I can find as many or more protocol examples who do
not include
a
mandatory/optional flag, so examples can always be found which will
support the point you are trying
to
make.
I do not see a
problem with a new internet-draft which defines new capability-types and
where a TLV
mandatory flag is included, I
do see a problem if the intend is to try and adjust what already
exist.
Woj#2> Ok, so if adjusting
is only scoped to what doesn't exist, as my proposal laid
out conditionally, you're fine.
Then if
anybody want to include new capability types or sub-TLVs later to
address specific applications,
then I think
changes can be discussed at that time instead of trying to change
existing protocol
implementations.
Woj>
Again I ask, where in the proposal did you see
*anything* requiring a change to an existing implementation.
Please be specific. I see that
your main objection is on this issue, which means that you accept
proposal 1 (have such a flag for new TLVs/apps).
It would also be useful if
you indicated whether the list of TLVs provided below is what you'd
expect to be the minimum mandatory set.
PAR> at the
moment I read the draft as having defined the TLVs mandatory as you
describe, except
I also read
it as the dsl-type = 0x91 must be part of the port down. If this is needed
or not is a different
discussion.
Woj#2> Ok.
Thanks. But please do come back to me if you see that the proposal impacts
an exiting implementation. I conclude that there is no problem with doing
changes to stuff that isn't currently used.
Woj.
cheers,
Peter
Cheers,
Woj.
cheers,
Peter
From: ancp-bounces at ietf.org
[mailto:ancp-bounces at ietf.org] On
Behalf Of Wojciech Dec (wdec)
Sent: 29. april 2008
02:28
To: DE
CNODDER Stefaan; Busser, M; ancp at ietf.org
Cc: Haag, T
Subject: Re: [ANCP] Mandatory
TLVs in draft-ietf-ancp-protocol
proposal
Stefaan,
a number of
points:
1. There currently is to
my knowledge no implementation of ANCP there that doesn't send
the DSL Line attributes info by default in Port-UP messages? The
support of HS on the NAS is an orthogonal issue.
2. The current ancp
protocol draft (02) doesn't say whether the rate info is optional or
mandatory, it only states that the sub-TLVs are mandatory. Based on
this, an implementer can be justified to expect port-ups to
*always* have the rate-info tlv (ie treat them as mandatory).
Equally, she's justified in considering this as
optional.
3. The port-up
and OAM are best considered as legacy applications for ANCP.
The re-use of any of the GSMP defined fields is already out of the
question due to constrains put in place by the existing use-case
messaging. Needless to say, this wasn't as thoroughly designed as it
should have been, and with the OAM and port-up apps being
coupled.
4. It's up to the
application to define what TLVs are mandatory and which aren't, as
you also state. The AN does not need to know what the NAS will
do with the info, BUT it needs to send the right TLVs for the
application (eg if we had a hypothetical AN that only sends
Port-up's with line-id, it would be next to useless for the dynamic
shaping application).
With all this in mind
it's useful to re-read what I proposed originally below regarding
the mandatory flag: 1. "have this TLV Flag be defined only for
new applications" and 2. The notion of the
mandatory flag applying to existing TLVs being "conditional on deriving
a suitable "commonly used" TLV set." The
latter point would ensure that existing implementations do not need
to change, but future ones can take advantage of the extra
robustness.
Hence, can the WG derive
a set of commonly used, i.e. always used, TLVs for existing
implementations?
The list I came up is as
follows (making them pretty much mandatory TLVs if it agrees with
the views of others);
Port-up message
(0x80);
Extension-TLV (dsl tech type)
Access-Loop-circuit-id (0x01)
DSL
Line Attribute (0x04) with the following sub
TLVs;
DSL-Type = 0x91; Actual-Net-Data-Upstream = 0x81;
Actual-Net-Data-Rate-Downstream = 0x82
Port-down message
(0x81);
Extension TLV (dsl
tech type)
Access-Loop-circuit-id
(0x01)
DSL Line Attribute
(0x04) with the following sub TLVs;
DSL line state =
0x8F
All other TLVs are
optional.
Would appreciate
confirmation from the WG regarding the above.
Thanks,
Woj.
From: DE CNODDER Stefaan
[mailto:stefaan.de_cnodder at alcatel-lucent.be]
Sent: 29 April 2008
09:52
To:
Wojciech Dec (wdec); Busser, M; ancp at ietf.org
Cc: Haag, T
Subject: RE: [ANCP] Mandatory
TLVs in draft-ietf-ancp-protocol
proposal
Hi
Woj,
Take the
following example: I have a network with 2 NASses, NAS-A is doing
hierarchical shaping, NAS-B just wants to have the port
information but is not doing hierarchical shaping (it is doing
other things like OAM, ...). This means NAS-A needs the
bandwidth, while NAS-B does not need the bandwidth. How
should the flag be set in this case by the AN? Set to
'Mandatory' for the port up messages to NAS-A, and set to
'Optional' for port up messages towards NAS-B? Or is it always set
to 'Mandatory'? From your answer below, I understand that it
should be set to 'Optional' towards NAS-B. Is that
correct?
NAS-B
will simply ignore the bandwidth TLV. If such a flag would
exist, and the flag is set to 'Mandatory' by the AN to NAS-B, what
should be the behavior of NAS-B? Should it reject the whole
message? Maybe NAS-B is not supporting hierarchical shaping,
so it might not support the bandwidth TLV. Today, the
bandwidht TLV is only mandatory to be put in the port up messages,
but for the receiver there is nothing
mandatory.
I
believe the original intend of ANCP was that the AN does not need
to know what the NAS is doing with this information, the use of
the bandwidth is also not specified by ANCP, only an example is
given (which is shaping). In the future there may be
applications for which TLVs will be mandatory which are now
optional.
regards,
Stefaan
From: Wojciech Dec (wdec)
[mailto:wdec at cisco.com]
Sent: maandag 28 april 2008
21:33
To: DE
CNODDER Stefaan; Busser, M; ancp at ietf.org
Cc: Haag, T
Subject: RE: [ANCP] Mandatory
TLVs in draft-ietf-ancp-protocol
proposal
From: DE CNODDER Stefaan
[mailto:stefaan.de_cnodder at alcatel-lucent.be]
Sent: 28 April 2008
17:15
To:
Wojciech Dec (wdec); Busser, M; ancp at ietf.org
Cc: Haag, T
Subject: RE: [ANCP]
Mandatory TLVs in draft-ietf-ancp-protocol
proposal
Take
the bandwidth sub-TLV in port up messages as example. The
current protocol spec says that it is mandatory to be sent
in port up messages. that's ok. But it is not
mandatory for the receiver to process the bandwidth
sub-TLV. What is done with this information by the NAS is
not specified by ANCP, so you cannot make it mandatory for the
receiver side.
Woj>
Is the information required by the application? It would appear
for the dynamic shaping use-case to be most certainly so. Hence
it is absolutely mandatory, otherwise the message makes no sense
for the application. In any
case, if
So it
looks to me that the flag can only indicate what the receiver
should do. Then the flag makes sense.
Woj>
The
flag tells the receiver what info the sender thinks is required
to carry out the application. This in almost all cases has to
match up to what the receiver thinks is required. The
sender doesn't tell the receiver what to do with the
info.
If the
receiver knows what is mandatory, then I do not see a reason why
this has to be made explicit in the protocol. It would
only complicate the protocol. As already said by Michael:
if a mandatory TLV is not there, then it is just a
bug.
Woj>
Can you specifically describe what aspect of the protocol does
it complicate? It's
just making explicitly clear what the protocol already has to
implement anyway to be of any use.
As to whether it is
a bug, having such explicit marking makes it clear what/where
the problem is when observing a messaging flow vs a lot of
deduction work. In any case, the other point being made
here is that today the protocol does NOT specify what
should happen if a mandatory TLV is missing.
-Woj.
regards,
Stefaan
From: Wojciech Dec
(wdec) [mailto:wdec at cisco.com]
Sent: maandag 28 april 2008
16:28
To: DE
CNODDER Stefaan; Busser, M; ancp at ietf.org
Cc: Haag, T
Subject: RE: [ANCP]
Mandatory TLVs in draft-ietf-ancp-protocol
proposal
It's actually a mix
of both. Inline...
From:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of DE CNODDER
Stefaan
Sent:
28 April 2008 16:04
To: Wojciech Dec (wdec);
Busser, M; ancp at ietf.org
Cc: Haag, T
Subject: Re: [ANCP]
Mandatory TLVs in draft-ietf-ancp-protocol
proposal
Hi,
This
new mandatory flag, what is exactly its
meaning?
(1) if
flag set to "mandatory", then the *receiver* of this TLV MUST
process it, and if unrecognized must drop the
message
If a
received TLV is has the "mandatory" flag set then
the receiver MUST drop the message and report an error to the
sender if it doesn't recognize the
TLV.
If a
the receiver expects a "mandatory" TLV but doesn't
receive it, the message MUST be droped and
an error report sent to
the sender.
OR
(2) if
flag is set to"mandatory", then the *sender* MUST include it
in the message for which it is defined
The
sender MUST include mandatory TLVs as defined by the
protocol-spec/applications.
The
current protocols draft says for certain TLVs that they are
mandatory, but that applies to the sender of it
(interpretation 2). The flag would indicate
interpretation 1 (like for Radius VSAs?)?
If
the higher order bit is set to "0" means that it is mandatory,
then currently defined optional defined TLVs suddenly become
mandatory which is not good.
Woj>
Only the currently used TLVs become mandatory. If they
are not used/implemented we can re-define them as optional
(set flag to 1) at no cost.
But I
would first to understand the exact meaning of this mandatory
flag. Defining such a flag indeed looks useful but then
as interpretation 1, and I would say that if flag set to 1,
then it is mandatory and actually, it is possible that a TLV
is sent sometimes as optional and sometimes as
mandatory.
Woj>
Precisely, that is possible on a per application
basis. Having
the flag would make troubleshooting of a message
flow much more explicit (today, with any problem one
has to browse the drafts to figure out what MUST be there vs
what SHOULD be there all while looking what is
actually there)
Regards,
Woj.
regards,
Stefaan
From:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec
(wdec)
Sent:
donderdag 24 april 2008 14:19
To: Busser, M;
ancp at ietf.org
Cc: Haag, T
Subject: Re: [ANCP]
Mandatory TLVs in draft-ietf-ancp-protocol
proposal
Hi
Michael,
inline...
From:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org]
On Behalf Of
Busser, M
Sent: 24 April 2008
13:13
To:
ancp at ietf.org
Cc: Haag, T
Subject: Re: [ANCP]
Mandatory TLVs in draft-ietf-ancp-protocol
proposal
I see the
problem but i can not see, how an additional flag will help
solving this problem.
Lets assume your
first proposal.
If an
implementation does not send the complete TLV, even it
is defined to be mandatory, I would call this
a bug and I can not see, how an additional flag can
help here.
Woj> The way
it helps, and other protocols bear proof of this scheme, is
that it is easier for implementations to reconcile errors
resulting out of "Mandatory" and "Optional" TLV sets.
The key to this lies on a per application basis. One
application may mandate TLV A for operation, while another
might not. Resolving such issues when implementing or
troubleshooting multiple applications is not always trivial.
Your second
proposal seems obviously be required to keep existing
things working, if we agree on your first
proposal.
But from my
point of view it also assumes, that all existing
implementations are using the same set of TLVs now.
And I am
not sure about that.
Woj> This
would be a good thing for the WG to discuss. There most
evidently is a fair amount of "dead wood" in the
current spec, ie stuff that nobody yet implements or
cares about. In the former case, we could re-cast that
material using the new notions/extensions, in the latter
case simply chop it out.
Therefore I
disagree with your first proposal. I recommend, the better
way will be to be more precise in
definitions.
In my mind, it
is a bug, if a mandatory TLV is missing. It is up to the
robustness of the implementation to deal with this
situation.
Is it really
neccesary to define the behavior of a network element in
this case of failure in the ancp protocol
itself?
Woj> Other
people have faced this problem before, and I would rather go
with the lessons they learned, rather than clinging to hopes
of perfect textual definitions and implementations. Other
than backwards compatibility, I do not see in your
statements a valid reason to object to the
1st proposal, particularly for new applications since
it can only make things more robust. The counter argument of
being precise in the definitions, as evidenced by the
current spec, is admirable and needs to be there, with this
proposal providing an extra level of robustness and
visibility of any problems.
If optional TLVs
are not present in a message, we should describe some kind
of default behaviour, as you already
stated.
Comments on
draft-ietf-ancp-protocol-02.txt:
It is not
clearly stated, if the TLV "DSL Line
Attributes " is
mandatory or optional.
In fact it is
mandatory because some of its SubTLVs are mandatory.
We should spent
a sentence to make this clear.
It is not
clearly stated, if the TLV "Service-Profile-Name" is mandatory or
optional.
I prefer
mandatory because it is essetial for the use case Line
Config.
Section 5.4.3
Line Config, where the TLVs are mentioned (page
35):
...defined in section 5.4.1.... must be
corrected to ...defined in section
5.4.2........
Section
5.4.4 OAM, where the TLVs are mentioned (page 36 and
page 38):
...defined in section 5.4.1.... must be
corrected to ...defined in section
5.4.2........
Best Regards;
Freundliche Grüße
Michael
Busser
T-Systems Enterprise Services
GmbH
Production Line Network
Centric Systems
ICT-Systems
Integration
Network Integration
Services
Brückes 2 -8, 55545
Bad Kreuznach
Postfach 9100, 55541 Bad Kreuznach
+49
671 8333 8911 (Phone)
+49 521 9210 3859
(Fax)
+49 151 1211 9689 (Mobile)
E-Mail: michael.busser at t-systems.com
Internet: http://www.t-systems.com
T-Systems
Enterprise Services GmbH
Aufsichtsrat: René Obermann
(Vorsitzender)
Executive Committee: Reinhard Clemens
(Vorsitzender)*, Helmut Binder, Albert Henn, Olaf Heyden*,
Katrin Horstmann, Ulrich Kemp, Wilfried Peters*,
Dr.
Herbert Schaaff*, Zvezdana Seeger*
Handelsregister:
Amtsgericht Frankfurt am Main HRB 55933
Sitz der
Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr.
DE87523644
*Geschäftsführer gem. § 35
GmbHG
Notice: This transmittal
and/or attachments may be privileged or confidential. If you
are not the intended recipient, you are hereby notified that
you have received this transmittal in error; any review,
dissemination, or copying is strictly prohibited. If you
received this transmittal in error, please notify us
immediately by reply and immediately delete this message and
all its attachments. Thank you.
T-Systems – Business
flexibility
Von:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org]
Im Auftrag von
Wojciech Dec (wdec)
Gesendet: Mittwoch,
23. April 2008 14:54
An:
ancp at ietf.org
Betreff: [ANCP]
Mandatory TLVs in draft-ietf-ancp-protocol
proposal
Hi
All,
Continuing
with the series of e-mails regarding basic protocol issues
still to be addressed, I now would now like to ask your
feedback regarding the distinction the protocol places on
mandatory TLVs. Given the length of this mail I'll first
cut to the proposal, and after it you can find the problem
description.
The proposal
which I am putting in front of the WG is to define a new
TLV format which contains at a minimum a Mandatory flag
(much like Radius VSAs do). We could have this TLV Flag be
defined only for new applications.
A second
proposal would be try to make this flag work with existing
ones by for example defining the highest order bit of the
TLV# field to mean "Mandatory" when set to "0". This would
be invisible to exiting implementations, but newer ones
may have problems in communicating with older ones when
the latter do not send all TLVs. But that can also be
addressed by simply forming the set of mandatory TLVs to
be the ones that all implementations currently send by
default.
Without
additional feedback, I will assume that the WG is fine
with the first proposal, and also with the 2nd one
conditional on deriving a suitable "commonly used" TLV
set.
The problem in
more detail:
Currently the
situation is that Mandatory TLVs are only stated to be as
such in the body of the protocol draft spec, with an
implementer having to scour fairly attentively the text.
Eg "Type (Access-Loop-Circuit-ID = 0x01): This is a
mandatory TLV", etc.
The behaviour
of an implementation that receives a message with a
missing mandatory TLV is not defined at all, and the
opposite is handled but not very robustly, i.e. when
receiving a TLV but not recognizing it, and implementation
is free to discard it (even if it is mandatory!). This is
a recipe for interoperability problems and an
implementation mine field.
This problem
is complicated by different applications. For example the
current OAM section states the following regarding TLVs
that are to be carried in the request message (my
italics):
"
Following
TLVs
can appear in this message:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in
section 5.4.1
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06):
defined in
section 5.4.1.
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03):
defined in section
5.4.1.
o Type (OAM-Loopback-Test-Parameters = 0x07): Parameters
related to
loopback test. This is an optional TLV. If this TLV is not
present
in the request message, the DSLAM SHOULD use locally
determined
default values for the test parameters.
"
(NOTE:
The last "SHOULD" appears to be inappropriate. If the TLV
is missing, the DSLAM MUST have some default parameters,
or return an error)
The
"can" above indicates that they're all optional, while
clearly the application cannot run its course without one
or more of these fields. Here we have a case where one
could have a perfectly compliant implementation that
ignores all these TLVs…
-Woj.
|