Re: Specification verification tools
On Wed, 4 Oct 2001 Henning G. Schulzrinne wrote: For now, please send me pointers to tools and possible languages or other suitable means, including, for example, RFC 2234 (ABNF), ASN.1 as used for LDAP and SNMP, or XML schemas. Note that these tools are meant for verification, not for code generation. You can download the OSS ASN.1 Syntax Checker for free from: http://www.oss.com/products/syntax1.html You can download for free the book ASN.1 - Communication between heterogeneous systems from http://www.oss.com/asn1/dubuisson.html, and the book ASN.1 Complete from http://www.oss.com/asn1/larmouth.html. Hardcopies of these books can also be purchased online from the likes of http://www.barnesandnoble.com or http://www.amazon.com A full line of ASN.1 products for C, C++ and Java can be found at http://www.oss.com. - Bancroft Scott Toll Free:1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 [EMAIL PROTECTED] Tech Support :1-732-302-9669 x-1 1-732-302-9669 x-200 Fax :1-732-302-0023 http://www.oss.com
ABOUT: PPPQOS
hi everyone, is there any mechanism in the PPP issues to implement QOS? sometimes we use pppoe, l2tp to access network, why not just do all QOS in the PPP stack? is there any draft about this? thanks.
Re: about: L2 VPN over MPLS
xiaolee wrote: hi, i have some doubts about when we implement L2 VPN over MPLS we SHOULD keep loop free. See draft-lasserre-tls-mpls-00.txt. why? why not just use such a simple algorithm described below? 1. if the L2 frames are received from a interface connecting to a CE, forward the frames to all other local interfaces in the same VPN, and also to all other remote PEs which sites within the same VPN are connecting to. Of course you should only do this if the destination of the frame is broadcast, multicast or unknown... 2. if the L2 frames are received from other PE, just forward the frames to all local interfaces in the same VPN with the frame. yes - with the above proviso again. is it like the full mesh topology for the IBGP peers? kind of. iBGP is control plane. This is forwarding plane (though both draft-lasserre and the similar draft-vkompella rely on meshed LDP sessions in the control plane.) and what will happen, if protocol operations in this way? It will behave exactly as specified in the draft? The draft states: Each PE MUST support a split-horizon scheme in order to prevent loops, that is, a PE MUST NOT forward traffic from one VC LSP to another in the same VPN (since each PE has direct connectivity to all other PEs in the same VPN). Isn't that the same as your suggestion? Giles -- = Giles HeronPrincipal Network ArchitectPacketExchange Ltd. ph: +44 7880 506185 if you build it they will yawn =
Re: ABOUT: PPPQOS
the RFC2125: The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP) describes some methods to dynamic Bandwidth Allocation in Multilink PPP. But it only can add, remote a link dynamic, why not go further for the ppp it self to allocate Bandwidth dynamically in the use of just only one link, i mean negotiating how much bandwidth peer need and without any interrupt. for example, in the pppoe scenario, if we have to implement QOS between the BAS and pppoe client( note: no just bandwidth control or limit), what to do? extending the ppp or extending the pppoe? which it the best? for the ppp is so pop in the network access field, why not just extending the ppp it self? i mean, extending the ppp, let the ppp(lcp or ncp for more accurate) can be use as a signal protocol, just like rsvp, so all other protocols such as pppoe, l2tp can benefit from it. PPP delivers the packet to IP, possibly with a QoS label, and IP uses the QoS to decide how to queue and schedule the packet yes, i can not agree u more. but it is the data panel not the control panel, how a ppp end point know how much bandwidth the other ppp end point needs? traditionally, it can be predefined by administrator. why not do this just more automatically, so the peer can dynamically change QOS at any time? thanks.
Re: Last Call: Remote Network Monitoring Management InformationBase for High Capacity Networks to Proposed Standard
On Thu, 27 Sep 2001, The IESG wrote: The IESG has received a request from the Remote Network Monitoring Working Group to consider Remote Network Monitoring Management Information Base for High Capacity Networks draft-ietf-rmonmib-hcrmon-09.txt as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by October 10, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-09.txt Updated MIBS can ve obtained via http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-07-rmon.mib http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-07-rmon2.mib I wish to raise four issues with respect to the updated MIBs: one procedural, one technical, and two editorial. Up to now the usual procedure for updating a MIB module that has been published in a standards-track RFC has been to publish a new RFC containing the revised MIB module. The proposed standards action would do something different. The above-mentioned draft draft-ietf-rmonmib-hcrmon-09.txt includes a new MIB module (HC-RMON-MIB) that requires revisions to two existing MIB modules (RMON-MIB and RMON2-MIB). Rather than publish revised versions of the latter MIB modules in new RFCs, the draft contains MIB module fragments specifying the revisions and contains pointers to on-line versions of the complete revised MIB modules. In particular, it points to http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-07-rmon.mib which is a revision of the RON-MIB module published in RFC 2819, currently a Full Standard, and http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-07-rmon2.mib which is a revision of the RMON2-MIB module published in RFC 2021, currently a Proposed Standard. The intent is that when the draft is published as an RFC these updated MIB modules would be posted on-line in a repository maintained by the RFC editor and the pointers would be updated accordingly. The changes to the RMON-MIB and RMON2-MIB modules are relatively modest: as currently written, they amount to adding high-capacity enumerations to hostTopNRateBase in the RMON-MIB and to nlMatrixTopNControlRateBase and alMatrixTopNControlRateBase in the RMON2-MIB, plus some clarifications and fixes for typos in the latter. However, they do tie those MIBs to the HC-RMON-MIB in a normative way via the revised DESCRIPTION clauses. Specifically, the new enumerations for hostTopNRateBase and nlMatrixTopNControlRateBase indicate that the corresponding control table entries pertain to tables in the HC-RMON-MIB, and the new enumerations for alMatrixTopNControlRateBase indicate that the corresponding reports are sorted according to values of objects in the HC-RMON-MIB. The HC-RMON-MIB will be a Proposed Standard; thus, if the revised RMON-MIB and RMON2-MIB modules were to be published in new RFCs, those RFCs would also be Proposed Standards. According to the RMONMIB WG Status slides for IETF #48, the working group wanted only the RateBase objects to cycle at Proposed, not all the other objects. Hence the variant procedure for publishing the updates to the RMON-MIB and RMON2-MIB. While I am sympathetic with the working group's motivation, it does seem to me that updating the RMON-MIB and RMON2-MIB in this way circumvents the following requirement from Section 2.1 of RFC 2026, The Internet Standards Process Revision 3: Each distinct version of an Internet standards-related specification is published as part of the Request for Comments (RFC) document series. In the past I believe that this has been understood to mean that if a MIB module that has been published in a standards-track RFC needs to be updated, then the revised version must be published in its entirety in a new RFC. The proposed standards action would have the effect of changing that understanding. It would therefore seem to be appropriate for the Area Directors to issue a written statement to the community making explicit the policy on publication of new standards-track MIB versions. There is also a minor technical issue regarding the revised RMON-MIB and RMON2-MIB modules. In order to achieve backward compatibility the conformance statements need to contain an OBJECT clauses for hostTopNRateBase, nlMatrixTopNControlRateBase, and alMatrixTopNControlRateBase specifying that if the HC-RMON-MIB is not supported then the only required enumeration values are those that are specified in the current versions (RFC 2819 and RFC 2021) of the MIB modules. The current draft versions have no such OBJECT clauses, implying that all the enumerations (old and new) need to be supported by a conformant implementation. Lastly, two minor editorial matters might be worth noting. First, the revised DESCRIPTION clauses for hostTopNRateBase and nlMatrixTopNControlRateBase should probably mention that
RE: Last Call: Remote Network Monitoring Management InformationBase for High Capacity Networks to Proposed Standard
Could I ask, that if people want to reactto or discuss this that we do the discussion on one mailing list? I suspect many of us are on all 3 lists Probably the rmonmib mailing list is the best place. Bert -Original Message- From: C. M. Heard [mailto:[EMAIL PROTECTED]] Sent: Friday, October 05, 2001 10:32 PM To: IETF Discussion List Cc: RMONMIB Mailing List; MIBS Mailing List Subject: Re: Last Call: Remote Network Monitoring Management Information Base for High Capacity Networks to Proposed Standard On Thu, 27 Sep 2001, The IESG wrote: The IESG has received a request from the Remote Network Monitoring Working Group to consider Remote Network Monitoring Management Information Base for High Capacity Networks draft-ietf-rmonmib-hcrmon-09.txt as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by October 10, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-09.txt Updated MIBS can ve obtained via http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon- 07-rmon.mib http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon- 07-rmon2.mib I wish to raise four issues with respect to the updated MIBs: one procedural, one technical, and two editorial. Up to now the usual procedure for updating a MIB module that has been published in a standards-track RFC has been to publish a new RFC containing the revised MIB module. The proposed standards action would do something different. The above-mentioned draft draft-ietf-rmonmib-hcrmon-09.txt includes a new MIB module (HC-RMON-MIB) that requires revisions to two existing MIB modules (RMON-MIB and RMON2-MIB). Rather than publish revised versions of the latter MIB modules in new RFCs, the draft contains MIB module fragments specifying the revisions and contains pointers to on-line versions of the complete revised MIB modules. In particular, it points to http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon- 07-rmon.mib which is a revision of the RON-MIB module published in RFC 2819, currently a Full Standard, and http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon- 07-rmon2.mib which is a revision of the RMON2-MIB module published in RFC 2021, currently a Proposed Standard. The intent is that when the draft is published as an RFC these updated MIB modules would be posted on-line in a repository maintained by the RFC editor and the pointers would be updated accordingly. The changes to the RMON-MIB and RMON2-MIB modules are relatively modest: as currently written, they amount to adding high-capacity enumerations to hostTopNRateBase in the RMON-MIB and to nlMatrixTopNControlRateBase and alMatrixTopNControlRateBase in the RMON2-MIB, plus some clarifications and fixes for typos in the latter. However, they do tie those MIBs to the HC-RMON-MIB in a normative way via the revised DESCRIPTION clauses. Specifically, the new enumerations for hostTopNRateBase and nlMatrixTopNControlRateBase indicate that the corresponding control table entries pertain to tables in the HC-RMON-MIB, and the new enumerations for alMatrixTopNControlRateBase indicate that the corresponding reports are sorted according to values of objects in the HC-RMON-MIB. The HC-RMON-MIB will be a Proposed Standard; thus, if the revised RMON-MIB and RMON2-MIB modules were to be published in new RFCs, those RFCs would also be Proposed Standards. According to the RMONMIB WG Status slides for IETF #48, the working group wanted only the RateBase objects to cycle at Proposed, not all the other objects. Hence the variant procedure for publishing the updates to the RMON-MIB and RMON2-MIB. While I am sympathetic with the working group's motivation, it does seem to me that updating the RMON-MIB and RMON2-MIB in this way circumvents the following requirement from Section 2.1 of RFC 2026, The Internet Standards Process Revision 3: Each distinct version of an Internet standards-related specification is published as part of the Request for Comments (RFC) document series. In the past I believe that this has been understood to mean that if a MIB module that has been published in a standards-track RFC needs to be updated, then the revised version must be published in its entirety in a new RFC. The proposed standards action would have the effect of changing that understanding. It would therefore seem to be appropriate for the Area Directors to issue a written statement to the community making explicit the policy on publication of new standards-track MIB versions. There is also a minor technical issue regarding the revised RMON-MIB and RMON2-MIB modules. In order to achieve backward compatibility the conformance statements need to contain
Re: Specification verification tools
http://www.ops.ietf.org/abnf/ At 04:33 PM 10/3/2001, Henning G. Schulzrinne wrote: Recently, the IESG sent a note describing and encouraging the use of formally verifiable means of protocol specification, in addition to English prose. To facilitate this effort, I will be setting a resource web page to provide information on mechanisms and tools. (Unless there is a formal IETF effort, of course.) For now, please send me pointers to tools and possible languages or other suitable means, including, for example, RFC 2234 (ABNF), ASN.1 as used for LDAP and SNMP, or XML schemas. Note that these tools are meant for verification, not for code generation. This is a freelance effort, and any statements or listings do not necessarily reflect official IETF or IESG policy or recommendations. Thank you. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- Jiri Kuthanhttp://iptel.org/~jiri
