From ancp-bounces@ietf.org Mon Jun 2 12:54:21 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540CF3A6A08; Mon, 2 Jun 2008 12:54:21 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF95628C17B for ; Mon, 2 Jun 2008 12:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZbDtpFJqGVZ for ; Mon, 2 Jun 2008 12:54:18 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id D61B428C17D for ; Mon, 2 Jun 2008 12:46:44 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m52Jkg2q004195; Mon, 2 Jun 2008 21:46:42 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 2 Jun 2008 21:46:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Jun 2008 21:46:40 +0200 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E01D618C9@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP message length field Thread-Index: AcikfcgluibF+DjWTfupYAEgs2PQXQAFCpLwB0Ul7CAA0KLkQA== References: From: "DE CNODDER Stefaan" To: "Wojciech Dec (wdec)" , X-OriginalArrivalTime: 02 Jun 2008 19:46:42.0707 (UTC) FILETIME=[61C95E30:01C8C4E9] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [ANCP] ANCP message length field X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0936203775==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0936203775== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C4E9.612CA5BB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C4E9.612CA5BB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 As long it is backwards compatible, it is fine for me. This means you cannot make one of the fields "Reserved". How is the re-definition in proposal 2a of the sub-message field and length field different from its current definition? I do not see much difference. =20 regards, Stefaan =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: vrijdag 30 mei 2008 9:07 To: ancp@ietf.org Subject: Re: [ANCP] ANCP message length field Hi Folks, =20 any comments, or preferences regarding the proposals? Since one of the two identical Length fields is redundant, we have some options on dealing with them...=20 =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: 22 April 2008 18:09 To: ancp@ietf.org Subject: Re: [ANCP] ANCP message length field =09 =09 Adding one note regarding the options for carrying PDUs exceeding 64kb. Using other GSMP derived notions in proposal options 2a and 2b it would be possible to set a "result" field flag to indicate the continuation of a fregmented PDU, with the transaction identifier allowing the possibility to stitch back together such a message. An implementation would however have to pay close attention to this flag, and the fact that overall legth of the message would be the sum of two (or more) length fields. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: 22 April 2008 15:36 To: ancp@ietf.org Subject: [ANCP] ANCP message length field =09 =09 Hi Folks,=20 As part of our GSMP legacy we've inherited some base protocol header fields that, for lack of a better word, are largely useless for ANCP. An example of such a field are the dual message Length field deriving from rfc3292 and rfc3293, both of which in ANCP carry the same value (it's not at all clear why rfc3293 needed such a field, but that's a different story). This is shown in more detail below in the form of an ANCP header: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type (0x88-0C) | Length |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Vers | Sub |MessageType | Result| Code |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Partition ID | Transaction Identifier |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |I| SubMessage Number | Length |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 RFC 3293 defines the first "Length" field to be: This 2-byte unsigned integer indicates the total length of the=20 GSMP message only. It does not include the 4-byte TLV header.=20 RFC 3292 defines the second "Length" field to be: Length of the GSMP message including its header fields and=20 defined GSMP message body. The length of additional data=20 appended to the end of the standard message SHOULD be included=20 in the Length field.=20 It's thus quite clear that the two fields, in ANCP's case, carry the same value and it appears reasonable to think of possible changes:. Proposal 1.=20 The "additional data" possibility is to be dropped. There appears to be no reason to transmit non ANCP data in ANCP.=20 Proposal 2 - Option a.=20 Re-define the Sub-message Number and Length fields to convey really a Sub-message Number and Sub-Message Length, and allow multiple commands to be bundled under the same transaction header, which appears interesting in the perspective of multicast control, and line configuration use-cases. Backwards compatibility with existing implementations could be maintained since currently all ANCP's applications set the I flag to "0". Implementations supporting this change, would most likely be required to send the so-far commonly implemented Port-up/down and OAM "legacy" messages with the I flag set to "1". Proposal 2 Option b.=20 Instead of using the Sub-message number and 2nd Length fields, we define these to be reserved fields of no use in ANCP.=20 Proposal 2 Option c.=20 Define the 1st Length field to be reserved fields of no use in ANCP, using instead only the Sub Message and Length fields to stitch together ANCP messages that go over 64kb boundary. Proposal 2 Option d=20 Continue using both fields as today, but refine the Sub-message and Length field to allow for messages over 64kb.=20 I solicit the WG's feedback regarding these proposed changes.=20 Regards,=20 Woj.=20 ------_=_NextPart_001_01C8C4E9.612CA5BB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ANCP message length field
 
As long it is backwards compatible, it is fine = for=20 me.  This means you cannot make one of the fields "Reserved".  = How is=20 the re-definition in proposal 2a of the sub-message field and length = field=20 different from its current definition?  I do not see much=20 difference.
 
regards,
Stefaan
 

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: vrijdag 30 mei 2008 9:07
To:=20 ancp@ietf.org
Subject: Re: [ANCP] ANCP message length=20 field

Hi Folks,
 
any comments, or preferences regarding the proposals? Since one = of the=20 two identical Length fields is redundant, we have some options on = dealing=20 with them...
 
-Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: 22 April 2008 18:09
To:=20 ancp@ietf.org
Subject: Re: [ANCP] ANCP message length=20 field

Adding one note regarding the options for carrying PDUs = exceeding=20 64kb. Using other GSMP derived notions in proposal options 2a and = 2b it=20 would be possible to set a "result" field flag to indicate the=20 continuation of a fregmented PDU, with the transaction identifier = allowing the=20 possibility to stitch back together such a message. An implementation = would=20 however have to pay close attention to this flag, and the fact that = overall=20 legth of the message would be the sum of two (or more) length=20 fields.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: 22 April 2008 15:36
To:=20 ancp@ietf.org
Subject: [ANCP] ANCP message length=20 field

Hi = Folks,

As part of our = GSMP legacy we've=20 inherited some base protocol header fields that, for lack of a = better word,=20 are largely useless for ANCP. An example of such a field are the = dual=20 message Length field deriving from rfc3292 and rfc3293, both of = which in=20 ANCP carry the same value (it's not at all clear why rfc3293 needed = such a=20 field, but that's a different story). This is shown in more detail = below in=20 the form of an ANCP header:


      0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8=20 9 0 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /SPAN>=20
     = |       =20 Type (0x88-0C)        =20 |          =20 = Length           &= nbsp; =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
     | Vers  |  Sub =20 |MessageType    |=20 Result|       =20 Code           |=20
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
     | Partition ID =20 |           =20 Transaction=20 = Identifier          &nb= sp; =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
     |I|      = SubMessage=20 Number     =20 |          =20 = Length           &= nbsp; =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

RFC 3293 defines = the first=20 "Length" field to be:       This = 2-byte=20 unsigned integer indicates the total length of the =
     =20 GSMP message only.  It does not include the 4-byte TLV=20 header.


RFC 3292 defines = the second=20 "Length" field to be: Length of the GSMP message including its = header fields=20 and
         defined = GSMP message=20 body.  The length of additional data
         appended = to the end=20 of the standard message SHOULD be included
         in the = Length=20 field.

It's thus quite = clear that the=20 two fields, in ANCP's case, carry the same value and it appears = reasonable=20 to think of possible changes:.

Proposal 1.=20
The = "additional=20 data" possibility is to be dropped. There appears to be no reason to = transmit non ANCP data in ANCP.

Proposal 2 - = Option=20 a.
Re-define the=20 Sub-message Number and Length fields to convey really a Sub-message = Number=20 and Sub-Message Length, and allow multiple commands to be bundled = under the=20 same transaction header, which appears interesting in the = perspective of=20 multicast control, and line configuration use-cases. Backwards = compatibility=20 with existing implementations could be maintained since currently = all ANCP's=20 applications set the I flag to "0". Implementations supporting this = change,=20 would most likely be required to send the so-far commonly = implemented=20 Port-up/down and OAM "legacy" messages with the I flag set to=20 "1".

Proposal 2 Option=20 b.
Instead of=20 using the Sub-message number and 2nd Length fields, we define these = to be=20 reserved fields of no use in ANCP.

Proposal 2 Option=20 c.
Define the 1st=20 Length field to be reserved fields of no use in ANCP, using instead = only the=20 Sub Message and Length fields to stitch together ANCP messages that = go over=20 64kb boundary.

Proposal 2 Option=20 d
Continue using=20 both fields as today, but refine the Sub-message and Length field to = allow=20 for messages over 64kb.

I solicit the WG's = feedback=20 regarding these proposed changes.

Regards,
Woj.=20

------_=_NextPart_001_01C8C4E9.612CA5BB-- --===============0936203775== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0936203775==-- From ancp-bounces@ietf.org Wed Jun 4 04:25:34 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306B228C0EF; Wed, 4 Jun 2008 04:25:34 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DC028C0F7 for ; Wed, 4 Jun 2008 04:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZpZ2c0Brt2Z for ; Wed, 4 Jun 2008 04:25:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E200328C104 for ; Wed, 4 Jun 2008 04:24:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,589,1204498800"; d="scan'208";a="10739053" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Jun 2008 13:24:36 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m54BOafo028273; Wed, 4 Jun 2008 13:24:36 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m54BOapo019909; Wed, 4 Jun 2008 11:24:36 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 13:23:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 13:23:48 +0200 Message-ID: In-Reply-To: <48C276B536524E478C659685995F6AA560439CC824@RBSJX.ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] question regarding Labels in ANCP port up messages Thread-Index: Aciqkn5nSPBPuwuySsamcvxF1uU6kQAZ9dQQAAE415AABe3TAABN80lQAA1w7OAAutMtAAAtn1MQAE7htiAFNNXYUA== References: <48C276B536524E478C659685995F6AA539DBBBE370@RBSJX.ad.redback.com><9BD5D7887235424FA97DFC223CAE3C280AB43A10@proton.jnpr.net><48C276B536524E478C659685995F6AA539DBBBE577@RBSJX.ad.redback.com><9BD5D7887235424FA97DFC223CAE3C28102EB5AA@proton.jnpr.net> <48C276B536524E478C659685995F6AA539DBBBEF99@RBSJX.ad.redback.com> <48C276B536524E478C659685995F6AA560439CC824@RBSJX.ad.redback.com> From: "Wojciech Dec (wdec)" To: "Peter Arberg" , "Ole Helleberg Andersen" , "Sanjay Wadhwa" , "Tina TSOU" , "Maglione Roberta" X-OriginalArrivalTime: 04 Jun 2008 11:23:51.0972 (UTC) FILETIME=[77740E40:01C8C635] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=67059; t=1212578676; x=1213442676; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20question=20regarding=20=20Labe ls=20in=20ANCP=20port=20up=20messages |Sender:=20; bh=HnDANqE1rN1F/R5rlbo/2rmJH2Ww42MwiXmS/+U5ZRo=; b=WUtG1rgEvcVPM93IKRvTMXDii8K+A4he/yC+YOWNlcwY/1ANWyitzUYhVF KaFq/BdshqGcJzviGfw7pr/Kx5DT08cjjoGkRd5+tw/ftD3c0CSTIwMs6xE1 InuYIQb6Wy; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] question regarding Labels in ANCP port up messages X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi All, Unless there are some last minute counter proposals, or comments, Peter's proposal below regarding the Label field should be considered as accepted by the WG. Regards, Woj. > -----Original Message----- > From: Peter Arberg [mailto:parberg@redback.com] > Sent: 09 May 2008 02:15 > To: Wojciech Dec (wdec); Ole Helleberg Andersen; Sanjay > Wadhwa; Tina TSOU; Maglione Roberta > Cc: ancp@ietf.org > Subject: RE: [ANCP] question regarding Labels in ANCP port up messages > > Hi Woj, > > I think your proposal goes hand in hand with my suggestion to > document the > event message bit by bit instead of reference the RFC3292 or > an expired old > gsmp-draft. > > I will suggest we in the ANCP draft do a description in section > 5.4.2 something in these lines: > > The ANCP Event message with PORT UP message type (80) is used for > conveying DSL line attributes to the NAS, and is defined as follows: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers | Sub | Message Type | Result| Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Port Session Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Event Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|S|x|x| | > +-+-+-+-+ Label | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Extension Value ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Version field is 1 byte, 4 bits for the major version and 4 > bits for the sub-version, should be set to 3, and the sub field > should be set to 1. > > Message Type is 1 byte, and can have the following values: > ... > > Result ... > > Code ... > > Partition ID ... > > .... > > > Label field is 8 bytes, should be set to 0 on transmit and > ignored on receive. > > .... > > So the idea is to document every single field in the event message, > and list what is the expected transmit value, and what should the > receiver do with the field. > > > I will actually suggest we remove the "label" name and just call the > unused field "reserved" and must be set to 0 on transmit and > ignored on > receive. > > If we simply call them "reserved" we always have the option > to reuse them > in alater contribution / new version if theer ever should be a need to > use some bits in the event message header. > > > Also as another comment, I still think it will be beneficial if we > describe that the version number check should be per adjacency, so > we in the future can do a version change easy and allow the ANCP > implementation to have multiple adjacency with different > versions of the > protocol, if we ever see a reason to increase the version number it > will give a much easier upgrade scenario. > > cheers, > Peter > > > cheers, > Peter > > > > > ________________________________ > > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: 7. maj 2008 14:14 > To: Ole Helleberg Andersen; Peter Arberg; Sanjay > Wadhwa; Tina TSOU; Maglione Roberta > Cc: ancp@ietf.org > Subject: RE: [ANCP] question regarding Labels in ANCP > port up messages > > > Hi All, > > it's with a certain amount of incredulity that I view > the proposals on this thread for changing the version number > of the protocol. Were such proposals to be accepted, by > definition it would make most likely the ANCP draft > incompatible with *all* current implementations, or at the > very least introduce a compatibility mess in existing > deployments short of a flag day change over, not to mention > the issue of depreciating the old version. > There really seems to be no reason to go through with > a version change due to what may be attributed as a day 1 > draft problem but *not* a day 1 implementation problem. Also, > it is not the first time that the protocol spec draft has had > some inaccuracies, and we've visited this aspect previously > resulting in the following versioning strategy being laid > out: > http://www.ietf.org/mail-archive/web/ancp/current/msg00152.htm l . While the strategy states that an ANCP version change will > not be considered due to "incompatibilities arising from > implementations of pre-RFC drafts", neither does it state > that the draft cannot change to reflect current > implementations while keeping the version. > > Now, given that there seems to be some uneasiness > (but thankfully not absolute) in the WG to come forward > publicly with details of what is currently implemented, I > have conducted a behind the scenes investigation of sorts, > and present the summarized findings below: > - There are 10 distinct implementations of ANCP > - Out of these 9 either directly implement the label > field format in as per section 5.3 of > draft-gsmpv3-base-spec-08, or each is known to be compatible > with at least 2 implementations that do so. By association, > it seems reasonable to claim that all of these ANCP > implementations use the draft-gsmpv3-base-spec-08 format. > Also, all use version 3.1 as the protocol version, and the > base protocol header also as per draft-gsmpv3-base-spec-08 > - One implementation is known to use the > draft-ietf-ancp-protocol-02 format of the label field format, > ie the rfc3292 format. This implementation is not known to be > compatible with any of the others. > > Based on this, but not only, the obvious answer to > the problem is *not* to do a version change, but rather fix > the draft. Granted, this is a far from ideal situation for > the one implementation affected, and it's a true shame that > the problem wasn't spotted earlier. Like Peter I also wonder > how any interop was achieved, but the fact that it is there > is a significant one that should not be undone by hasty > version changes. As such option 2 below is not one we'll be > taking forward. Option 1 however also comes short as it does > not quite follow the logic of simply documenting what is > known to be interoperable in the WG draft. If specific > implementations choose to realize knobs or other, fine, but > this is not part of the protocol spec, and there is no such > thing as "old label format". Please do consider the third > option, ie fixing the draft to reflect what is already done. > > This fact in general highlights the problems we're > having in carrying with the GSMPv3 (rfc3292) legacy, > alongside adopted amendments from draft-gsmpv3-base-spec > (this Label issue not being the only adopted item), alongside > new protocol work. I trust that all of you agree that getting > maximum clarity on all the legacy issues and dependencies in > the protocol spec is in the WG's best interest, and that we > are still some way off from that. As such I also expect the > WG to support moves/proposals aimed at getting that clarity, > with resolving this issue being not the first and not the > last such move. > > Regards, > Woj. > > > > > > ________________________________ > > From: Ole Helleberg Andersen > [mailto:ole.helleberg.andersen@ericsson.com] > Sent: 06 May 2008 14:04 > To: Peter Arberg; Sanjay Wadhwa; Tina TSOU; > Maglione Roberta; Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: RE: [ANCP] question regarding Labels > in ANCP port up messages > > > Hi All, > > I think the main issue is to > ensure interoperability with existing implementations, and to > allow for upgrading nodes that are already in service to a > WG-draft compliant version. To do that in a manageable way we > must allow for version negotiation per adjacency. We > therefore need to change the WG-draft as suggested by Sanjay > in his option 2. > > Concerning the encoding issue I prefer to > make the WG-draft in line with existing implementations. > However, if the WG decides to change it, differences in this > encoding would also be solved by choosing Sanjay's option 2. > > Cheers, > Ole > > ________________________________ > > From: ancp-bounces@ietf.org > [mailto:ancp-bounces@ietf.org] On Behalf Of Peter Arberg > Sent: 2. maj 2008 20:52 > To: Sanjay Wadhwa; Tina TSOU; Maglione > Roberta; Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] question regarding Labels > in ANCP port up messages > > > Hi Sanjay, > > yes apparently I missed your point in the > last email, but I'm glad we agree something is needed > to make existing ANCP implementations and the > current draft to co-exist. > > I do not like your option 1) as if you need a > config knob for interoperability, it is too easy to > get into trouble. > > I think option 2) is the best way forward > with the differences already identified, or we can > continue to get a show of hands of ANCP > implementations, and see if anyone is actually > deployed based on the WG-draft. > > There is no beneficial reasons to base the > event-message of RFC3292, it could as well be a message > described bit by bit in the ANCP draft, and > then we can keep the label space at 8 as many > implementations alreday do. > > cheers, > Peter > > > > > > ________________________________ > > From: Sanjay Wadhwa > [mailto:swadhwa@juniper.net] > Sent: 2. maj 2008 05:35 > To: Peter Arberg; Tina TSOU; Maglione > Roberta; Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: RE: [ANCP] question > regarding Labels in ANCP port up messages > > > > Peter > > You missed my point below. The ANCP > draft since becoming a WG draft does NOT refer to the old > GSMP drafts. Any implementations based on this WG-draft are > expected to be interoperable. You are pointing to > pre-WG-draft versions of ANCP, and these were indeed based on > expired GSMP drafts that evolved past RFC3292. > > There is incompatibility between the > current ANCP WG-draft and previous non-WG versions (TLV > clash, label format..). As mentioned earlier it is prudent > for older implementations to start supporting the WG-draft > version as soon as possible. > > > > For interoperability of WG-draft with > the older pre-WG versions, I see the following options: > > > > 1. Versioning starts with the > WG-draft i.e. WG-draft is version = 3, sub-version = 1. For > any interop issues between older non-WG versions and the > WG-draft, one needs to look at solving it within > implementations (e.g. an AN that implements the WG-draft, > could based on a configuration knob, generate a PORT-UP > message with old label format the will be accepted by BNG > implementing pre-WG versions of the draft). > > > > 2. Change the WG-draft (current > draft) to use version = 3 and sub-version = 2. This is > assuming there is no deployed implementation of current > WG-draft that already uses 3.1 as the version, and also > assuming the old pre-WG implementations use 3.1. There will > be no backwards compatibility i.e. version 3.1 BNG will not > work with version 3.2 AN (we will need to list this as caveat > in the appendix section). AN and BNG will need to negotiate > the same version in order for ANCP adjacency to come up. A > BNG supporting both versions 3.1 and 3.2 could simultaneously > become adjacent with one AN supporting 3.1 and another AN > supporting 3.2. (i.e. version compatibility is per adjacency). > > Also, major version number change > (e.g. from 3 to 4) should only correspond to a major change > in the protocol (e.g. different mechanism, different transport etc). > > > > My vote would be to adopt option 2 > above only if further changes to WG-draft happen that render > it incompatible with the current WG-draft. Any > interoperability issues with pre-WG versions could be handled > via option 1. > > > > Cheers > > -Sanjay > > > > ________________________________ > > From: Peter > Arberg [mailto:parberg@redback.com] > Sent: Wednesday, April 30, 2008 7:20 PM > To: Sanjay Wadhwa; Tina TSOU; > Maglione Roberta; Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: RE: [ANCP] question > regarding Labels in ANCP port up messages > > > > Sanjay, > > > > What do you mean "why I reference an > old draft" ???????????? > > > > I'm surprised you even ask... please > take a look at YOUR own internet-draft that most > > of the ANCP working implementations > are based on, in case you do not have this old > > internet-draft, I have attached it to > the document. > > > > If you look at the reference for this > ancp-draft, you will see that in the reference section > > you point to this old gsmp-draft... > Yes and I know this has been changed in the later > > versions of the ANCP draft, but that > do not change the fact that many of the implementations > > today was developed when the attached > draft was current. > > > > I think a very good question is > brought up here, and that is what is implemented and > > running in networks today ? > > > > My take on this is that when the > reference was change from the old gsmp-draft to the older > > RFC3292, apparently no one paid any > attention to the fact the label definition in the event > > message was different and not compatible. > > > > What current implementations do today > is an important factor in this discussion, and I think > > it is time to come to realization > that we might need a new version number for ANCP since > > it continues to look like there is > big holes open for interpretation. So if I did a ANCP > > implementation there is bound to be > interoperability issues with existing implementations > > runnig. > > > > cheers, > > Peter > > > > > > > > > > ________________________________ > > > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > Sent: 30. april 2008 14:42 > To: Peter Arberg; Tina TSOU; > Maglione Roberta; Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: RE: [ANCP] question > regarding Labels in ANCP port up messages > > Peter > The ANCP draft as it > currently stands is based on RFC3292. It provides extensions > and modifications to relevant constructs in RFC3292. There is > no mention (implicit or explicit) of expired GSMP drafts in > the ANCP draft. In order to implement the ANCP draft, I am > not sure why one would look at the expired GSMP drafts. Do > you see a reason to do this based on anything that you read > in the ANCP draft? Bringing up reference to expired gsmp > draft in this thread just adds to the confusion. For GSMPv3 > objects in the messages (such as Label Type), one has to look > at RFC3292 (this is clearly stated in the ANCP draft - > section 2 and I am quoting it below) : > > ANCP uses a subset of GSMPv3 > messages to implement currently defined use-cases. These > relevant GSMPv3 messages are identified in section 5. GSMPv3 > procedures with suitable extensions, as used by ANCP, are > described in sections 5.1, 5.2 and 5.3. GSMPv3 general > extensions and GSMPv3 message specific extensions required by > ANCP are described in sub-sections of 5.4. In addition to > specifying extensions and modifications to relevant GSMP > messages applicable to ANCP, this draft also defines the > usage of these messages by ANCP, and indicates the values > that ANCP should set for relevant fields in these GSMP > messages. However, to understand the basic semantics of > various fields in GSMP messages, the reader is referred to > [4]. => RFC 3292. > > What existing implementations > currently do is an important but separate issue. These > implementations for most part precede the current ANCP draft. > It is fine to poll where these implementations diverge from > the current draft. It is then upto the implementations > (including the one that I am somewhat familiar with) to work > towards compliance with the draft. > > On the following points from Woj: > > Woj>2) The current version of > the spec is not accurate, and does not reflect the fact that > the known implementations follow the label field definition > from draft-gsmpv3-base-spec. > > It is not for the protocol > draft to point out what current implementations do. The best > we can do is to further clarify in the draft that type and > value fields of the Label object (defined in RFC3292) should > be set to 0 in the port-up message (we already mention the > lable object as a whole should be set to all 0s). > > 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. > > I agree. We are based on > GSMPv3 (RFC3292) messages, and obviously not everything in > these messages is leveraged by ANCP. However, the sync rate > and OAM uses-cases are implemented and in use (ideally we > should leave these alone...i.e. no change beyond adding more > clarity if needed). For anything new (such as multicast) we > are defining new messages (no legacy). > > -Sanjay > > >-----Original Message----- > >From: Peter Arberg > [mailto:parberg@redback.com ] > >Sent: Wednesday, April 30, > 2008 3:56 PM > >To: Tina TSOU; Maglione > Roberta; Sanjay Wadhwa; Wojciech Dec (wdec) > >Cc: ancp@ietf.org > >Subject: RE: [ANCP] question > regarding Labels in ANCP port up messages > > > > > >Hi, > > > >some times I think it is > amazing we ever got interoperability > >of ANCP :-) > >because looking at the label > discussion is a very good example that the > >whole GSMP - ANCP reference > have not worked very well. > > > >In the ANCP draft, section > 5.4.2 the event message is shown like this: > > > >0 1 > 2 3 > >0 1 2 3 4 5 6 7 8 9 0 1 2 3 > 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| Vers | Sub | Message > Type | Result| Code | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| Partition ID | > Transaction Identifier | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >|I| SubMessage Number > | Length | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| > Port | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| Port > Session Number | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| Event > Sequence Number | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >|x|S|x|x| > | > >+-+-+-+-+ > Label | > >~ > ~ > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >|x|x|x|x|x|x|x|x| Message > Type | Tech Type | Block Length | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| > | > >~ > Extension Value ~ > >| > | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >This is the exact same event > message defined in > > >draft-ietf-gsmp-v3-base-spec-08.txt section 11. > > > >And in this gsmp-draft, > section 5.1.3 the label space is defined > >as minimum 8 bytes if the > length=0 and as such no value, and this > >is because the gsmp-draft > has a new "label adaptaion" field. > > > > > > > >BUT in RFC3292 the event > message is show in section 9, like this: > > > >0 1 > 2 3 > >0 1 2 3 4 5 6 7 8 9 0 1 2 3 > 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| Version | Message > Type | Result | Code | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| Partition ID | > Transaction Identifier | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >|I| SubMessage Number > | Length | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| > Port | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| Port > Session Number | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| Event > Sequence Number | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >|x|S|x|x| > | > >+-+-+-+-+ > Label | > >~ > ~ > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >So a different Event Message > picture/definition than what is shown > >in the ANCP draft, and in > RFC3292 section 3.1.3 the label field > >is defined as 4 bytes if > length=0 and as such no value. > > > > > > > >So I very much agree with > Woj that we need this issue to be resolved, > >and proabably a show of > hands what is actually done in different > >implementations, so we can > nail down how the event message is > >suppose to look like in ANCP. > > > > > >I know at least 1 > implementation which uses 8 bytes for the > >label field. > > > > > >cheers, > >Peter > > > > > > > > > > > > > >________________________________ > > > > From: ancp-bounces@ietf.org > > >[mailto:ancp-bounces@ietf.org > ] On Behalf Of Tina TSOU > > Sent: 30. april 2008 00:19 > > To: Maglione > Roberta; Sanjay Wadhwa; Wojciech Dec (wdec) > > Cc: ancp@ietf.org > > Subject: Re: [ANCP] > question regarding Labels in ANCP > >port up messages > > > > > > Hi all, > > It is clear to me > that if Label Length is filled as 0, > >there is nothing to be > filled into Label Value. The whole > >Label part is 4 bytes, not 8 bytes. > > > > Cheers from the last > working day before Labor's Day > >holidays in some countries:) > > > > Tina > > > > ----- > Original Message ----- > > From: > Wojciech Dec (wdec) > > > To: Sanjay > Wadhwa > > > ; Maglione Roberta > > > > Cc: ancp@ietf.org > > Sent: > Wednesday, April 30, 2008 1:12 AM > > Subject: Re: > [ANCP] question regarding Labels > >in ANCP port up messages > > > > Sanjay, All, > > > > What is > stated below runs counter to at least > >a handful of ANCP > > > implementations, all of which are known to be > >interoperable. > > There are > really two options: > > 1) The > current version of the spec is correct, > >and the known > > > interoperable implementations do not follow it > > 2) The > current version of the spec is not > >accurate, and does not reflect > > the fact > that the known implementations follow > >the label field > > definition > from draft-gsmpv3-base-spec. > > > > I would like > to ask you, as the lead editor of > >the spec, to work with > > the WG in > resolving what the problem is, and > >clearing up what the WG > > spec says > about and if 1) holds to be true, > >then proposing an > > interoperability fix. > > > > In either > case, the issue highlights the fact > >that there is still > > lingering > confusion as to the dependencies > >ANCP has on rfc3292, or > > > draft-gsmpv3-base-spec, or both. It seems to > >be in the best interest of > > all to address these. > > > > Regards, > > Woj. > > > > > > -----Original Message----- > > > From: > Sanjay Wadhwa [mailto:swadhwa@juniper.net > ] > > > Sent: 29 > April 2008 17:29 > > > To: > Maglione Roberta > > > Cc: > Wojciech Dec (wdec); ancp@ietf.org; > >Philippe Champagne (pchamp) > > > Subject: > RE: question regarding Labels in > >ANCP port up messages > > > > > > Hi Maglione > > > Yes, the > label format is as defined in RFC > >3292. The ANCP draft is > > > based on > RFC 3292 and proposes > >extensions/modifications where > > > required. > > > This is > clearly stated upfront both in the > >abstract and in > > > section 2. In > > > section > 5.4.2, it clearly specifies the > >format of "port up" message > > > (based on > RFC 3292), and explicitly states > >the label field > > > should be set > > > to 0. > Following is what the draft currently states: > > > > > > > > > 5.4.2 > Topology Discovery Extensions > > > > > > The GSMP > Event message with PORT UP message > >type (80) is used for > > > conveying > DSL line attributes to the NAS. > >The version field should be > > > set to 3, > and the sub field should be set to > >1. The I and subMessage > > > fields > SHOULD be set to 1 to signify no > >fragmentation. The Port and > > > Label > fields should be set to 0. > > > > > > 0 > 1 2 > > 3 > > > 0 > 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > >8 9 0 1 2 3 4 5 > > > 6 7 8 9 0 1 > > > > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > Vers | Sub | Message Type | > >Result| Code > > > | > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > Partition ID | > >Transaction Identifier > > > | > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > |I| SubMessage Number | > > Length > > > | > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > Port > > > | > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > Port Session Number > > > | > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > Event Sequence Number > > > | > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |x|S|x|x| > > > | > > > > +-+-+-+-+ Label > > > | > > > ~ > > > ~ > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > |x|x|x|x|x|x|x|x| Message Type | > >Tech Type | Block Length > > > | > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > > > | > > > ~ > Extension Value > > > ~ > > > | > > > | > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > When we > say the label field should be set to > >0, the intention > > > is for the > > > type and > length fields in the label TLV to > >be set to 0. We can > > > explicitly > state this for clarity. > > > > > > -Sanjay > > > > > > > >-----Original Message----- > > > >From: > Maglione Roberta > > >[mailto:roberta.maglione@telecomitalia.it > ] > > > >Sent: > Tuesday, April 29, 2008 8:06 AM > > > >To: Sanjay Wadhwa > > > >Cc: > Wojciech Dec (wdec); ancp@ietf.org; > >pchamp@cisco.com > > > >Subject: > RE: question regarding Labels in > >ANCP port up messages > > > > > > > > > > > >Hi Sanjay and All, > > > > I > was reading the current ancp > >protocol draft in order to > > > > > understand which should be the correct > >format for the label > > > >field in > the ancp port Up message. > > > >Actually > as it was already pointed out in > >the alias the draft > > > >in > section 5.4.2 says "GSMP Event message > >with PORT UP message > > > >type (80) > is used" thus I am assuming that > >the label in the > > > >port UP > message should follow the message > >format defined in > > > >RFC 3292, > section 3.1.3: > > > > > > > > 0 > 1 > >2 3 > > > > 0 1 2 > 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > >0 1 2 3 4 5 6 7 8 9 0 1 > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > |x|S|x|x| Label Type | > > Label Length | > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | > > | > > > > ~ > Label Value > > ~ > > > > | > > | > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > >but from > what I have seen different > >implementations use > > > >different > format for label field: in > >particular several > > > > >implementations use a label format that is > >similar to the one > > > >specified > in the expired draft > >draft-ietf-gsmp-v3-base-spec: > > > > > > > > 0 > 1 > > 2 3 > > > > 0 > 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > >8 9 0 1 2 3 4 5 6 > > > 7 8 9 0 1 > > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x| > > Label > > > Type | > > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | > Label Adaptation | > > Label > > > Length | > > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | > > > | > > > > ~ > Label Value > > > ~ > > > > | > > > | > > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > >Even if > ancp does not care about the label > >field, having this > > > >field > somehow not clearly specified in the > >current ancp draft > > > >can > easily lead to interoperability issues, > >thus I think it > > > >would be > very helpful if you and/or the > >other editors can > > > >clarify > what should be the correct format > >for the label field > > > >to be > used in the ancp Port Up message. > > > > > > > >Thanks > and best regards, > > > >Roberta > > > > > > > > >________________________________________ > > > >From: > Philippe Champagne (pchamp) [pchamp@cisco.com] > > > >Sent: > Thursday, April 24, 2008 7:14 PM > > > >To: Sanjay Wadhwa > > > >Cc: > Maglione Roberta; Wojciech Dec (wdec); > >ancp@ietf.org > > > >Subject: > question regarding Labels in ANCP > >port up messages > > > > > > > >Hi Sanjay > > > > > > > >In > section 5.4.2 of the draft, we have: > > > > > > > > > > > > > 0 1 2 > > > 3 > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >7 8 9 0 1 2 3 4 5 6 > > > >7 8 9 0 1 > > > > > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | > Vers | Sub | Message Type | > >Result| Code > > > > | > > > > > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | > Partition ID | > >Transaction Identifier > > > > | > > > > > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > |I| SubMessage Number | > > Length > > > > | > > > > > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | > Port > > > > | > > > > > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | > Port Session Number > > > > | > > > > > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | > Event Sequence Number > > > > | > > > > > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > |x|S|x|x| > > > > | > > > > > +-+-+-+-+ Label > > > > | > > > > ~ > > > > ~ > > > > > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > |x|x|x|x|x|x|x|x| Message Type | > >Tech Type | > > > >Block Length | > > > > > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | > > > > | > > > > ~ > Extension Value > > > > ~ > > > > | > > > > | > > > > > > > > > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >Where > Label I suppose is taken from the RFC > >3292, section > > > >3.1.3: > (well, I'm guessing) > > > > > > > > A > summary of TLV labels supported in > >this version of the > > > protocol is > > > > listed below: > > > > > > > > TLV > Label Type Section Title > > > > > --------- ---- ------------- > > > > ATM > Label 0x100 ATM TLV Labels > > > > FR > Label 0x101 Frame Relay > >TLV Labels > > > > > MPLS Gen Label 0x102 MPLS > >Generic TLV Labels > > > > FEC > Label 0x103 FEC TLV Labels > > > > > > > > All > Labels will be designated as follow: > > > > > > > > 0 > 1 > >2 3 > > > > 0 1 2 > 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > >0 1 2 3 4 5 6 7 8 9 0 1 > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > |x|S|x|x| Label Type | > > Label Length | > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | > > | > > > > ~ > Label Value > > ~ > > > > | > > | > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > x: > Reserved Flags. > > > > > These are generally used by > >specific messages and will be > > > > > defined in those messages. > > > > > > > > S: > Stacked Label Indicator > > > > > Label Stacking is discussed below > >in section 3.1.3.5 > > > > > > > > Label Type > > > > > A 12-bit field indicating the type > >of label. > > > > > > > > Label Length > > > > > A 16-bit field indicating the > >length of the Label > > > Value field > > > > in bytes. > > > > > > > > Label Value > > > > > A variable length field that is an > >integer number of 32 bit > > > > > words long. The Label Value field > >is interpreted > > > according to > > > > > the Label Type as described in the > >following sections. > > > > > > > > > > > >The draft > is a bit obscure about this and > >since it doesn't > > > >specify > much, it can lead to > >misinterpretation for the unused > > > >part. > Moreover, it would appear that > >several implementations > > > >currently > use another format for the label > >field. Can you > > > >explain? > I mean, how come what's in the > >current draft doesn't > > > >match > what's known to be implemented? > > > > > > > >I'm still > wondering why we carried over > >pieces from GSMP that > > > >we do not > intend to use. > > > > > > > >I would > recommend that if we are to keep > >them but not use > > > >them, we > should mention precisely how we > >intend not to use > > > >them: > that is how many 0 filled bytes this > >is expected to use > > > > > > > >The rfc > 3292 doesn't cover the case where > >this field is not used. > > > > > > > >Can you > shed some ligths on this? > > > > > > > >Thanks > > > >Regards > > > >Phil > > > > > > > > > > > > > > > > > >>-------------------------------------------------------------------- > > > > > > > > >CONFIDENTIALITY NOTICE > > > > > > > >This > message and its attachments are > >addressed solely to the > > > >persons > above and may contain confidential > >information. If you > > > >have > received the message in error, be > >informed that any use > > > >of the > content hereof is prohibited. Please > >return it > > > > >immediately to the sender and delete the > >message. Should you > > > >have any > questions, please contact us by replying to > > > > >webmaster@telecomitalia.it. > > > > > > > > Thank you > > > > > > > > > >www.telecomitalia.it > > > > > > > > > >>-------------------------------------------------------------------- > > > > > > > > > > > > > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ancp > > > > > > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Jun 20 16:20:19 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42D13A6828; Fri, 20 Jun 2008 16:20:19 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364683A6813 for ; Fri, 20 Jun 2008 16:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96HSDCtKKMfG for ; Fri, 20 Jun 2008 16:20:13 -0700 (PDT) Received: from smtp128.rog.mail.re2.yahoo.com (smtp128.rog.mail.re2.yahoo.com [206.190.53.33]) by core3.amsl.com (Postfix) with SMTP id 70FBB3A686B for ; Fri, 20 Jun 2008 16:20:10 -0700 (PDT) Received: (qmail 95102 invoked from network); 20 Jun 2008 23:20:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=v21LaBRNNjzakew6BDjO2IO/TMOCT0ruPtrxEkZ42365jzF1opCBtekEUBFPGsX3P9u5FbL8vC7LdZCmyq9MlVFCmQXEilm2Tcfvq4PG5ecYlsUsfgiaTX33k1v1L2YW+i8mwEiyenEHj2E14a/ez4n7R0f/e1yO6D3PjJCbeY4= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@72.140.46.24 with plain) by smtp128.rog.mail.re2.yahoo.com with SMTP; 20 Jun 2008 23:20:08 -0000 X-YMail-OSG: OER3x7wVM1ltDZv0r9U0kZhiojMG94LwK57wshRd24QQ7kaOdHCQMElz9mhMX6xDww-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485C3B28.2050300@rogers.com> Date: Fri, 20 Jun 2008 19:20:08 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ancp@ietf.org Subject: [ANCP] Events and event flags X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org I'm in the process of trying to define an extension to ANCP to cover a multicast use case that isn't explicit in the framework. I need to define several events (e.g. to request more multicast bandwidth). Events seem to be tied closely to event flags and flow control flags in GSMPv3, which puts a sharp limit on the number of possible events due to limited flag field lengths. Has this been thought through in ANCP? What is the strategy, if any, for defining new events? Tom Taylor _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sat Jun 21 10:11:37 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38B33A688E; Sat, 21 Jun 2008 10:11:37 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79653A695B for ; Sat, 21 Jun 2008 10:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ocxm7yOCuJF for ; Sat, 21 Jun 2008 10:11:36 -0700 (PDT) Received: from smtp113.rog.mail.re2.yahoo.com (smtp113.rog.mail.re2.yahoo.com [68.142.225.229]) by core3.amsl.com (Postfix) with SMTP id B88293A6887 for ; Sat, 21 Jun 2008 10:11:35 -0700 (PDT) Received: (qmail 14806 invoked from network); 21 Jun 2008 17:11:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GgQIW+/8c3LaApmzvTYUaPfJUQpqKMLy39p9LWbjKuXlYTvTtlleDWHj/dVSmoNdWZa4cFPMmwszAc4qq+MntCpO1f2DGGJ/cKIgBPD0Wi49KXFCMQljMIZxX2h6m79C/y3ZCP8rXasSGDtQ7DZ5Q8DPGjB5ztrSHAN4r5axQN4= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@72.140.46.24 with plain) by smtp113.rog.mail.re2.yahoo.com with SMTP; 21 Jun 2008 17:11:35 -0000 X-YMail-OSG: UkVO7NAVM1kBS0DCI6i4gbh9mZh0jPE5iqcE7AcAyIjCYFRTwFaN7QoG32ZPYGDJpQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485D3644.1010202@rogers.com> Date: Sat, 21 Jun 2008 13:11:32 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ancp@ietf.org References: <485C3B28.2050300@rogers.com> In-Reply-To: <485C3B28.2050300@rogers.com> Subject: Re: [ANCP] Events and event flags X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Thinking about it further, I suggest that the base ANCP protocol document define one or two events. The extension TLV associated with them would contain event subtype as a mandatory component. Other components would be defined by the individual extension documents. If there is only one event, it should be "Admission Control Event". However, if there is a chance flow control is needed, there should be two events: "Resource Request Event" and "Resource Release Event". Obviously one would prefer not to flow control the latter, even if conditions are such that some flow control is needed. Tom Taylor wrote: > I'm in the process of trying to define an extension to ANCP to cover a > multicast use case that isn't explicit in the framework. I need to > define several events (e.g. to request more multicast bandwidth). Events > seem to be tied closely to event flags and flow control flags in GSMPv3, > which puts a sharp limit on the number of possible events due to limited > flag field lengths. Has this been thought through in ANCP? What is the > strategy, if any, for defining new events? > > Tom Taylor > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sun Jun 22 23:56:29 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0673A68DB; Sun, 22 Jun 2008 23:56:29 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A68A3A6901 for ; Sun, 22 Jun 2008 23:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4-SXH7MEWuv for ; Sun, 22 Jun 2008 23:56:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3A62F3A68DB for ; Sun, 22 Jun 2008 23:56:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,688,1204498800"; d="scan'208";a="12361155" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 Jun 2008 08:56:24 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5N6uOog010607; Mon, 23 Jun 2008 08:56:24 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5N6uMZD020769; Mon, 23 Jun 2008 06:56:24 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 08:56:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 08:56:23 +0200 Message-ID: In-Reply-To: <485C3B28.2050300@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Events and event flags Thread-Index: AcjTLDiQlfUq7NP7TpqbI8ccPMUSMgAW03Fg References: <485C3B28.2050300@rogers.com> From: "Wojciech Dec (wdec)" To: "Tom Taylor" , X-OriginalArrivalTime: 23 Jun 2008 06:56:23.0682 (UTC) FILETIME=[3FC69620:01C8D4FE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1879; t=1214204184; x=1215068184; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Events=20and=20event=20flags |Sender:=20; bh=7Ib3hxmOQFOb5gdYS1i+yn686ihVwWJVp55+oSt/xEo=; b=ujx4Ro2av+BDPK+9EoYkDnpUF5IM0UR7GA5nFu1MhdqtJ0TcYTsOfMr8Lu 6ADXavyJ20t2gIDcGsbYGszOO77QDirqcG676QiL4niRSGAQs1GS+7SuFclJ M01qQZlQto; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [ANCP] Events and event flags X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Tom, I strongly believe that the messaging, besides some of the base header, deriving from GSMPv3 are of little use. The approach you should consider is along the lines of the Design Team proposal for multicast control. I understand that an updated proposal from them is imminent (must be next week at the latest), but you can observe and follow the concept followed in the previous one: http://www.ietf.org/mail-archive/web/ancp/current/msg00548.html In more detail; - Define message types which allow re-use across applications - Define common TLV and wrapper TLVs used in messages. In particular the flag field and result code ANCP inherited from GSMP in the base header seem to be particularly unwieldy, and I would encourage limiting their use or re-defining in a manner that does not cause compatibility issues with existing ANCP implementations. Could you share with us the events and flow control requirements that you see? Regards, Woj. > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: 21 June 2008 01:20 > To: ancp@ietf.org > Subject: [ANCP] Events and event flags > > I'm in the process of trying to define an extension to ANCP > to cover a multicast use case that isn't explicit in the > framework. I need to define several events (e.g. to request > more multicast bandwidth). Events seem to be tied closely to > event flags and flow control flags in GSMPv3, which puts a > sharp limit on the number of possible events due to limited > flag field lengths. Has this been thought through in ANCP? > What is the strategy, if any, for defining new events? > > Tom Taylor > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jun 23 05:38:26 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA823A691B; Mon, 23 Jun 2008 05:38:26 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7CE3A68EF for ; Mon, 23 Jun 2008 05:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENVLFWKpfG7D for ; Mon, 23 Jun 2008 05:38:24 -0700 (PDT) Received: from smtp108.rog.mail.re2.yahoo.com (smtp108.rog.mail.re2.yahoo.com [68.142.225.206]) by core3.amsl.com (Postfix) with SMTP id 396573A691B for ; Mon, 23 Jun 2008 05:38:23 -0700 (PDT) Received: (qmail 57647 invoked from network); 23 Jun 2008 12:38:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=d4/5tO29naMf3eXkhEppO7PWOx19ofGWRtJjp4kT8d3E/mnPCCR6OuDTxPnMJPW3aF6YLp5IBYGyIAwJ+2HdX4Z1WZvct7XoKcBX1xOLk6GtPYM/lQaBoFzj9nhWrKz7oaSJx2XdaYs0sisB2wEWr1jcTrstyqH3W8qOuH1KEWc= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@72.140.46.24 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 23 Jun 2008 12:38:20 -0000 X-YMail-OSG: AXrjSBUVM1kEm9g5MCsUg4klfB42Ds7lK8V5mYxu3XqCcWpGNbnaX27aFaspkY4sxQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <485F9938.8020600@rogers.com> Date: Mon, 23 Jun 2008 08:38:16 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" References: <485C3B28.2050300@rogers.com> In-Reply-To: Cc: ancp@ietf.org Subject: Re: [ANCP] Events and event flags X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org I am considering a case where the task of multicast admission control is delegated to the Access Node. It is given an allocation of bandwidth for the purpose. From time to time it needs to request an increase in its allocation or it needs to give some back. In both cases, this requires an autonomously-generated message (i.e., an event report). I see a theoretical possibility that flow control would be needed in high-load situations, and of course, there is always the possibility of the misbehaving Access Node. An I-D has been written adopting a solution along the lines I previously indicated: a general Admission Control event with event subtypes. This draft is currently in the internal comment stage, but I'll share whatever text seems useful. Wojciech Dec (wdec) wrote: > Hi Tom, > > I strongly believe that the messaging, besides some of the base header, > deriving from GSMPv3 are of little use. The approach you should consider > is along the lines of the Design Team proposal for multicast control. I > understand that an updated proposal from them is imminent (must be next > week at the latest), but you can observe and follow the concept followed > in the previous one: > http://www.ietf.org/mail-archive/web/ancp/current/msg00548.html > > In more detail; > - Define message types which allow re-use across applications > - Define common TLV and wrapper TLVs used in messages. > > In particular the flag field and result code ANCP inherited from GSMP in > the base header seem to be particularly unwieldy, and I would encourage > limiting their use or re-defining in a manner that does not cause > compatibility issues with existing ANCP implementations. > Could you share with us the events and flow control requirements that > you see? > > Regards, > Woj. > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Jun 24 09:30:05 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AED328C137; Tue, 24 Jun 2008 09:30:05 -0700 (PDT) X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 740D33A6A6B; Tue, 24 Jun 2008 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080624163001.740D33A6A6B@core3.amsl.com> Date: Tue, 24 Jun 2008 09:30:01 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-mib-an-03.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Access Node Control Protocol (ANCP) MIB module for Access Nodes Author(s) : S. Cnodder, M. Morgenstern Filename : draft-ietf-ancp-mib-an-03.txt Pages : 37 Date : 2008-06-24 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-mib-an-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-mib-an-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-24092547.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --NextPart-- From ancp-bounces@ietf.org Wed Jun 25 07:07:14 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2243A6876; Wed, 25 Jun 2008 07:07:14 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156553A6876 for ; Wed, 25 Jun 2008 07:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNTQa7rTMv24 for ; Wed, 25 Jun 2008 07:07:03 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 443473A67E3 for ; Wed, 25 Jun 2008 07:07:03 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m5PE73dg005749 for ; Wed, 25 Jun 2008 16:07:03 +0200 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 25 Jun 2008 16:07:04 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 16:07:02 +0200 Message-ID: <0458D2EE0C36744BABB36BE37805C29A0225A287@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dublin ANCP slots Thread-Index: AcjWzIwZbUNC/xNnRHm1JtNrBg5L+QAAA+5w From: "BOCCI Matthew" To: X-OriginalArrivalTime: 25 Jun 2008 14:07:04.0002 (UTC) FILETIME=[BEA20220:01C8D6CC] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [ANCP] Dublin ANCP slots X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1934220552==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1934220552== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D6CC.BE6F3FE7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D6CC.BE6F3FE7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > Folks, >=20 > We have a session for ANCP, currently scheduled for 1300-1500 on > Wednesday 30th July.=20 >=20 > Please let me know if you would like a slot to present during the > meeting by 14th July.=20 >=20 > As usual, please send a brief summary of the topic, a pointer to the > draft (if any), and how much time you would like. >=20 > Regards, >=20 > Matthew ------_=_NextPart_001_01C8D6CC.BE6F3FE7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dublin ANCP slots

Folks,

We have a session for ANCP, currently = scheduled for 1300-1500 on Wednesday 30th July.

Please let me know if you would like a = slot to present during the meeting by 14th July.

As usual, please send a brief summary = of the topic, a pointer to the draft (if any), and how much time you = would like.

Regards,

Matthew

------_=_NextPart_001_01C8D6CC.BE6F3FE7-- --===============1934220552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============1934220552==-- From ancp-bounces@ietf.org Wed Jun 25 08:36:01 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D51228C0E4; Wed, 25 Jun 2008 08:36:01 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71FD83A68B7 for ; Wed, 25 Jun 2008 08:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwXDNy5vEB1C for ; Wed, 25 Jun 2008 08:35:58 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 5D7A83A6961 for ; Wed, 25 Jun 2008 08:35:51 -0700 (PDT) Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m5PFZpTG002436 for ; Wed, 25 Jun 2008 17:35:51 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 25 Jun 2008 17:35:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 17:35:49 +0200 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E01EEF16E@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-ancp-mib-an-03.txt Thread-Index: AcjW2SUNA4/y6j1jR+K+C6QxWBCJ1Q== From: "DE CNODDER Stefaan" To: X-OriginalArrivalTime: 25 Jun 2008 15:35:51.0692 (UTC) FILETIME=[262EFCC0:01C8D6D9] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [ANCP] I-D Action:draft-ietf-ancp-mib-an-03.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This new MIB draft is out, only a small change compared to version 02: MIB is put directly under mib-2 and not under ancpMIB node. This change is made because of this comment: http://www.ietf.org/mail-archive/web/ancp/current/msg00483.html regards, Stefaan [ANCP] I-D Action:draft-ietf-ancp-mib-an-03.txt ------------------------------------------------------------------------ -------- To: i-d-announce at ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-mib-an-03.txt From: Internet-Drafts at ietf.org Date: Tue, 24 Jun 2008 09:30:01 -0700 (PDT) Cc: ancp at ietf.org Delivered-to: ietfarch-ancp-web-archive at core3.amsl.com Delivered-to: ancp at core3.amsl.com List-archive: List-help: List-id: Access Node Control Protocol working group mailing list List-post: List-subscribe: , List-unsubscribe: , Sender: ancp-bounces at ietf.org ------------------------------------------------------------------------ -------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Access Node Control Protocol (ANCP) MIB module for Access Nodes Author(s) : S. Cnodder, M. Morgenstern Filename : draft-ietf-ancp-mib-an-03.txt Pages : 37 Date : 2008-06-24 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-mib-an-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ ANCP mailing list ANCP at ietf.org https://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jun 26 00:46:07 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C353A6803; Thu, 26 Jun 2008 00:46:07 -0700 (PDT) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87233A67D0 for ; Thu, 26 Jun 2008 00:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyEgcWPw4cJL for ; Thu, 26 Jun 2008 00:46:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 127393A6832 for ; Thu, 26 Jun 2008 00:45:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,707,1204498800"; d="scan'208,217";a="12706483" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Jun 2008 09:45:52 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5Q7jqYH001875; Thu, 26 Jun 2008 09:45:52 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5Q7jq3W000239; Thu, 26 Jun 2008 07:45:52 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 09:45:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 09:45:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request agenda items Thread-Index: AcjXYKPlb+O8adrmT1uBzZcaz+QxUA== From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 26 Jun 2008 07:45:52.0628 (UTC) FILETIME=[A8A50B40:01C8D760] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1589; t=1214466352; x=1215330352; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20Request=20agenda=20items |Sender:=20; bh=QGFrG6jqeXKq1I8eL2dpPKREpb/0j0zOIpi3jF6fUGk=; b=cER/EgYI1N1sZRHFpBqaH/tdTZMBnHhmvIMIa/KvfEG58O3kBNVs3lIflI kUvWns1OoyJdT4760T3LlZHKRmxCHfzrgKeqGTIA35AP1g6A4xrH44hxifcZ SJDLdoyxfu; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [ANCP] Request agenda items X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0678983169==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0678983169== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D760.A886249A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D760.A886249A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 If you have items you would like to discuss in the upcoming ANCP meeting during IETF 72, please send the chairs a request that includes the topic and amount of time desired. The current tentative item is: - Design Team update Thanks, Woj & Matthew ------_=_NextPart_001_01C8D760.A886249A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Request agenda items

All,
      =
If you have items you would like = to discuss in the upcoming ANCP meeting during IETF 72, please send the = chairs a request that includes the topic and amount of time = desired.

The current tentative item = is:
- Design Team update

Thanks,
Woj & Matthew

------_=_NextPart_001_01C8D760.A886249A-- --===============0678983169== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0678983169==--