Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 6 May 2008 18:33:28 +0200

Sanjay,
 
Inline.... Woj#2

________________________________

	From: Sanjay Wadhwa [mailto:[email-masked]] 
	Sent: 30 April 2008 07:40
	To: Wojciech Dec (wdec); Peter Arberg; DE CNODDER Stefaan; Busser, M; [email-masked]
	Cc: Haag, T
	Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal

	Woj

	  I agree only on the following:

	1.	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

	1.	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.

	1.	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.

	2.	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: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
	Sent: Tuesday, April 29, 2008 3:03 PM
	To: Peter Arberg; DE CNODDER Stefaan; Busser, M; [email-masked]
	Cc: Haag, T
	Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal

	Hi Peter,

	continued inline...

________________________________

		From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Arberg
		Sent: 29 April 2008 20:39
		To: Wojciech Dec (wdec); DE CNODDER Stefaan; Busser, M; [email-masked]
		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:[email-masked]] 
			Sent: 29. april 2008 11:07
			To: Peter Arberg; DE CNODDER Stefaan; Busser, M; [email-masked]
			Cc: Haag, T
			Subject: RE: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal

			Hi Peter,

				
________________________________

				From: Peter Arberg [mailto:[email-masked]] 
				Sent: 29 April 2008 19:34
				To: Wojciech Dec (wdec); DE CNODDER Stefaan; Busser, M; [email-masked]
				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) 

		Value   : (Rate in Kb/sec) 

		Type (Actual-Net-Data-Rate-Downstream = 0x82) : Actual downstream net data rate on a DSL line. 

		This is a mandatory TLV. 

		Length :  (4 bytes) 

		Value  :  (Rate in Kb/sec) 

				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: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
					Sent: 29. april 2008 02:28
					To: DE CNODDER Stefaan; Busser, M; [email-masked]
					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:[email-masked]] 
					Sent: 29 April 2008 09:52
					To: Wojciech Dec (wdec); Busser, M; [email-masked]
					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:[email-masked]] 
					Sent: maandag 28 april 2008 21:33
					To: DE CNODDER Stefaan; Busser, M; [email-masked]
					Cc: Haag, T
					Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal

________________________________

					From: DE CNODDER Stefaan [mailto:[email-masked]] 
					Sent: 28 April 2008 17:15
					To: Wojciech Dec (wdec); Busser, M; [email-masked]
					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:[email-masked]] 
					Sent: maandag 28 april 2008 16:28
					To: DE CNODDER Stefaan; Busser, M; [email-masked]
					Cc: Haag, T
					Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal

					It's actually a mix of both. Inline...

________________________________

					From: [email-masked] [mailto:[email-masked]] On Behalf Of DE CNODDER Stefaan
					Sent: 28 April 2008 16:04
					To: Wojciech Dec (wdec); Busser, M; [email-masked]
					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: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
					Sent: donderdag 24 april 2008 14:19
					To: Busser, M; [email-masked]
					Cc: Haag, T
					Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal

					Hi Michael,

					inline...

________________________________

					From: [email-masked] [mailto:[email-masked]] On Behalf Of Busser, M
					Sent: 24 April 2008 13:13
					To: [email-masked]
					Cc: Haag, T
					Subject: Re: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal

					Hi Woi, all

					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. 

					Thanks,

					Woj.

					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: [email-masked]

					Internet: http://www.t-systems.com <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: [email-masked] [mailto:[email-masked]] Im Auftrag von Wojciech Dec (wdec)
					Gesendet: Mittwoch, 23. April 2008 14:54
					An: [email-masked]
					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. 

					

_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 6 May 2008 20:15:45 -0400

>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

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]]
Sent: Tuesday, May 06, 2008 12:33 PM
To: Sanjay Wadhwa; Peter Arberg; DE CNODDER Stefaan; Busser, M; [email-masked]
Cc: Haag, T
Subject: RE: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal

Sanjay,
 
Inline.... Woj#2

  _____  

Woj

 

-Woj.

 

Cheers

-Sanjay

  _____  

Hi Peter,

continued inline...

  _____  

Hi Woj,

 

  _____  

Hi Peter,

  _____  

Hi Woj,

 

Woj> Exactly. 

 

Woj> The text states:   

 

This is a mandatory TLV.  

Length  :  (4 bytes) 

Value   : (Rate in Kb/sec) 

This is a mandatory TLV. 

Length :  (4 bytes) 

Value  :  (Rate in Kb/sec) 

to make.

 

implementations. 

discussion.

Woj.

cheers,

Peter 

Cheers,

Woj.

cheers,

Peter

 

  _____  

Stefaan,

a number of points:

Port-up message (0x80);

        DSL line state = 0x8F

Thanks,

Woj.

  _____  

Hi Woj,

regards,

Stefaan

 

  _____  

 

  _____  

-Woj.

regards,

Stefaan

  _____  

  _____  

Hi,

OR

Regards,

Woj.

regards,

Stefaan

  _____  

Hi Michael,

inline...

  _____  

Hi Woi, all

Thanks,

Woj.

 

 

Michael Busser

ICT-Systems Integration

Internet:  <http://www.t-systems.com/> http://www.t-systems.com 

 

  _____  

Hi All, 

" 

  

-Woj.