From Lothar.Reith@detecon.com Mon Nov 2 01:40:19 2009 Return-Path: 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 175633A63C9 for ; Mon, 2 Nov 2009 01:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.225 X-Spam-Level: * X-Spam-Status: No, score=1.225 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, SUBJECT_FUZZY_TION=0.156] 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 jcUxycg86RAh for ; Mon, 2 Nov 2009 01:40:16 -0800 (PST) Received: from dtc034.detecon.net (dtc034.detecon.net [194.25.60.134]) by core3.amsl.com (Postfix) with ESMTP id DCBC83A635F for ; Mon, 2 Nov 2009 01:39:17 -0800 (PST) Received: from unknown (HELO dc00357.detecon.com) ([172.16.10.107]) by relay.dtc034.detecon.net with ESMTP; 02 Nov 2009 10:39:36 +0100 Received: from DC00331.detecon.com ([172.16.10.78]) by dc00357.detecon.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 10:39:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA5BA0.635E1AB4" Date: Mon, 2 Nov 2009 10:39:27 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAA7n/FAACxIQTAAAdj3kACIEpIg References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local><5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> From: "Reith, Lothar" To: "Wojciech Dec \(wdec\)" , "Haag, Thomas" , , , , , , , , "Paul, Manuel" , "Witschurke, Birgit" X-OriginalArrivalTime: 02 Nov 2009 09:39:36.0008 (UTC) FILETIME=[63C2B480:01CA5BA0] Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID 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: , X-List-Received-Date: Mon, 02 Nov 2009 09:40:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5BA0.635E1AB4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA5BA0.635E1AB4" ------_=_NextPart_002_01CA5BA0.635E1AB4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Woj, =20 I am afraid that your proposal means that we should use "sender-name" = instead of "partition-ID" to identify an AN partition. =20 Known implementations use "sender-name" to convey either the management = name of the AN (and the NAS/Controller respectively) or a MAC address as = GSMPv3 describes. =20 So for two reasons it is not possible to use "sender name" instead of = "partition ID": =20 1. The associated functionality to verify if one is talking to the = proper (intended) AN (or NAS/Controller respectively)=20 would be lost if when using the sender-id to convey the partition-ID = instead of the management name of the device. 2. If a MAC address information in "sender name" would be used for = "partition ID" only one partition can be used because usually a AN uses = one MAC address. So we have a conflict on networking because usually an = access node use one MAC Adresse regardles of partitioning.=20 =20 For that reasons I don't want to effectively abandon the partition-ID. I = highly recommend keeping the conventions (75th meeting minutes) for = partition ID as I understand they are meant to keep network scenarios = clean and avoid the mixing up of different layer informations. =20 Best Regards, =20 Lothar Reith Detecon International GmbH (Deutsche Telekom Group) ________________________________ Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Freitag, 30. Oktober 2009 18:19 An: Reith, Lothar; Haag, Thomas; roberta.maglione@telecomitalia.it; = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: RE: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 Hi Lothar, =20 =09 Having the NAS/controller verify the sender-name (as is done today), = with each partition using a different sender name, would accomplish the = use-case below, without partition-id. Any problem with this? =20 Thanks, Woj. =20 ________________________________ From: Reith, Lothar [mailto:Lothar.Reith@detecon.com]=20 Sent: 30 October 2009 17:17 To: Wojciech Dec (wdec); Haag, Thomas; = roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 Hi Woj, dear all, =20 I fully support Thomas Haag`s point in his mail. =20 I also noticed that the following section is no longer present in the = current version, and propose to re-include: =20 Partition ID: =09 This field is a 8 bit number which signifies a partition on the AN. [ TBD How AN and NAS agree on the partition numbers. = Possible options: =09 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; =09 2 - The partition ID could be statically configured on the NAS = as part of configuring the neighbor information.] =20 =20 I further suggest to enhance the text as follows: =20 Partition ID: =09 This field is a 8 bit number which signifies a partition on the AN. AN and NAS MAY agree on the partition ID using one of the = following possible options: =09 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; =09 2 - The partition ID could be statically configured on the NAS = as part of configuring the neighbor information. =20 =20 A potential use case could be in assurance, e.g. to enable = verification that the proper (intended) partition ID is used over a = particular adjacency in cases where the AN has multiple adjacencies to = different NAS/Controller.=20 =20 Best Regards, Lothar Reith =20 Detecon International GmbH (Deutsche Telekom Group) ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Wojciech Dec (wdec) Gesendet: Donnerstag, 29. Oktober 2009 19:45 An: Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: Re: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 While keeping the GSMP derived partition-id in the protocol spec "as = is" is fine, a note should perhaps also be inserted stating that this = field is effectively not currently used by ANCP. At least this is my = recollection of the discussion on this matter, ie partition-id is fine, = but we don't really have a use for it now given that functional = partitioning is not covered and that an AN will have 1 adjacency to each = NAS/controller. =20 -Woj. ________________________________ From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 28 October 2009 15:52 To: roberta.maglione@telecomitalia.it; Wojciech Dec (wdec); = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID =09 =09 Hi Roberta, all, =20 thanks for providing the updated protocol draft. =20 So far I recognized that the update covers issues regarding = versioning, tech Type for GPON and Range of values of the code field. =20 But I notice on page 17 of version 07 that the whole section of = partition ID including definition is deleted. From my understanding (and as result from the minutes) it was agreed = during 75th IETF meeting to keep the partition ID. =20 Extract from 75th IETF minutes:=20 =20 (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces = extensibility. Thomas Haag: need multiple partition-ids because one might need to = distinguish=20 between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational = problems=20 if partition-id not available.=20 No one felt strongly -- will keep "as is". =20 =09 So we had consensus not to remove and keep partion ID. But I didn't = find it in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are = there any reasons for doing this? =20 So I recommend update the protocol draft before upcoming meeting = keeping partition ID. =20 Regards =20 Thomas .=20 =20 ________________________________ Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps =09 =09 Hi All, I updated the ancp protocol draft following the chairs' = recommendations on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the = end of section 2:=20 "At the time of writing of this specification some implementations = of the ANCP protocol, based on pre-standards drafts are already = available. All these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed = from 1 to 2 upon publication.] Adopting a new sub-version value = provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP = implementation on any given ANCP node. The mechanism used to identify the = protocol version/sub-version is part of the adjacency negotiation process = and it is described in details in Section 5.2. It is important to = note that this mechanism does not guarantee backwards compatibility of = the ANCP RFC specification to those early-draft implementations." 2. I explained the version/sub-version negotiation process in = section 5.2:=20 "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 = upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In = a SYN message the version/sub-version fields always contain the = highest version understood by the sender. A receiver receiving a SYN = message with a version/sub-version higher than understood will ignore = that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP = version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in = the version/sub-version fields." =20 3. I added a non-normative appendix. This appendix will contain a = clarification of what version of the ANCP protocol draft specification = constitutes version 3.1 as soon as the WG decides on 3.1=20 "6. Appendix: Handling of pre-RFC deployments of the ANCP protocol =20 This appendix is non normative. =20 Prior to completion of this document, several pre-RFC versions of = the protocol were documented and implemented. There were numerous = pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document = may, on a peer basis, use the version and sub-version fields to detect = a pre-RFC implementation of the protocol and choose to work with = such pre-RFC peers. The version and sub-version negotiation phase is = part of the adjacency protocol and is performed before synchronisation = is achieved." =20 Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not = or if you have additional comments please let me know. =20 Best Regards, Roberta =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Wojciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps =20 =20 Hi All,=20 During the ITEF75 WG meeting a discussion was had on ANCP protocol = versioning and the need to revise the protocol version. A follow-up = e-mail discussion on the WG alias took place and it seems appropriate = now (if not overdue) to draw up a set of recommendations and settle the = issue: Recommended protocol draft changes and WG actions=20 - The currently used ANCP version 3.1 is to change to 3.2 at the = time of publishing as an RFC. An instruction to execute such a change = should be placed as part of an editors' note in the next revision of = draft-ietf-ancp-protocol. This instruction is expected to only come into = effect at the time of final review past a WG last-call, which means that = until then v3.1 will be in evidence. Current implementers should make a = note of this fact. - Another note (not editorial though) should be placed in an = appropriate section, possibly Section 2 or Section 5, to convey in-brief = the historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) = based on early versions of the ANCP protocol draft. The note should be = clear in offering no guarantees in terms of backwards compatibility of = the RFC spec to those early-draft implementations. The note must also = not be seen as passing a normative reference to the early protocol = draft.=20 - Along with the above note, the existing GSMP/ANCP version = negotiation mechanisms could be highlighted, indicating that it provides = a way to distinguish between the different versions if the adjacency = establishment negotiation mechanism followed by all is as per GSMPv3 = (rfc3292). - For the sake of clarity it is recommended that the adjacency = negotiation be more fully described in the ANCP protocol draft instead = of the current reference to rfc3292. Specifically, it would appear = reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP = protocol spec, with the re-edit describing the version negotiation = behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic statements as to the expected behaviour in case of version = differences, but such text is in evidence in the descriptive part of = Section 11.1. - The WG should identify what version of the ANCP protocol draft = specification constitutes v3.1. A non-normative reference to such a = reference could be passed in the v3.2 spec. Rationale=20 From a technical point of view, given that a "current" (i.e. = draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols = are identical, with any newly added functions covered as negotiable = capabilities, the version change does not appear to be fully warranted = and not fully in line with the guidelines previously laid down = (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html = ). = That said, from an operational perspective a reasonable case for such a = version change has made based and presented in = https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docume= nt.htm = .=20 Now, given that normative compliance to an interim draft (such as = draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text = which may be perceived as mandating or claiming compatibility to such = interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 = and have plans for v3.2, the version negotiation mechanism that ANCP = inherited from GSMPv3 provides a way to disambiguate the two protocols = and thus allows in theory for supporting running a pre-standard (v3.1) = and a standards compliant v3.2 on any given ANCP node. The issue of = where v3.1 is documented can be solved by using non-normative references = to one of the interim drafts. The issue of what rev of draft-ietf-ancp = is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be = extending the protocol spec to cover issues around protocol version = negotiation or remediation of incompatibilities of draft = implementations. As such no such work is expected. We welcome clarification questions on the above.=20 Regards,=20 Wojciech & Matthew.=20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.=20 ------_=_NextPart_002_01CA5BA0.635E1AB4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: ANCP = Versioning - next steps
 
Hi Woj,
 
I am afraid that your proposal means that we=20 should use =20 "sender-name" instead=20 of "partition-ID" to = identify an AN=20 partition.
 
Known = implementations=20 use  "sender-name" to=20 convey either the = management name of=20 the AN (and the NAS/Controller respectively) or a=20 MAC address as GSMPv3 = describes.
 
So for two = reasons it is=20 not possible to use "sender name" instead of "partition=20 ID":
 
1.=20 The associated functionality to verify if one = is=20 talking to the proper (intended) AN (or NAS/Controller=20 respectively) 
    would be lost=20 if when using the sender-id to convey the partition-ID instead = of the=20 management name of the device.
2. If = a MAC=20 address information in "sender name" would be used for "partition ID" = only one=20 partition can be used because usually a AN uses one MAC address. So we = have a=20 conflict on networking because usually an access node use one MAC = Adresse=20 regardles of partitioning.
 
For that = reasons I=20 don't want to effectively abandon the partition-ID. I highly recommend keeping the conventions = (75th=20 meeting minutes) for partition ID as I=20 understand they are meant = to=20 keep network scenarios clean and = avoid the=20 mixing up of = different layer=20 informations.
&nbs= p;
Best=20 Regards,
&nbs= p;
Lothar=20 Reith
Detecon International GmbH (Deutsche Telekom=20 Group)
=
Von: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Gesendet: Freitag, 30. Oktober 2009 = 18:19
An: Reith, Lothar; Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, = Manuel;=20 Witschurke, Birgit
Betreff: RE: [ANCP] ANCP Versioning - = next steps;=20 partition ID

Hi Lothar,
 
Having the NAS/controller verify the sender-name (as is done = today),=20 with each partition using a different sender name, would = accomplish the=20 use-case below, without partition-id. Any problem with=20 this?
 
Thanks,
Woj.
 

From: Reith, Lothar=20 [mailto:Lothar.Reith@detecon.com]
Sent: 30 October 2009=20 17:17
To: Wojciech Dec (wdec); Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke, = Birgit
Subject:=20 AW: [ANCP] ANCP Versioning - next steps; partition = ID

Hi Woj, = dear=20 all,
 
I fully support Thomas Haag`s point in his=20 mail.
 
I also noticed that the following section = is no longer=20 present in the current version, and propose to=20 re-include:
 
Partition=20 ID:

      This field is a 8 bit = number which=20 signifies a partition on the
      AN. [ = TBD How=20 AN and NAS agree on the partition numbers. =20 Possible
     =20 options:

      1 - The partition ID = could be=20 configured on the AN and learnt by
      = NAS in=20 the adjacency message;

      2 - The = partition ID could be statically configured on the NAS=20 as
      part of configuring the = neighbor=20 information.]
 
 
I further suggest to enhance the text as=20 follows:
 
Partition = ID:

     =20 This field is a 8 bit number which signifies a partition on=20 the
      AN.  AN and NAS MAY agree = on the=20 partition ID using one of the=20 following possible
     =20 options:

      1 - The partition ID = could be=20 configured on the AN and learnt by
      = NAS in=20 the adjacency message;

      2 - The = partition ID could be statically configured on the NAS=20 as
      part of configuring the = neighbor=20 information.
 
 
A potential use case could be in = assurance,=20 e.g. to enable verification that the proper = (intended) partition=20 ID is used over a particular adjacency in cases where the = AN has=20 multiple adjacencies to different = NAS/Controller. 
 
 Best Regards, Lothar=20 Reith
 
Detecon International GmbH (Deutsche = Telekom=20 Group)

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec=20 (wdec)
Gesendet: Donnerstag, 29. Oktober 2009=20 19:45
An: Haag, Thomas; = roberta.maglione@telecomitalia.it;=20 ancp@ietf.org; alan.kavanagh@ericsson.com; = Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke,=20 Birgit
Betreff: Re: [ANCP] ANCP Versioning - next steps; = partition ID

While keeping the GSMP derived partition-id in the = protocol=20 spec "as is" is fine, a note should perhaps also be inserted = stating that=20 this field is effectively not currently used by ANCP. At least = this is my=20 recollection of the discussion on this matter, ie partition-id is = fine,=20 but we don't really have a use for it now given that functional=20 partitioning is not covered and that an AN will have 1 adjacency = to each=20 NAS/controller.
 
-Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 28 October 2009=20 15:52
To: roberta.maglione@telecomitalia.it; Wojciech = Dec=20 (wdec); ancp@ietf.org; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net;=20 Manuel.Paul@telekom.de; = B.Witschurke@telekom.de
Subject: AW:=20 ANCP Versioning - next steps; partition ID

Hi Roberta, all,
 
thanks for providing the updated = protocol=20 draft.
 
So far I recognized that the update = covers issues=20 regarding versioning, tech Type for GPON and Range of values of = the code=20 field.
 
But I notice on page 17 of version 07 = that the=20 whole section of partition ID including definition is=20 deleted.
From my understanding (and as = result from the=20 minutes) it was agreed during 75th IETF meeting to keep the = partition=20 ID.
 
Extract from 75th IETF minutes:=20
 
(1) = Partition-id
    ------------
Sanjay: = concerned=20 that removing the partition-id reduces extensibility.
Thomas = Haag:=20 need multiple partition-ids because one might need to = distinguish=20
between BRASs when expanding the network.
Woj: send = e-mail.=20 Thomas: already did. Makes for operational problems
if = partition-id=20 not available.
No one felt strongly -- will keep "as=20 is".
 
So we had consensus not to remove = and keep=20 partion ID. But I didn't find it in the whole document any=20 more.
Based on that agreements I wonder why this issue is = deleted. Are there any reasons for doing=20 this?
 
So I recommend update the protocol = draft before=20 upcoming meeting keeping partition ID.
 
Regards
 
Thomas
.
 

Von: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it]
Gesendet: = Montag,=20 19. Oktober 2009 16:16
An: 'Wojciech Dec (wdec)';=20 ancp@ietf.org; Haag, Thomas; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net; BOCCI Matthew; = 'tom111.taylor@bell.net'
Betreff: RE: ANCP Versioning = - next=20 steps

Hi=20 All,

    =20 I updated the ancp protocol draft following the chairs=92 = recommendations=20 on the ANCP versioning.

In=20 particular:

  1. I added some = text to=20 explain the history and rationale, at the end of section=20 2:

 =93At the=20 time of writing of this specification some implementations of = the ANCP=20 protocol, based on pre-standards drafts are already = available.  All=20 these early-draft implementations use=20 protocol

  =20 version/sub-version 3.1; standard ANCP protocol will use=20 version/

  =20 sub-version 3.2 [Editor's note: sub-version needs to be changed=20 from

  =20 1 to 2 upon publication.]  Adopting a new sub-version value = provides

  =20 a way to disambiguate the two protocols and allows for=20 supporting

  =20 running a pre-standard and a standards compliant ANCP=20 implementation

  =20 on any given ANCP node.  The mechanism used to identify the = protocol

  =20 version/sub-version is part of the adjacency negotiation process = and

  =20 it is described in details in Section 5.2.  It is important = to=20 note

  =20 that this mechanism does not guarantee backwards compatibility = of=20 the

  =20 ANCP RFC specification to those early-draft=20 implementations.=94

  1. I explained the=20 version/sub-version negotiation process in section=20 5.2:=20

=93ANCP=20 uses version 3 and sub-version 1 of GSMP=20 protocol.

  =20 [RFC Editor's note: sub-version needs to be changed from 1 to 2=20 upon

  =20 publication.]  In the adjacency protocol the version and = the=20 sub-

  =20 version fields are used for version negotiation.  The=20 version

  =20 negotiation is performed before synchronisation is = achieved.  In=20 a

  =20 SYN message the version/sub-version fields always contain the=20 highest

  =20 version understood by the sender.  A receiver receiving a = SYN=20 message

  =20 with a version/sub-version higher than understood will ignore=20 that

  =20 message.  A receiver receiving a SYN message with a=20 version/

  =20 sub-vresion lower than its own highest version/sub-version, but=20 a

  =20 version/sub-version that it understands, will reply with a=20 SYNACK

  =20 with the version/sub-version from the received SYN in its ANCP=20 version/sub-version fields.  This defines the = version/sub-version=20 of

  =20 the ANCP protocol to be used while the adjacency protocol=20 remains

  =20 synchronised.  All other messages will use the agreed = version in=20 the

  =20 version/sub-version fields.=94

 

  1. I=20 added a non-normative appendix. This appendix = will contain=20 a clarification of what version of the ANCP protocol draft=20 specification constitutes version 3.1 as soon as the WG = decides on=20 3.1=20

=936. =20 Appendix: Handling of pre-RFC deployments of the ANCP =20 protocol

 

  =20 This appendix is non normative.

 

  =20 Prior to completion of this document, several pre-RFC versions = of=20 the

  =20 protocol were documented and implemented.  There were = numerous=20 pre-

  =20 standard versions of the protocol all using a=20 version/sub-version

  =20 fields set to 3.1.

 

  =20 A NAS implementing the ANCP protocol as defined in this document = may,

  =20 on a peer basis, use the version and sub-version fields to = detect=20 a

  =20 pre-RFC implementation of the protocol and choose to work with=20 such

  =20 pre-RFC peers.  The version and sub-version negotiation = phase is=20 part

  =20 of the adjacency protocol and is performed before = synchronisation=20 is

  =20 achieved.=94

 

Please find new=20 version of draft attached.

I = hope I=92ve=20 captured most of your feedback in the new draft, if not or if = you have=20 additional comments please let me = know.

 

Best=20 Regards,

Roberta

 

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On=20 Behalf Of Wojciech Dec (wdec)
Sent: Wednesday, October = 14, 2009=20 1:07 PM
To:=20 ancp@ietf.org
Subject: [ANCP] FW: ANCP = Versioning=20 - next steps

 

 

Hi = All,

During the ITEF75 = WG meeting=20 a discussion was had on ANCP protocol versioning and the need to = revise=20 the protocol version. A follow-up e-mail discussion on the WG = alias took=20 place and it seems appropriate now (if not overdue) to draw = up a set of=20 recommendations and settle the = issue:

Recommended = protocol draft=20 changes and WG=20 actions=20

- The currently = used ANCP=20 version 3.1 is to change to 3.2 at the time of publishing as an = RFC. An=20 instruction to execute such a change should be placed as part of = an=20 editors' note in the next revision of draft-ietf-ancp-protocol. = This=20 instruction is expected to only come into effect at the time of = final=20 review past a WG last-call, which means that until then v3.1 = will be in=20 evidence. Current implementers should make a note of this=20 fact.

- Another note = (not=20 editorial though) should be placed in an appropriate section, = possibly=20 Section 2 or Section 5, to convey in-brief the historic aspect = of=20 GSMP/ANCP v3.1 implementations, which are (were?) based on early = versions of the ANCP protocol draft. The note should be clear in = offering no guarantees in terms of backwards compatibility of = the RFC=20 spec to those early-draft implementations. The note must also = not be=20 seen as passing a normative reference to the early protocol = draft.=20

- Along with the = above note,=20 the existing GSMP/ANCP version negotiation mechanisms could be=20 highlighted, indicating that it provides a way to distinguish = between=20 the different versions if the adjacency establishment = negotiation=20 mechanism followed by all is as per GSMPv3=20 (rfc3292).

- For the sake of = clarity it=20 is recommended that the adjacency negotiation be more fully = described in=20 the ANCP protocol draft instead of the current reference to = rfc3292.=20 Specifically, it would appear reasonable to adopt and re-edit = Section=20 11.2 of rfc3292 into the ANCP protocol spec, with the re-edit = describing=20 the version negotiation behaviour. Rather confusingly Rfc3292 = Section=20 11.2 does not carry text or logic statements as to the expected=20 behaviour in case of version differences, but such text is in = evidence=20 in the descriptive part of Section = 11.1.

- = The WG=20 should identify what version of the ANCP protocol draft = specification=20 constitutes v3.1. A non-normative reference to such a reference = could be=20 passed in the v3.2 spec.

Rationale

From a technical = point of=20 view, given that a "current" (i.e.=20 draft-ietf-protocol-06 based) = and future=20 (i.e.=20 ANCP RFC based) = protocols=20 are identical, with any=20 newly added functions covered as=20 negotiable = capabilities, the=20 version change = does=20 not appear to be fully=20 warranted and not = fully in=20 line with the guidelines previously laid down (= http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That said, from = an=20 operational = perspective a = reasonable=20 case for such=20 a version change = has=20 made based and = presented in=20 https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3= _document.htm.=20

Now, = given that = normative=20 compliance to an interim draft (such as draft-ietf-protocol-06=20 based) = cannot be passed = by the ANCP=20 RFC, text which may=20 be perceived as = mandating or=20 claiming compatibility to such  interim drafts = needs to be=20 avoided.

In the case of=20 vendors and = operators that=20 already = support/use v3.1 and=20 have plans for v3.2, the version negotiation mechanism that ANCP = inherited from GSMPv3 provides a way to disambiguate the two = protocols=20 and thus=20 allows in theory = for supporting = running a=20 pre-standard (v3.1) and a standards compliant v3.2 on any given = ANCP=20 node. The issue = of where=20 v3.1 is documented can be solved by using non-normative = references to=20 one of the interim drafts. The issue of what rev of = draft-ietf-ancp is=20 considered to be v3.1 needs to be=20 clarified.

Other than the = above the WG=20 is currently not chartered=20 to be extending the protocol spec to cover issues = around=20 protocol version negotiation or remediation of incompatibilities = of=20 draft implementations. As=20 such no such work is=20 expected.

We = welcome=20 clarification questions on the above.=20

Regards,=20
Wojciech &=20 Matthew.=20

Questo = messaggio e=20 i suoi allegati sono indirizzati esclusivamente alle = persone=20 indicate. La diffusione, copia o qualsiasi altra azione = derivante=20 dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per = errore=20 siete cortesemente pregati di darne immediata = comunicazione al=20 mittente e di provvedere alla sua distruzione, Grazie.=20

This=20 e-mail and any attachments is confidential=20 and may contain privileged information intended for the=20 addressee(s) only. Dissemination, copying, printing or use = by=20 anybody else is unauthorised. If you are not the intended=20 recipient, please delete this message and any attachments = and=20 advise the sender by return e-mail, = Thanks.=20

3D"rispettaRispetta l'ambiente. Non stampare questa mail = se non =E8=20 necessario.=20 =

<= /BLOCKQUOTE> ------_=_NextPart_002_01CA5BA0.635E1AB4-- ------_=_NextPart_001_01CA5BA0.635E1AB4 Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: <984283609@02112009-178C> Content-Description: logo Ambiente_foglia.jpg Content-Location: logo%20Ambiente_foglia.jpg R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------_=_NextPart_001_01CA5BA0.635E1AB4-- From wdec@cisco.com Mon Nov 2 05:54:21 2009 Return-Path: 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 082523A6A07 for ; Mon, 2 Nov 2009 05:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.413 X-Spam-Level: X-Spam-Status: No, score=-5.413 tagged_above=-999 required=5 tests=[AWL=-4.031, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] 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 jSj3C-Y8zUx4 for ; Mon, 2 Nov 2009 05:54:18 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D5C763A69CB for ; Mon, 2 Nov 2009 05:54:17 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo Ambiente_foglia.jpg : 677 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAEdz7kqrR7Ht/2dsb2JhbACCJywhhFU2j1atQIkajT+CNA+BdgSBYooi X-IronPort-AV: E=Sophos;i="4.44,667,1249257600"; d="jpg'147?scan'147,208,217,147";a="422860392" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 02 Nov 2009 13:54:36 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA2DsYBY026477; Mon, 2 Nov 2009 13:54:36 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 14:54:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA5BC4.020DF632" Date: Mon, 2 Nov 2009 14:54:26 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAA7n/FAACxIQTAAAdj3kACIEpIgAAjG22A= References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local><5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> From: "Wojciech Dec (wdec)" To: "Reith, Lothar" , "Haag, Thomas" , , , , , , , , "Paul, Manuel" , "Witschurke, Birgit" X-OriginalArrivalTime: 02 Nov 2009 13:54:34.0357 (UTC) FILETIME=[02498250:01CA5BC4] Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID 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: , X-List-Received-Date: Mon, 02 Nov 2009 13:54:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5BC4.020DF632 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA5BC4.020DF632" ------_=_NextPart_002_01CA5BC4.020DF632 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lothar, =20 ________________________________ From: Reith, Lothar [mailto:Lothar.Reith@detecon.com]=20 Sent: 02 November 2009 10:39 To: Wojciech Dec (wdec); Haag, Thomas; = roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID =20 =09 Hi Woj, =20 I am afraid that your proposal means that we should use "sender-name" = instead of "partition-ID" to identify an AN partition. =20 Known implementations use "sender-name" to convey either the = management name of the AN (and the NAS/Controller respectively) or a MAC = address as GSMPv3 describes. =20 Woj> The choice of what goes into the sender-name is rather arbitrary; = having a name + partition-id is pretty much as the same as having a name = with partition-id. Furthermore, we're now at v3.2 of ANCP... =20 So for two reasons it is not possible to use "sender name" instead of = "partition ID": =20 1. The associated functionality to verify if one is talking to the = proper (intended) AN (or NAS/Controller respectively)=20 would be lost if when using the sender-id to convey the = partition-ID instead of the management name of the device.=20 =20 Woj> How so? The name is an opaque value that has significance to the = operator, very much like partition-id. =20 =09 2. If a MAC address information in "sender name" would be used for = "partition ID" only one partition can be used because usually a AN uses = one MAC address. So we have a conflict on networking because usually an = access node use one MAC Adresse regardles of partitioning. =20 =20 Woj> Please note that GSMP recommended the use of MAC addresses because = it was meant to run on TCP/IP. In ANCP , you can identify each AN with = the IP address and the sender-name is pretty much redudnant today. = However it appears it could well be used for the use-case you described. =20 For that reasons I don't want to effectively abandon the partition-ID. = I highly recommend keeping the conventions (75th meeting minutes) for = partition ID as I understand they are meant to keep network scenarios = clean and avoid the mixing up of different layer informations.=20 =20 Woj> The existing "conventions" amount to partition-id beingthere, like = other GSMP fields, but its use is not currently specified in ANCP. =20 Regards, Woj.=20 =20 Best Regards, =20 Lothar Reith Detecon International GmbH (Deutsche Telekom Group) ________________________________ Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Freitag, 30. Oktober 2009 18:19 An: Reith, Lothar; Haag, Thomas; roberta.maglione@telecomitalia.it; = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: RE: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 Hi Lothar, =20 =09 Having the NAS/controller verify the sender-name (as is done today), = with each partition using a different sender name, would accomplish the = use-case below, without partition-id. Any problem with this? =20 Thanks, Woj. =20 ________________________________ From: Reith, Lothar [mailto:Lothar.Reith@detecon.com]=20 Sent: 30 October 2009 17:17 To: Wojciech Dec (wdec); Haag, Thomas; = roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 Hi Woj, dear all, =20 I fully support Thomas Haag`s point in his mail. =20 I also noticed that the following section is no longer present in the = current version, and propose to re-include: =20 Partition ID: =09 This field is a 8 bit number which signifies a partition on the AN. [ TBD How AN and NAS agree on the partition numbers. = Possible options: =09 1 - The partition ID could be configured on the AN and learnt = by NAS in the adjacency message; =09 2 - The partition ID could be statically configured on the NAS = as part of configuring the neighbor information.] =20 =20 I further suggest to enhance the text as follows: =20 Partition ID: =09 This field is a 8 bit number which signifies a partition on the AN. AN and NAS MAY agree on the partition ID using one of the = following possible options: =09 1 - The partition ID could be configured on the AN and learnt = by NAS in the adjacency message; =09 2 - The partition ID could be statically configured on the NAS = as part of configuring the neighbor information. =20 =20 A potential use case could be in assurance, e.g. to enable = verification that the proper (intended) partition ID is used over a = particular adjacency in cases where the AN has multiple adjacencies to = different NAS/Controller.=20 =20 Best Regards, Lothar Reith =20 Detecon International GmbH (Deutsche Telekom Group) ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Wojciech Dec (wdec) Gesendet: Donnerstag, 29. Oktober 2009 19:45 An: Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: Re: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 While keeping the GSMP derived partition-id in the protocol spec "as = is" is fine, a note should perhaps also be inserted stating that this = field is effectively not currently used by ANCP. At least this is my = recollection of the discussion on this matter, ie partition-id is fine, = but we don't really have a use for it now given that functional = partitioning is not covered and that an AN will have 1 adjacency to each = NAS/controller. =20 -Woj. ________________________________ From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 28 October 2009 15:52 To: roberta.maglione@telecomitalia.it; Wojciech Dec (wdec); = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID =09 =09 Hi Roberta, all, =20 thanks for providing the updated protocol draft. =20 So far I recognized that the update covers issues regarding = versioning, tech Type for GPON and Range of values of the code field. =20 But I notice on page 17 of version 07 that the whole section of = partition ID including definition is deleted. From my understanding (and as result from the minutes) it was = agreed during 75th IETF meeting to keep the partition ID. =20 Extract from 75th IETF minutes:=20 =20 (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces = extensibility. Thomas Haag: need multiple partition-ids because one might need to = distinguish=20 between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational = problems=20 if partition-id not available.=20 No one felt strongly -- will keep "as is". =20 =09 So we had consensus not to remove and keep partion ID. But I didn't = find it in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are = there any reasons for doing this? =20 So I recommend update the protocol draft before upcoming meeting = keeping partition ID. =20 Regards =20 Thomas .=20 =20 ________________________________ Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps =09 =09 Hi All, I updated the ancp protocol draft following the chairs' = recommendations on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the = end of section 2:=20 "At the time of writing of this specification some implementations = of the ANCP protocol, based on pre-standards drafts are already = available. All these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use = version/ sub-version 3.2 [Editor's note: sub-version needs to be changed = from 1 to 2 upon publication.] Adopting a new sub-version value = provides a way to disambiguate the two protocols and allows for = supporting running a pre-standard and a standards compliant ANCP = implementation on any given ANCP node. The mechanism used to identify the = protocol version/sub-version is part of the adjacency negotiation process = and it is described in details in Section 5.2. It is important to = note that this mechanism does not guarantee backwards compatibility = of the ANCP RFC specification to those early-draft implementations." 2. I explained the version/sub-version negotiation process in = section 5.2:=20 "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 = upon publication.] In the adjacency protocol the version and the = sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In = a SYN message the version/sub-version fields always contain the = highest version understood by the sender. A receiver receiving a SYN = message with a version/sub-version higher than understood will ignore = that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but = a version/sub-version that it understands, will reply with a = SYNACK with the version/sub-version from the received SYN in its ANCP = version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol = remains synchronised. All other messages will use the agreed version in = the version/sub-version fields." =20 3. I added a non-normative appendix. This appendix will contain a = clarification of what version of the ANCP protocol draft specification = constitutes version 3.1 as soon as the WG decides on 3.1=20 "6. Appendix: Handling of pre-RFC deployments of the ANCP = protocol =20 This appendix is non normative. =20 Prior to completion of this document, several pre-RFC versions = of the protocol were documented and implemented. There were numerous = pre- standard versions of the protocol all using a = version/sub-version fields set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document = may, on a peer basis, use the version and sub-version fields to = detect a pre-RFC implementation of the protocol and choose to work with = such pre-RFC peers. The version and sub-version negotiation phase is = part of the adjacency protocol and is performed before = synchronisation is achieved." =20 Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not = or if you have additional comments please let me know. =20 Best Regards, Roberta =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Wojciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps =20 =20 Hi All,=20 During the ITEF75 WG meeting a discussion was had on ANCP protocol = versioning and the need to revise the protocol version. A follow-up = e-mail discussion on the WG alias took place and it seems appropriate = now (if not overdue) to draw up a set of recommendations and settle the = issue: Recommended protocol draft changes and WG actions=20 - The currently used ANCP version 3.1 is to change to 3.2 at the = time of publishing as an RFC. An instruction to execute such a change = should be placed as part of an editors' note in the next revision of = draft-ietf-ancp-protocol. This instruction is expected to only come into = effect at the time of final review past a WG last-call, which means that = until then v3.1 will be in evidence. Current implementers should make a = note of this fact. - Another note (not editorial though) should be placed in an = appropriate section, possibly Section 2 or Section 5, to convey in-brief = the historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) = based on early versions of the ANCP protocol draft. The note should be = clear in offering no guarantees in terms of backwards compatibility of = the RFC spec to those early-draft implementations. The note must also = not be seen as passing a normative reference to the early protocol = draft.=20 - Along with the above note, the existing GSMP/ANCP version = negotiation mechanisms could be highlighted, indicating that it provides = a way to distinguish between the different versions if the adjacency = establishment negotiation mechanism followed by all is as per GSMPv3 = (rfc3292). - For the sake of clarity it is recommended that the adjacency = negotiation be more fully described in the ANCP protocol draft instead = of the current reference to rfc3292. Specifically, it would appear = reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP = protocol spec, with the re-edit describing the version negotiation = behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic statements as to the expected behaviour in case of version = differences, but such text is in evidence in the descriptive part of = Section 11.1. - The WG should identify what version of the ANCP protocol draft = specification constitutes v3.1. A non-normative reference to such a = reference could be passed in the v3.2 spec. Rationale=20 From a technical point of view, given that a "current" (i.e. = draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols = are identical, with any newly added functions covered as negotiable = capabilities, the version change does not appear to be fully warranted = and not fully in line with the guidelines previously laid down = (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html = ). = That said, from an operational perspective a reasonable case for such a = version change has made based and presented in = https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docume= nt.htm = .=20 Now, given that normative compliance to an interim draft (such as = draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text = which may be perceived as mandating or claiming compatibility to such = interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 = and have plans for v3.2, the version negotiation mechanism that ANCP = inherited from GSMPv3 provides a way to disambiguate the two protocols = and thus allows in theory for supporting running a pre-standard (v3.1) = and a standards compliant v3.2 on any given ANCP node. The issue of = where v3.1 is documented can be solved by using non-normative references = to one of the interim drafts. The issue of what rev of draft-ietf-ancp = is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be = extending the protocol spec to cover issues around protocol version = negotiation or remediation of incompatibilities of draft = implementations. As such no such work is expected. We welcome clarification questions on the above.=20 Regards,=20 Wojciech & Matthew.=20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.=20 ------_=_NextPart_002_01CA5BC4.020DF632 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: ANCP = Versioning - next steps
Hi Lothar,
 
From: Reith, Lothar=20 [mailto:Lothar.Reith@detecon.com]
Sent: 02 November 2009=20 10:39
To: Wojciech Dec (wdec); Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, = Manuel;=20 Witschurke, Birgit
Subject: AW: [ANCP] ANCP Versioning - next = steps;=20 partition ID

 
Hi Woj,
 
I am afraid that your proposal means that = we=20 should use =20 "sender-name" instead=20 of "partition-ID" to = identify an AN=20 partition.
 
Known=20 implementations use  "sender-name" to convey either the management name of the AN = (and the=20 NAS/Controller respectively) or a MAC = address=20 as GSMPv3 describes.
 
Woj> = The choice of=20 what goes into the sender-name is rather arbitrary; having a name +=20 partition-id is pretty much as the same as having a name with=20 partition-id.
Furthermore, we're now=20 at v3.2 of ANCP...
 
So for two = reasons it=20 is not possible to use "sender name" instead of "partition=20 ID":
 
1.=20 The associated functionality to verify if = one is=20 talking to the proper (intended) AN (or NAS/Controller=20 respectively) 
    would be = lost=20 if when using the sender-id to convey the partition-ID = instead of=20 the management name of the device. 
 
Woj> = How so? The=20 name is an opaque value that has significance to the operator, very = much like=20 partition-id.
 
2. If a MAC address information in "sender name" = would be=20 used for "partition ID" only one partition can be used because usually = a AN=20 uses one MAC address. So we have a conflict on networking because = usually an=20 access node use one MAC Adresse regardles of partitioning.  
&nbs= p;
Woj> Please note=20 that GSMP recommended the use of MAC addresses because it was meant to = run on=20 TCP/IP. In ANCP , you can identify each=20 AN with the IP address and the sender-name is pretty much redudnant = today.=20 However it appears it could well be used for the use-case you=20 described.
 
For=20 that reasons I don't want to effectively abandon the = partition-ID. I highly recommend keeping the = conventions (75th=20 meeting minutes) for partition ID as I understand they are meant to keep network scenarios=20 clean and avoid the = mixing=20 up of different layer=20 informations. 
 
Woj> The=20 existing "conventions" amount to partition-id beingthere, = like other=20 GSMP fields, but its use is not currently specified in=20 ANCP.
 
Regards,=
Woj. 
&nbs= p;
Best=20 Regards,
&nbs= p;
Lothar=20 Reith
Detecon International GmbH (Deutsche = Telekom=20 = Group)
=
Von: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Gesendet: Freitag, 30. Oktober = 2009=20 18:19
An: Reith, Lothar; Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke, = Birgit
Betreff:=20 RE: [ANCP] ANCP Versioning - next steps; partition = ID

Hi Lothar,
 
Having the NAS/controller verify the sender-name (as is = done today),=20 with each partition using a different sender name, would = accomplish the=20 use-case below, without partition-id. Any problem with=20 this?
 
Thanks,
Woj.
 

From: Reith, Lothar=20 [mailto:Lothar.Reith@detecon.com]
Sent: 30 October 2009 = 17:17
To: Wojciech Dec (wdec); Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke,=20 Birgit
Subject: AW: [ANCP] ANCP Versioning - next steps; = partition ID

Hi = Woj, dear=20 all,
 
I fully support Thomas Haag`s point in = his=20 mail.
 
I also noticed that the following section = is no=20 longer present in the current version, and propose to=20 re-include:
 
Partition=20 ID:

      This field is a 8 bit = number=20 which signifies a partition on = the
      AN. [=20 TBD How AN and NAS agree on the partition numbers. =20 Possible
     =20 options:

      1 - The partition = ID could=20 be configured on the AN and learnt = by
     =20 NAS in the adjacency = message;

      2 -=20 The partition ID could be statically configured on the NAS=20 as
      part of configuring the = neighbor=20 information.]
 
 
I further suggest to enhance the text = as=20 follows:
 
Partition=20 ID:

      This field is a 8 bit = number=20 which signifies a partition on = the
     =20 AN.  AN and NAS MAY agree on the partition ID using one of = the=20 following possible
     =20 options:

      1 - The partition = ID could=20 be configured on the AN and learnt = by
     =20 NAS in the adjacency = message;

      2 -=20 The partition ID could be statically configured on the NAS=20 as
      part of configuring the = neighbor=20 information.
 
 
A potential use case could be in = assurance,=20 e.g. to enable verification that the proper = (intended) partition=20 ID is used over a particular adjacency in cases where = the AN has=20 multiple adjacencies to different=20 NAS/Controller. 
 
 Best Regards, Lothar=20 Reith
 
Detecon International GmbH (Deutsche = Telekom=20 Group)

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech = Dec=20 (wdec)
Gesendet: Donnerstag, 29. Oktober 2009=20 19:45
An: Haag, Thomas; = roberta.maglione@telecomitalia.it;=20 ancp@ietf.org; alan.kavanagh@ericsson.com; = Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke,=20 Birgit
Betreff: Re: [ANCP] ANCP Versioning - next = steps;=20 partition ID

While keeping the GSMP derived partition-id in the = protocol=20 spec "as is" is fine, a note should perhaps also be inserted = stating=20 that this field is effectively not currently used by ANCP. At = least this=20 is my recollection of the discussion on this matter, ie = partition-id is=20 fine, but we don't really have a use for it now given that = functional=20 partitioning is not covered and that an AN will have 1 adjacency = to each=20 NAS/controller.
 
-Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 28 October 2009=20 15:52
To: roberta.maglione@telecomitalia.it; = Wojciech Dec=20 (wdec); ancp@ietf.org; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net;=20 Manuel.Paul@telekom.de; = B.Witschurke@telekom.de
Subject: AW:=20 ANCP Versioning - next steps; partition = ID

Hi Roberta, = all,
 
thanks for providing the = updated=20 protocol draft.
 
So far I recognized that = the update=20 covers issues regarding versioning, tech Type for GPON and = Range of=20 values of the code field.
 
But I notice on page 17 = of version 07=20 that the whole section of partition ID including definition is = deleted.
From my understanding = (and as=20 result from the minutes) it was agreed during 75th IETF = meeting=20 to keep the partition ID.
 
Extract from 75th = IETF minutes:=20
 
(1)=20 Partition-id
    ------------
Sanjay: = concerned=20 that removing the partition-id reduces = extensibility.
Thomas Haag:=20 need multiple partition-ids because one might need to = distinguish=20
between BRASs when expanding the network.
Woj: send = e-mail.=20 Thomas: already did. Makes for operational problems
if=20 partition-id not available.
No one felt strongly -- will = keep "as=20 is".
 
So we had consensus = not to remove=20 and keep partion ID. But I didn't find it in the whole = document any=20 more.
Based on that agreements I wonder why this issue is=20 deleted. Are there any = reasons for=20 doing this?
 
So I recommend update = the protocol=20 draft before upcoming meeting keeping partition=20 ID.
 
Regards
 
Thomas
.
 

Von: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it] =
Gesendet:=20 Montag, 19. Oktober 2009 16:16
An: 'Wojciech Dec = (wdec)';=20 ancp@ietf.org; Haag, Thomas; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net; BOCCI = Matthew;=20 'tom111.taylor@bell.net'
Betreff: RE: ANCP = Versioning - next=20 steps

Hi=20 All,

    =20 I updated the ancp protocol draft following the chairs=92=20 recommendations on the ANCP = versioning.

In=20 particular:

  1. I added some = text to=20 explain the history and rationale, at the end of section=20 2:

 =93At=20 the time of writing of this specification some implementations = of the=20 ANCP protocol, based on pre-standards drafts are already=20 available.  All these early-draft implementations use=20 protocol

  =20 version/sub-version 3.1; standard ANCP protocol will use=20 version/

  =20 sub-version 3.2 [Editor's note: sub-version needs to be = changed=20 from

  =20 1 to 2 upon publication.]  Adopting a new sub-version = value=20 provides

  =20 a way to disambiguate the two protocols and allows for=20 supporting

  =20 running a pre-standard and a standards compliant ANCP=20 implementation

  =20 on any given ANCP node.  The mechanism used to identify = the=20 protocol

  =20 version/sub-version is part of the adjacency negotiation = process=20 and

  =20 it is described in details in Section 5.2.  It is = important to=20 note

  =20 that this mechanism does not guarantee backwards compatibility = of=20 the

  =20 ANCP RFC specification to those early-draft=20 implementations.=94

  1. I explained = the=20 version/sub-version negotiation process in section=20 5.2:=20

=93ANCP=20 uses version 3 and sub-version 1 of GSMP=20 protocol.

  =20 [RFC Editor's note: sub-version needs to be changed from 1 to = 2=20 upon

  =20 publication.]  In the adjacency protocol the version and = the=20 sub-

  =20 version fields are used for version negotiation.  The=20 version

  =20 negotiation is performed before synchronisation is = achieved.  In=20 a

  =20 SYN message the version/sub-version fields always contain the=20 highest

  =20 version understood by the sender.  A receiver receiving a = SYN=20 message

  =20 with a version/sub-version higher than understood will ignore=20 that

  =20 message.  A receiver receiving a SYN message with a=20 version/

  =20 sub-vresion lower than its own highest version/sub-version, = but=20 a

  =20 version/sub-version that it understands, will reply with a=20 SYNACK

  =20 with the version/sub-version from the received SYN in its ANCP = version/sub-version fields.  This defines the = version/sub-version=20 of

  =20 the ANCP protocol to be used while the adjacency protocol=20 remains

  =20 synchronised.  All other messages will use the agreed = version in=20 the

  =20 version/sub-version fields.=94

 

  1. I added a = non-normative=20 appendix. This appendix = will=20 contain a clarification of what version of the ANCP protocol = draft=20 specification constitutes version 3.1 as soon as the WG = decides on=20 3.1=20

=936. =20 Appendix: Handling of pre-RFC deployments of the ANCP =20 protocol

 

  =20 This appendix is non normative.

 

  =20 Prior to completion of this document, several pre-RFC versions = of=20 the

  =20 protocol were documented and implemented.  There were = numerous=20 pre-

  =20 standard versions of the protocol all using a=20 version/sub-version

  =20 fields set to 3.1.

 

  =20 A NAS implementing the ANCP protocol as defined in this = document=20 may,

  =20 on a peer basis, use the version and sub-version fields to = detect=20 a

  =20 pre-RFC implementation of the protocol and choose to work with = such

  =20 pre-RFC peers.  The version and sub-version negotiation = phase is=20 part

  =20 of the adjacency protocol and is performed before = synchronisation=20 is

  =20 achieved.=94

 

Please find=20 new version of draft attached.

I = hope I=92ve=20 captured most of your feedback in the new draft, if not or if = you have=20 additional comments please let me = know.

 

Best=20 Regards,

Roberta

 

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On=20 Behalf Of Wojciech Dec (wdec)
Sent: Wednesday, = October 14, 2009=20 1:07 PM
To: = ancp@ietf.org
Subject: [ANCP] FW: = ANCP=20 Versioning - next steps

 

 

Hi = All,

During the = ITEF75 WG=20 meeting a discussion was had on ANCP protocol versioning and = the need=20 to revise the protocol version. A follow-up e-mail discussion = on the=20 WG alias took place and it seems appropriate now (if not = overdue)=20 to draw up a set of recommendations and settle the=20 issue:

Recommended = protocol draft=20 changes and WG=20 actions=20

- The currently = used ANCP=20 version 3.1 is to change to 3.2 at the time of publishing as = an RFC.=20 An instruction to execute such a change should be placed as = part of an=20 editors' note in the next revision of = draft-ietf-ancp-protocol. This=20 instruction is expected to only come into effect at the time = of final=20 review past a WG last-call, which means that until then v3.1 = will be=20 in evidence. Current implementers should make a note of this=20 fact.

- Another note = (not=20 editorial though) should be placed in an appropriate section, = possibly=20 Section 2 or Section 5, to convey in-brief the historic aspect = of=20 GSMP/ANCP v3.1 implementations, which are (were?) based on = early=20 versions of the ANCP protocol draft. The note should be clear = in=20 offering no guarantees in terms of backwards compatibility of = the RFC=20 spec to those early-draft implementations. The note must also = not be=20 seen as passing a normative reference to the early protocol = draft.=20

- Along with the = above=20 note, the existing GSMP/ANCP version negotiation mechanisms = could be=20 highlighted, indicating that it provides a way to distinguish = between=20 the different versions if the adjacency establishment = negotiation=20 mechanism followed by all is as per GSMPv3=20 (rfc3292).

- For the sake = of clarity=20 it is recommended that the adjacency negotiation be more fully = described in the ANCP protocol draft instead of the current = reference=20 to rfc3292. Specifically, it would appear reasonable to adopt = and=20 re-edit Section 11.2 of rfc3292 into the ANCP protocol spec, = with the=20 re-edit describing the version negotiation behaviour. Rather=20 confusingly Rfc3292 Section 11.2 does not carry text or logic=20 statements as to the expected behaviour in case of version=20 differences, but such text is in evidence in the descriptive = part of=20 Section 11.1.

- = The WG=20 should identify what version of the ANCP protocol draft = specification=20 constitutes v3.1. A non-normative reference to such a = reference could=20 be passed in the v3.2 spec.

Rationale

From a technical = point of=20 view, given that a "current" (i.e.=20 draft-ietf-protocol-06 = based) and=20 future (i.e.=20 ANCP RFC = based) protocols=20 are identical, with any=20 newly added functions covered as=20 negotiable = capabilities,=20 the version change does=20 not appear to be fully warranted and = not fully in=20 line with the guidelines previously laid down = (= http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That said, = from an=20 operational = perspective a = reasonable=20 case for such=20 a version change = has=20 made based and = presented in=20 https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3= _document.htm.=20

Now,=20 given that = normative=20 compliance to an interim draft (such = as draft-ietf-protocol-06=20 based) = cannot be passed = by the=20 ANCP RFC, text which may=20 be perceived as = mandating=20 or claiming compatibility to such  interim drafts = needs to=20 be avoided.

In the case = of=20 vendors and = operators=20 that=20 already = support/use v3.1=20 and have plans for v3.2, the version negotiation mechanism = that ANCP=20 inherited from GSMPv3 provides a way to disambiguate the two = protocols=20 and thus=20 allows = in theory=20 for = supporting = running a=20 pre-standard (v3.1) and a standards compliant v3.2 on any = given ANCP=20 node. The = issue of where=20 v3.1 is documented can be solved by using non-normative = references to=20 one of the interim drafts. The issue of what rev of = draft-ietf-ancp is=20 considered to be v3.1 needs to be=20 clarified.

Other than the = above the=20 WG is currently not chartered to be extending = the=20 protocol spec to cover issues around protocol version = negotiation or=20 remediation of incompatibilities of draft = implementations. As such no such = work is=20 expected.

We = welcome=20 clarification questions on the above.=20

Regards,=20
Wojciech &=20 Matthew.=20

Questo = messaggio=20 e i suoi allegati sono indirizzati esclusivamente alle = persone=20 indicate. La diffusione, copia o qualsiasi altra azione=20 derivante dalla conoscenza di queste informazioni sono=20 rigorosamente vietate. Qualora abbiate ricevuto questo = documento=20 per errore siete cortesemente pregati di darne immediata = comunicazione al mittente e di provvedere alla sua = distruzione,=20 Grazie.

This=20 e-mail and any attachments is confidential=20 and may contain privileged information intended for the=20 addressee(s) only. Dissemination, copying, printing or = use by=20 anybody else is unauthorised. If you are not the = intended=20 recipient, please delete this message and any = attachments and=20 advise the sender by return e-mail, = Thanks.=20

3D"rispettaRispetta l'ambiente. Non stampare questa mail = se non =E8=20 necessario.=20 =

<= /BLOCKQUOTE>
------_=_NextPart_002_01CA5BC4.020DF632-- ------_=_NextPart_001_01CA5BC4.020DF632 Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: <685474713@02112009-2E4B> Content-Description: logo Ambiente_foglia.jpg Content-Location: logo%20Ambiente_foglia.jpg R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------_=_NextPart_001_01CA5BC4.020DF632-- From HaagT@telekom.de Mon Nov 2 07:09:59 2009 Return-Path: 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 0C96B3A680B for ; Mon, 2 Nov 2009 07:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.632 X-Spam-Level: X-Spam-Status: No, score=-0.632 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156] 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 iSQ8rvpG4nAZ for ; Mon, 2 Nov 2009 07:09:38 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 0E2483A65A6 for ; Mon, 2 Nov 2009 07:09:36 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 02 Nov 2009 16:09:28 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 16:09:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA5BCE.78A5B8D2" Date: Mon, 2 Nov 2009 16:09:27 +0100 Message-ID: <5661758E3E93364685B91DD8272F2876020B6785@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAA7n/FAACxIQTAAAdj3kACIEpIgAAjG22AAAS+RMA== References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local><5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> From: To: , , , , , , , , , , X-OriginalArrivalTime: 02 Nov 2009 15:09:28.0740 (UTC) FILETIME=[7925EE40:01CA5BCE] Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID 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: , X-List-Received-Date: Mon, 02 Nov 2009 15:09:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5BCE.78A5B8D2 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA5BCE.78A5B8D2" ------_=_NextPart_002_01CA5BCE.78A5B8D2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, =20 I'm really concerned about the way partition ID is beeing discussed now. = The use of partitioning is described in ANCP Framework - final version. Considering chapter 4.6.1 General Architecture, R-37,38,39,40 specifies = exactly requirements for partitioning which is naturally served by using = of an appropriate partition ID.=20 >From my understanding ANCP protocol draft must follow ANCP framework = requirements not having diverge work. =20 Derived from given descriptive text from ANCP framework it would be very = useful for introduction in chapter "partition ID": =20 Textproposal: "The Access Node Control Mechanism is defined to operate between an = Access Node (AN) and a NAS. In such a model, the physical AN needs to = be split in virtual ANs, each having its own Access Node Control reporting and/or enforcement function. A = partition ID is used for seperation of different partions in one = physical access node."=20 =20 =20 As agreed in San Francisco minutes the partition ID remains as protocol = field. I strongly insist on following that agreement and keeping this field in = protocol draft. =20 =20 Regards Thomas =20 _____ =20 Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Montag, 2. November 2009 14:54 An: Reith, Lothar; Haag, Thomas; roberta.maglione@telecomitalia.it; = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: RE: [ANCP] ANCP Versioning - next steps; partition ID Hi Lothar, =20 _____ =20 From: Reith, Lothar [mailto:Lothar.Reith@detecon.com]=20 Sent: 02 November 2009 10:39 To: Wojciech Dec (wdec); Haag, Thomas; = roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID =20 Hi Woj, =20 I am afraid that your proposal means that we should use "sender-name" = instead of "partition-ID" to identify an AN partition. =20 Known implementations use "sender-name" to convey either the management = name of the AN (and the NAS/Controller respectively) or a MAC address as = GSMPv3 describes. =20 Woj> The choice of what goes into the sender-name is rather arbitrary; = having a name + partition-id is pretty much as the same as having a name = with partition-id. Furthermore, we're now at v3.2 of ANCP... =20 So for two reasons it is not possible to use "sender name" instead of = "partition ID": =20 1. The associated functionality to verify if one is talking to the = proper (intended) AN (or NAS/Controller respectively)=20 would be lost if when using the sender-id to convey the partition-ID = instead of the management name of the device.=20 =20 Woj> How so? The name is an opaque value that has significance to the = operator, very much like partition-id. =20 2. If a MAC address information in "sender name" would be used for = "partition ID" only one partition can be used because usually a AN uses = one MAC address. So we have a conflict on networking because usually an = access node use one MAC Adresse regardles of partitioning. =20 =20 Woj> Please note that GSMP recommended the use of MAC addresses because = it was meant to run on TCP/IP. In ANCP , you can identify each AN with = the IP address and the sender-name is pretty much redudnant today. = However it appears it could well be used for the use-case you described. =20 For that reasons I don't want to effectively abandon the partition-ID. I = highly recommend keeping the conventions (75th meeting minutes) for = partition ID as I understand they are meant to keep network scenarios = clean and avoid the mixing up of different layer informations.=20 =20 Woj> The existing "conventions" amount to partition-id beingthere, like = other GSMP fields, but its use is not currently specified in ANCP. =20 Regards, Woj.=20 =20 Best Regards, =20 Lothar Reith Detecon International GmbH (Deutsche Telekom Group) _____ =20 Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Freitag, 30. Oktober 2009 18:19 An: Reith, Lothar; Haag, Thomas; roberta.maglione@telecomitalia.it; = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: RE: [ANCP] ANCP Versioning - next steps; partition ID Hi Lothar, =20 Having the NAS/controller verify the sender-name (as is done today), = with each partition using a different sender name, would accomplish the = use-case below, without partition-id. Any problem with this? =20 Thanks, Woj. =20 _____ =20 From: Reith, Lothar [mailto:Lothar.Reith@detecon.com]=20 Sent: 30 October 2009 17:17 To: Wojciech Dec (wdec); Haag, Thomas; = roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID Hi Woj, dear all, =20 I fully support Thomas Haag`s point in his mail. =20 I also noticed that the following section is no longer present in the = current version, and propose to re-include: =20 Partition ID: This field is a 8 bit number which signifies a partition on the AN. [ TBD How AN and NAS agree on the partition numbers. Possible options: 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; 2 - The partition ID could be statically configured on the NAS as part of configuring the neighbor information.] =20 =20 I further suggest to enhance the text as follows: =20 Partition ID: This field is a 8 bit number which signifies a partition on the AN. AN and NAS MAY agree on the partition ID using one of the = following possible options: 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; 2 - The partition ID could be statically configured on the NAS as part of configuring the neighbor information. =20 =20 A potential use case could be in assurance, e.g. to enable verification = that the proper (intended) partition ID is used over a particular = adjacency in cases where the AN has multiple adjacencies to different = NAS/Controller.=20 =20 Best Regards, Lothar Reith =20 Detecon International GmbH (Deutsche Telekom Group) _____ =20 Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von = Wojciech Dec (wdec) Gesendet: Donnerstag, 29. Oktober 2009 19:45 An: Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: Re: [ANCP] ANCP Versioning - next steps; partition ID While keeping the GSMP derived partition-id in the protocol spec "as is" = is fine, a note should perhaps also be inserted stating that this field = is effectively not currently used by ANCP. At least this is my = recollection of the discussion on this matter, ie partition-id is fine, = but we don't really have a use for it now given that functional = partitioning is not covered and that an AN will have 1 adjacency to each = NAS/controller. =20 -Woj. _____ =20 From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 28 October 2009 15:52 To: roberta.maglione@telecomitalia.it; Wojciech Dec (wdec); = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID Hi Roberta, all, =20 thanks for providing the updated protocol draft. =20 So far I recognized that the update covers issues regarding versioning, = tech Type for GPON and Range of values of the code field. =20 But I notice on page 17 of version 07 that the whole section of = partition ID including definition is deleted. >From my understanding (and as result from the minutes) it was agreed = during 75th IETF meeting to keep the partition ID. =20 Extract from 75th IETF minutes:=20 =20 (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces extensibility. Thomas Haag: need multiple partition-ids because one might need to = distinguish=20 between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational problems=20 if partition-id not available.=20 No one felt strongly -- will keep "as is". =20 So we had consensus not to remove and keep partion ID. But I didn't find = it in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are there = any reasons for doing this? =20 So I recommend update the protocol draft before upcoming meeting keeping = partition ID. =20 Regards =20 Thomas .=20 =20 _____ =20 Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps Hi All, I updated the ancp protocol draft following the chairs' = recommendations on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the end of = section 2:=20 "At the time of writing of this specification some implementations of = the ANCP protocol, based on pre-standards drafts are already available. = All these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] Adopting a new sub-version value provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP implementation on any given ANCP node. The mechanism used to identify the protocol version/sub-version is part of the adjacency negotiation process and it is described in details in Section 5.2. It is important to note that this mechanism does not guarantee backwards compatibility of the ANCP RFC specification to those early-draft implementations." 2. I explained the version/sub-version negotiation process in section = 5.2:=20 "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the highest version understood by the sender. A receiver receiving a SYN message with a version/sub-version higher than understood will ignore that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP = version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in the version/sub-version fields." =20 3. I added a non-normative appendix. This appendix will contain a = clarification of what version of the ANCP protocol draft specification = constitutes version 3.1 as soon as the WG decides on 3.1=20 "6. Appendix: Handling of pre-RFC deployments of the ANCP protocol =20 This appendix is non normative. =20 Prior to completion of this document, several pre-RFC versions of the protocol were documented and implemented. There were numerous pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document may, on a peer basis, use the version and sub-version fields to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers. The version and sub-version negotiation phase is part of the adjacency protocol and is performed before synchronisation is achieved." =20 Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not or = if you have additional comments please let me know. =20 Best Regards, Roberta =20 _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps =20 =20 Hi All,=20 During the ITEF75 WG meeting a discussion was had on ANCP protocol = versioning and the need to revise the protocol version. A follow-up = e-mail discussion on the WG alias took place and it seems appropriate = now (if not overdue) to draw up a set of recommendations and settle the = issue: Recommended protocol draft changes and WG actions=20 - The currently used ANCP version 3.1 is to change to 3.2 at the time of = publishing as an RFC. An instruction to execute such a change should be = placed as part of an editors' note in the next revision of = draft-ietf-ancp-protocol. This instruction is expected to only come into = effect at the time of final review past a WG last-call, which means that = until then v3.1 will be in evidence. Current implementers should make a = note of this fact. - Another note (not editorial though) should be placed in an appropriate = section, possibly Section 2 or Section 5, to convey in-brief the = historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) = based on early versions of the ANCP protocol draft. The note should be = clear in offering no guarantees in terms of backwards compatibility of = the RFC spec to those early-draft implementations. The note must also = not be seen as passing a normative reference to the early protocol = draft.=20 - Along with the above note, the existing GSMP/ANCP version negotiation = mechanisms could be highlighted, indicating that it provides a way to = distinguish between the different versions if the adjacency = establishment negotiation mechanism followed by all is as per GSMPv3 = (rfc3292). - For the sake of clarity it is recommended that the adjacency = negotiation be more fully described in the ANCP protocol draft instead = of the current reference to rfc3292. Specifically, it would appear = reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP = protocol spec, with the re-edit describing the version negotiation = behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic statements as to the expected behaviour in case of version = differences, but such text is in evidence in the descriptive part of = Section 11.1. - The WG should identify what version of the ANCP protocol draft = specification constitutes v3.1. A non-normative reference to such a = reference could be passed in the v3.2 spec. Rationale=20 >From a technical point of view, given that a "current" (i.e. = draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols = are identical, with any newly added functions covered as negotiable = capabilities, the version change does not appear to be fully warranted = and not fully in line with the guidelines previously laid down ( = = http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That = said, from an operational perspective a reasonable case for such a = version change has made based and presented in = = https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docume= nt.htm.=20 Now, given that normative compliance to an interim draft (such as = draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text = which may be perceived as mandating or claiming compatibility to such = interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 and = have plans for v3.2, the version negotiation mechanism that ANCP = inherited from GSMPv3 provides a way to disambiguate the two protocols = and thus allows in theory for supporting running a pre-standard (v3.1) = and a standards compliant v3.2 on any given ANCP node. The issue of = where v3.1 is documented can be solved by using non-normative references = to one of the interim drafts. The issue of what rev of draft-ietf-ancp = is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be extending = the protocol spec to cover issues around protocol version negotiation or = remediation of incompatibilities of draft implementations. As such no = such work is expected. We welcome clarification questions on the above.=20 Regards,=20 Wojciech & Matthew.=20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non = =E8 necessario.=20 ------_=_NextPart_002_01CA5BCE.78A5B8D2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: ANCP Versioning - next steps
All,
 
I'm really concerned about the way partition = ID is=20 beeing discussed now.
The use of partitioning is described in ANCP = Framework=20 - final version.
Considering chapter 4.6.1 General = Architecture,=20 R-37,38,39,40 specifies exactly requirements for partitioning which is = naturally=20 served by using of an appropriate partition ID.
From my = understanding ANCP protocol=20 draft must follow ANCP framework requirements not = having = diverge=20 work.
 
Derived from given descriptive text from ANCP = framework=20 it would be very useful for introduction in chapter "partition=20 ID":
 
Textproposal:
 "The Access Node Control Mechanism is = defined to=20 operate between an Access Node (AN) and a NAS.  In such a model, = the=20 physical AN needs to be split in virtual ANs, each = having
   its=20 own Access Node Control reporting and/or enforcement function.=20 A partition ID is used for seperation = of different=20 partions in one physical access node."
 
 
As agreed in San Francisco = minutes the=20 partition ID remains as protocol field.
I strongly insist on following that agreement = and keeping this field in protocol draft.
 
 
Regards
Thomas
 

Von: Wojciech Dec (wdec) = [mailto:wdec@cisco.com]=20
Gesendet: Montag, 2. November 2009 14:54
An: Reith, = Lothar;=20 Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, = Manuel;=20 Witschurke, Birgit
Betreff: RE: [ANCP] ANCP Versioning - next = steps;=20 partition ID

Hi Lothar,
 
From: Reith, Lothar=20 [mailto:Lothar.Reith@detecon.com]
Sent: 02 November 2009=20 10:39
To: Wojciech Dec (wdec); Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, = Manuel;=20 Witschurke, Birgit
Subject: AW: [ANCP] ANCP Versioning - next = steps;=20 partition ID

 
Hi Woj,
 
I am afraid that your proposal means that = we=20 should use =20 "sender-name" instead=20 of "partition-ID" to = identify an AN=20 partition.
 
Known=20 implementations use  "sender-name" to convey either the management name of the AN = (and the=20 NAS/Controller respectively) or a MAC = address=20 as GSMPv3 describes.
 
Woj> = The choice of=20 what goes into the sender-name is rather arbitrary; having a name +=20 partition-id is pretty much as the same as having a name with=20 partition-id.
Furthermore, we're now=20 at v3.2 of ANCP...
 
So for two = reasons it=20 is not possible to use "sender name" instead of "partition=20 ID":
 
1.=20 The associated functionality to verify if = one is=20 talking to the proper (intended) AN (or NAS/Controller=20 respectively) 
    would be = lost=20 if when using the sender-id to convey the partition-ID = instead of=20 the management name of the device. 
 
Woj> = How so? The=20 name is an opaque value that has significance to the operator, very = much like=20 partition-id.

 
2. If a MAC address information in "sender name" = would be=20 used for "partition ID" only one partition can be used because usually = a AN=20 uses one MAC address. So we have a conflict on networking because = usually an=20 access node use one MAC Adresse regardles of partitioning.  
&nbs= p;
Woj> Please note=20 that GSMP recommended the use of MAC addresses because it was meant to = run on=20 TCP/IP. In ANCP , you can identify each=20 AN with the IP address and the sender-name is pretty much redudnant = today.=20 However it appears it could well be used for the use-case you=20 described.
 
For=20 that reasons I don't want to effectively abandon the = partition-ID. I highly recommend keeping the = conventions (75th=20 meeting minutes) for partition ID as I understand they are meant to keep network scenarios=20 clean and avoid the = mixing=20 up of different layer=20 informations. 
 
Woj> The=20 existing "conventions" amount to partition-id beingthere, = like other=20 GSMP fields, but its use is not currently specified in=20 ANCP.
 
Regards,=
Woj. 
&nbs= p;
Best=20 Regards,
&nbs= p;
Lothar=20 Reith
Detecon International GmbH (Deutsche = Telekom=20 = Group)
=
Von: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Gesendet: Freitag, 30. Oktober = 2009=20 18:19
An: Reith, Lothar; Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke, = Birgit
Betreff:=20 RE: [ANCP] ANCP Versioning - next steps; partition = ID

Hi Lothar,
 
Having the NAS/controller verify the sender-name (as is = done today),=20 with each partition using a different sender name, would = accomplish the=20 use-case below, without partition-id. Any problem with=20 this?
 
Thanks,
Woj.
 

From: Reith, Lothar=20 [mailto:Lothar.Reith@detecon.com]
Sent: 30 October 2009 = 17:17
To: Wojciech Dec (wdec); Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke,=20 Birgit
Subject: AW: [ANCP] ANCP Versioning - next steps; = partition ID

Hi = Woj, dear=20 all,
 
I fully support Thomas Haag`s point in = his=20 mail.
 
I also noticed that the following section = is no=20 longer present in the current version, and propose to=20 re-include:
 
Partition=20 ID:

      This field is a 8 bit = number=20 which signifies a partition on = the
      AN. [=20 TBD How AN and NAS agree on the partition numbers. =20 Possible
     =20 options:

      1 - The partition = ID could=20 be configured on the AN and learnt = by
     =20 NAS in the adjacency = message;

      2 -=20 The partition ID could be statically configured on the NAS=20 as
      part of configuring the = neighbor=20 information.]
 
 
I further suggest to enhance the text = as=20 follows:
 
Partition=20 ID:

      This field is a 8 bit = number=20 which signifies a partition on = the
     =20 AN.  AN and NAS MAY agree on the partition ID using one of = the=20 following possible
     =20 options:

      1 - The partition = ID could=20 be configured on the AN and learnt = by
     =20 NAS in the adjacency = message;

      2 -=20 The partition ID could be statically configured on the NAS=20 as
      part of configuring the = neighbor=20 information.
 
 
A potential use case could be in = assurance,=20 e.g. to enable verification that the proper = (intended) partition=20 ID is used over a particular adjacency in cases where = the AN has=20 multiple adjacencies to different=20 NAS/Controller. 
 
 Best Regards, Lothar=20 Reith
 
Detecon International GmbH (Deutsche = Telekom=20 Group)

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech = Dec=20 (wdec)
Gesendet: Donnerstag, 29. Oktober 2009=20 19:45
An: Haag, Thomas; = roberta.maglione@telecomitalia.it;=20 ancp@ietf.org; alan.kavanagh@ericsson.com; = Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke,=20 Birgit
Betreff: Re: [ANCP] ANCP Versioning - next = steps;=20 partition ID

While keeping the GSMP derived partition-id in the = protocol=20 spec "as is" is fine, a note should perhaps also be inserted = stating=20 that this field is effectively not currently used by ANCP. At = least this=20 is my recollection of the discussion on this matter, ie = partition-id is=20 fine, but we don't really have a use for it now given that = functional=20 partitioning is not covered and that an AN will have 1 adjacency = to each=20 NAS/controller.
 
-Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 28 October 2009=20 15:52
To: roberta.maglione@telecomitalia.it; = Wojciech Dec=20 (wdec); ancp@ietf.org; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net;=20 Manuel.Paul@telekom.de; = B.Witschurke@telekom.de
Subject: AW:=20 ANCP Versioning - next steps; partition = ID

Hi Roberta, = all,
 
thanks for providing the = updated=20 protocol draft.
 
So far I recognized that = the update=20 covers issues regarding versioning, tech Type for GPON and = Range of=20 values of the code field.
 
But I notice on page 17 = of version 07=20 that the whole section of partition ID including definition is = deleted.
From my understanding = (and as=20 result from the minutes) it was agreed during 75th IETF = meeting=20 to keep the partition ID.
 
Extract from 75th = IETF minutes:=20
 
(1)=20 Partition-id
    ------------
Sanjay: = concerned=20 that removing the partition-id reduces = extensibility.
Thomas Haag:=20 need multiple partition-ids because one might need to = distinguish=20
between BRASs when expanding the network.
Woj: send = e-mail.=20 Thomas: already did. Makes for operational problems
if=20 partition-id not available.
No one felt strongly -- will = keep "as=20 is".
 
So we had consensus = not to remove=20 and keep partion ID. But I didn't find it in the whole = document any=20 more.
Based on that agreements I wonder why this issue is=20 deleted. Are there any = reasons for=20 doing this?
 
So I recommend update = the protocol=20 draft before upcoming meeting keeping partition=20 ID.
 
Regards
 
Thomas
.
 

Von: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it] =
Gesendet:=20 Montag, 19. Oktober 2009 16:16
An: 'Wojciech Dec = (wdec)';=20 ancp@ietf.org; Haag, Thomas; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net; BOCCI = Matthew;=20 'tom111.taylor@bell.net'
Betreff: RE: ANCP = Versioning - next=20 steps

Hi=20 All,

    =20 I updated the ancp protocol draft following the chairs’=20 recommendations on the ANCP = versioning.

In=20 particular:

  1. I added some = text to=20 explain the history and rationale, at the end of section=20 2:

 “At=20 the time of writing of this specification some implementations = of the=20 ANCP protocol, based on pre-standards drafts are already=20 available.  All these early-draft implementations use=20 protocol

  =20 version/sub-version 3.1; standard ANCP protocol will use=20 version/

  =20 sub-version 3.2 [Editor's note: sub-version needs to be = changed=20 from

  =20 1 to 2 upon publication.]  Adopting a new sub-version = value=20 provides

  =20 a way to disambiguate the two protocols and allows for=20 supporting

  =20 running a pre-standard and a standards compliant ANCP=20 implementation

  =20 on any given ANCP node.  The mechanism used to identify = the=20 protocol

  =20 version/sub-version is part of the adjacency negotiation = process=20 and

  =20 it is described in details in Section 5.2.  It is = important to=20 note

  =20 that this mechanism does not guarantee backwards compatibility = of=20 the

  =20 ANCP RFC specification to those early-draft=20 implementations.”

  1. I explained = the=20 version/sub-version negotiation process in section=20 5.2:=20

“ANCP=20 uses version 3 and sub-version 1 of GSMP=20 protocol.

  =20 [RFC Editor's note: sub-version needs to be changed from 1 to = 2=20 upon

  =20 publication.]  In the adjacency protocol the version and = the=20 sub-

  =20 version fields are used for version negotiation.  The=20 version

  =20 negotiation is performed before synchronisation is = achieved.  In=20 a

  =20 SYN message the version/sub-version fields always contain the=20 highest

  =20 version understood by the sender.  A receiver receiving a = SYN=20 message

  =20 with a version/sub-version higher than understood will ignore=20 that

  =20 message.  A receiver receiving a SYN message with a=20 version/

  =20 sub-vresion lower than its own highest version/sub-version, = but=20 a

  =20 version/sub-version that it understands, will reply with a=20 SYNACK

  =20 with the version/sub-version from the received SYN in its ANCP = version/sub-version fields.  This defines the = version/sub-version=20 of

  =20 the ANCP protocol to be used while the adjacency protocol=20 remains

  =20 synchronised.  All other messages will use the agreed = version in=20 the

  =20 version/sub-version fields.”

 

  1. I added a = non-normative=20 appendix. This appendix = will=20 contain a clarification of what version of the ANCP protocol = draft=20 specification constitutes version 3.1 as soon as the WG = decides on=20 3.1=20

“6. =20 Appendix: Handling of pre-RFC deployments of the ANCP =20 protocol

 

  =20 This appendix is non normative.

 

  =20 Prior to completion of this document, several pre-RFC versions = of=20 the

  =20 protocol were documented and implemented.  There were = numerous=20 pre-

  =20 standard versions of the protocol all using a=20 version/sub-version

  =20 fields set to 3.1.

 

  =20 A NAS implementing the ANCP protocol as defined in this = document=20 may,

  =20 on a peer basis, use the version and sub-version fields to = detect=20 a

  =20 pre-RFC implementation of the protocol and choose to work with = such

  =20 pre-RFC peers.  The version and sub-version negotiation = phase is=20 part

  =20 of the adjacency protocol and is performed before = synchronisation=20 is

  =20 achieved.”

 

Please find=20 new version of draft attached.

I = hope I’ve=20 captured most of your feedback in the new draft, if not or if = you have=20 additional comments please let me = know.

 

Best=20 Regards,

Roberta

 

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On=20 Behalf Of Wojciech Dec (wdec)
Sent: Wednesday, = October 14, 2009=20 1:07 PM
To: = ancp@ietf.org
Subject: [ANCP] FW: = ANCP=20 Versioning - next steps

 

 

Hi = All,

During the = ITEF75 WG=20 meeting a discussion was had on ANCP protocol versioning and = the need=20 to revise the protocol version. A follow-up e-mail discussion = on the=20 WG alias took place and it seems appropriate now (if not = overdue)=20 to draw up a set of recommendations and settle the=20 issue:

Recommended = protocol draft=20 changes and WG=20 actions=20

- The currently = used ANCP=20 version 3.1 is to change to 3.2 at the time of publishing as = an RFC.=20 An instruction to execute such a change should be placed as = part of an=20 editors' note in the next revision of = draft-ietf-ancp-protocol. This=20 instruction is expected to only come into effect at the time = of final=20 review past a WG last-call, which means that until then v3.1 = will be=20 in evidence. Current implementers should make a note of this=20 fact.

- Another note = (not=20 editorial though) should be placed in an appropriate section, = possibly=20 Section 2 or Section 5, to convey in-brief the historic aspect = of=20 GSMP/ANCP v3.1 implementations, which are (were?) based on = early=20 versions of the ANCP protocol draft. The note should be clear = in=20 offering no guarantees in terms of backwards compatibility of = the RFC=20 spec to those early-draft implementations. The note must also = not be=20 seen as passing a normative reference to the early protocol = draft.=20

- Along with the = above=20 note, the existing GSMP/ANCP version negotiation mechanisms = could be=20 highlighted, indicating that it provides a way to distinguish = between=20 the different versions if the adjacency establishment = negotiation=20 mechanism followed by all is as per GSMPv3=20 (rfc3292).

- For the sake = of clarity=20 it is recommended that the adjacency negotiation be more fully = described in the ANCP protocol draft instead of the current = reference=20 to rfc3292. Specifically, it would appear reasonable to adopt = and=20 re-edit Section 11.2 of rfc3292 into the ANCP protocol spec, = with the=20 re-edit describing the version negotiation behaviour. Rather=20 confusingly Rfc3292 Section 11.2 does not carry text or logic=20 statements as to the expected behaviour in case of version=20 differences, but such text is in evidence in the descriptive = part of=20 Section 11.1.

- = The WG=20 should identify what version of the ANCP protocol draft = specification=20 constitutes v3.1. A non-normative reference to such a = reference could=20 be passed in the v3.2 spec.

Rationale

From a technical = point of=20 view, given that a "current" (i.e.=20 draft-ietf-protocol-06 = based) and=20 future (i.e.=20 ANCP RFC = based) protocols=20 are identical, with any=20 newly added functions covered as=20 negotiable = capabilities,=20 the version change does=20 not appear to be fully warranted and = not fully in=20 line with the guidelines previously laid down = (= http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That said, = from an=20 operational = perspective a = reasonable=20 case for such=20 a version change = has=20 made based and = presented in=20 https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3= _document.htm.=20

Now,=20 given that = normative=20 compliance to an interim draft (such = as draft-ietf-protocol-06=20 based) = cannot be passed = by the=20 ANCP RFC, text which may=20 be perceived as = mandating=20 or claiming compatibility to such  interim drafts = needs to=20 be avoided.

In the case = of=20 vendors and = operators=20 that=20 already = support/use v3.1=20 and have plans for v3.2, the version negotiation mechanism = that ANCP=20 inherited from GSMPv3 provides a way to disambiguate the two = protocols=20 and thus=20 allows = in theory=20 for = supporting = running a=20 pre-standard (v3.1) and a standards compliant v3.2 on any = given ANCP=20 node. The = issue of where=20 v3.1 is documented can be solved by using non-normative = references to=20 one of the interim drafts. The issue of what rev of = draft-ietf-ancp is=20 considered to be v3.1 needs to be=20 clarified.

Other than the = above the=20 WG is currently not chartered to be extending = the=20 protocol spec to cover issues around protocol version = negotiation or=20 remediation of incompatibilities of draft = implementations. As such no such = work is=20 expected.

We = welcome=20 clarification questions on the above.=20

Regards,=20
Wojciech &=20 Matthew.=20

Questo = messaggio=20 e i suoi allegati sono indirizzati esclusivamente alle = persone=20 indicate. La diffusione, copia o qualsiasi altra azione=20 derivante dalla conoscenza di queste informazioni sono=20 rigorosamente vietate. Qualora abbiate ricevuto questo = documento=20 per errore siete cortesemente pregati di darne immediata = comunicazione al mittente e di provvedere alla sua = distruzione,=20 Grazie.

This=20 e-mail and any attachments is confidential=20 and may contain privileged information intended for the=20 addressee(s) only. Dissemination, copying, printing or = use by=20 anybody else is unauthorised. If you are not the = intended=20 recipient, please delete this message and any = attachments and=20 advise the sender by return e-mail, = Thanks.=20

3D"rispettaRispetta l'ambiente. Non stampare questa mail = se non =E8=20 necessario.=20 =

<= /BLOCKQUOTE>
------_=_NextPart_002_01CA5BCE.78A5B8D2-- ------_=_NextPart_001_01CA5BCE.78A5B8D2 Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: <679442114@02112009-2CFC> Content-Description: logo Ambiente_foglia.jpg Content-Location: logo%20Ambiente_foglia.jpg R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------_=_NextPart_001_01CA5BCE.78A5B8D2-- From roberta.maglione@telecomitalia.it Mon Nov 2 16:18:15 2009 Return-Path: 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 243413A693A for ; Mon, 2 Nov 2009 16:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.733 X-Spam-Level: X-Spam-Status: No, score=0.733 tagged_above=-999 required=5 tests=[AWL=1.452, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 BjOZHOxjruOD for ; Mon, 2 Nov 2009 16:18:14 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 179E33A6847 for ; Mon, 2 Nov 2009 16:18:14 -0800 (PST) Received: from grfhub705ba020.griffon.local (10.188.101.118) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 3 Nov 2009 01:18:32 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub705ba020.griffon.local ([10.188.101.118]) with mapi; Tue, 3 Nov 2009 01:18:31 +0100 From: Maglione Roberta To: "Wojciech Dec (wdec)" , "ancp@ietf.org" Date: Tue, 3 Nov 2009 01:17:03 +0100 Thread-Topic: [ANCP] Agenda items for IETF76 ANCP WG meeting Thread-Index: Acn+6ltl92lm+d4MS0WQoGhkOfvVhRMJzVNgA59idbAAovdRzw== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3E686D3047@GRFMBX704BA020.griffon.local> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ANCP] Agenda items for IETF76 ANCP WG meeting 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: , X-List-Received-Date: Tue, 03 Nov 2009 00:18:15 -0000 Hi Woj, I sent you a request to present a new version of ancp protocol draft so= me weeks ago. Could you please allocate a time slot for me? Thanks, Regards, Roberta ________________________________________ From: ancp-bounces@ietf.org [ancp-bounces@ietf.org] On Behalf Of Wojciech D= ec (wdec) [wdec@cisco.com] Sent: Friday, October 30, 2009 7:33 PM To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] Agenda items for IETF76 ANCP WG meeting Hi All, So far the agenda looks as follows: - TR-147 gaps ; Hongyu Li - ANCP Restart ; Shridhar Rao - ancp-mc-extensions ; Francois Le Faucheur Did we miss anyone's request? Thanks, Woj. > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On > Behalf Of Wojciech Dec (wdec) > Sent: 12 October 2009 09:58 > To: ancp@ietf.org > Subject: [ANCP] Agenda items for IETF76 ANCP WG meeting > > Hi All, > > > We're taking requests for agenda slots at our next ANCP WG > meeting in Hiroshima. Please respond with any requests. > > Thanks, > Matthew & Woj > > _______________________________________________ > 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From wdec@cisco.com Tue Nov 3 03:50:52 2009 Return-Path: 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 AEAAC28C185 for ; Tue, 3 Nov 2009 03:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.655 X-Spam-Level: X-Spam-Status: No, score=-9.655 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 n4D5WEL-zF0q for ; Tue, 3 Nov 2009 03:50:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6C5BE28C172 for ; Tue, 3 Nov 2009 03:50:51 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcAAGuo70qQ/uCWe2dsb2JhbACbVQEBCwskBqoJl2aEPQSBZA X-IronPort-AV: E=Sophos;i="4.44,673,1249257600"; d="scan'208";a="53487511" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2009 11:51:11 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3BpB9Y024049; Tue, 3 Nov 2009 11:51:11 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 12:51:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2009 12:51:10 +0100 Message-ID: In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3E686D3047@GRFMBX704BA020.griffon.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Agenda items for IETF76 ANCP WG meeting Thread-Index: Acn+6ltl92lm+d4MS0WQoGhkOfvVhRMJzVNgA59idbAAovdRzwAXp5wg References: , <282BBE8A501E1F4DA9C775F964BB21FE3E686D3047@GRFMBX704BA020.griffon.local> From: "Wojciech Dec (wdec)" To: "Maglione Roberta" , X-OriginalArrivalTime: 03 Nov 2009 11:51:11.0140 (UTC) FILETIME=[F009FE40:01CA5C7B] Subject: Re: [ANCP] Agenda items for IETF76 ANCP WG meeting 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: , X-List-Received-Date: Tue, 03 Nov 2009 11:50:52 -0000 Hi Roberta, Confirmed. Apologies for the oversight. Thanks, Woj. > -----Original Message----- > From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 > Sent: 03 November 2009 01:17 > To: Wojciech Dec (wdec); ancp@ietf.org > Subject: RE: [ANCP] Agenda items for IETF76 ANCP WG meeting >=20 > Hi Woj, > I sent you a request to present a new version of ancp=20 > protocol draft some weeks ago. > Could you please allocate a time slot for me? > Thanks, > Regards, > Roberta > ________________________________________ > From: ancp-bounces@ietf.org [ancp-bounces@ietf.org] On Behalf=20 > Of Wojciech Dec (wdec) [wdec@cisco.com] > Sent: Friday, October 30, 2009 7:33 PM > To: Wojciech Dec (wdec); ancp@ietf.org > Subject: Re: [ANCP] Agenda items for IETF76 ANCP WG meeting >=20 > Hi All, >=20 > So far the agenda looks as follows: >=20 > - TR-147 gaps ; Hongyu Li > - ANCP Restart ; Shridhar Rao > - ancp-mc-extensions ; Francois Le Faucheur >=20 > Did we miss anyone's request? >=20 > Thanks, > Woj. >=20 >=20 > > -----Original Message----- > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org]=20 > On Behalf=20 > > Of Wojciech Dec (wdec) > > Sent: 12 October 2009 09:58 > > To: ancp@ietf.org > > Subject: [ANCP] Agenda items for IETF76 ANCP WG meeting > > > > Hi All, > > > > > > We're taking requests for agenda slots at our next ANCP WG=20 > meeting in=20 > > Hiroshima. Please respond with any requests. > > > > Thanks, > > Matthew & Woj > > > > _______________________________________________ > > 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 >=20 > Questo messaggio e i suoi allegati sono indirizzati=20 > esclusivamente alle persone indicate. La diffusione, copia o=20 > qualsiasi altra azione derivante dalla conoscenza di queste=20 > informazioni sono rigorosamente vietate. Qualora abbiate=20 > ricevuto questo documento per errore siete cortesemente=20 > pregati di darne immediata comunicazione al mittente e di=20 > provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may=20 > contain privileged information intended for the addressee(s)=20 > only. Dissemination, copying, printing or use by anybody else=20 > is unauthorised. If you are not the intended recipient,=20 > please delete this message and any attachments and advise the=20 > sender by return e-mail, Thanks. >=20 >=20 From wdec@cisco.com Tue Nov 3 03:51:04 2009 Return-Path: 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 E1B1728C188 for ; Tue, 3 Nov 2009 03:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.425 X-Spam-Level: X-Spam-Status: No, score=-8.425 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156] 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 uP7kSaGLFZT4 for ; Tue, 3 Nov 2009 03:51:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C543428C14E for ; Tue, 3 Nov 2009 03:50:58 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo Ambiente_foglia.jpg : 677 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkAAGuo70qQ/uCWe2dsb2JhbACCJywhhFU2k1YBAQsLJAaqCYkajkyCOA+BdgSBZIoq X-IronPort-AV: E=Sophos;i="4.44,673,1249257600"; d="jpg'147?scan'147,208,217,147";a="53487525" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2009 11:51:17 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3BpH1b024076; Tue, 3 Nov 2009 11:51:17 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 12:51:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA5C7B.F365D3A8" Date: Tue, 3 Nov 2009 12:49:41 +0100 Message-ID: In-Reply-To: <5661758E3E93364685B91DD8272F2876020B6785@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAA7n/FAACxIQTAAAdj3kACIEpIgAAjG22AAAS+RMAAsglTg References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local><5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> <5661758E3E93364685B91DD8272F2876020B6785@S4DE8PSAAQC.mitte.t-com.de> From: "Wojciech Dec (wdec)" To: , , , , , , , , , , X-OriginalArrivalTime: 03 Nov 2009 11:51:17.0593 (UTC) FILETIME=[F3E2A490:01CA5C7B] Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID 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: , X-List-Received-Date: Tue, 03 Nov 2009 11:51:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5C7B.F365D3A8 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA5C7B.F365D3A8" ------_=_NextPart_002_01CA5C7B.F365D3A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas, =20 the framework is an informative document whose purpose is (was) used to = help the WG steer at a high level the protocol design. Previous = discussions have not revealed that a partition-id is needed, hence the = "legacy status" of the partition field. It's perhaps also worth noting = that current implementations largely do not support it.=20 The latest discussion about the use-case from Lothar is a new one (and = the use-case is not part of the framework), which is welcome to = continue. As discussed so far, there appears to be another way for = realizing this use-case, which does not require any new functionality. = More opinions along with reasons are welcome. =20 Thanks, Woj. ________________________________ From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 02 November 2009 16:09 To: Wojciech Dec (wdec); Lothar.Reith@detecon.com; = roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 All, =20 I'm really concerned about the way partition ID is beeing discussed = now.=20 The use of partitioning is described in ANCP Framework - final version. Considering chapter 4.6.1 General Architecture, R-37,38,39,40 specifies = exactly requirements for partitioning which is naturally served by using = of an appropriate partition ID.=20 From my understanding ANCP protocol draft must follow ANCP framework = requirements not having diverge work. =20 Derived from given descriptive text from ANCP framework it would be = very useful for introduction in chapter "partition ID": =20 Textproposal: "The Access Node Control Mechanism is defined to operate between an = Access Node (AN) and a NAS. In such a model, the physical AN needs to = be split in virtual ANs, each having its own Access Node Control reporting and/or enforcement function. A = partition ID is used for seperation of different partions in one = physical access node."=20 =20 =20 As agreed in San Francisco minutes the partition ID remains as protocol = field. I strongly insist on following that agreement and keeping this field in = protocol draft. =20 =20 Regards Thomas =20 ________________________________ Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Montag, 2. November 2009 14:54 An: Reith, Lothar; Haag, Thomas; roberta.maglione@telecomitalia.it; = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: RE: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 Hi Lothar, =20 ________________________________ From: Reith, Lothar [mailto:Lothar.Reith@detecon.com]=20 Sent: 02 November 2009 10:39 To: Wojciech Dec (wdec); Haag, Thomas; = roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 =20 =09 Hi Woj, =20 I am afraid that your proposal means that we should use "sender-name" = instead of "partition-ID" to identify an AN partition. =20 Known implementations use "sender-name" to convey either the = management name of the AN (and the NAS/Controller respectively) or a MAC = address as GSMPv3 describes. =20 Woj> The choice of what goes into the sender-name is rather arbitrary; = having a name + partition-id is pretty much as the same as having a name = with partition-id. Furthermore, we're now at v3.2 of ANCP... =20 So for two reasons it is not possible to use "sender name" instead of = "partition ID": =20 1. The associated functionality to verify if one is talking to the = proper (intended) AN (or NAS/Controller respectively)=20 would be lost if when using the sender-id to convey the = partition-ID instead of the management name of the device.=20 =20 Woj> How so? The name is an opaque value that has significance to the = operator, very much like partition-id. =09 =20 2. If a MAC address information in "sender name" would be used for = "partition ID" only one partition can be used because usually a AN uses = one MAC address. So we have a conflict on networking because usually an = access node use one MAC Adresse regardles of partitioning. =20 =20 Woj> Please note that GSMP recommended the use of MAC addresses = because it was meant to run on TCP/IP. In ANCP , you can identify each = AN with the IP address and the sender-name is pretty much redudnant = today. However it appears it could well be used for the use-case you = described. =20 For that reasons I don't want to effectively abandon the partition-ID. = I highly recommend keeping the conventions (75th meeting minutes) for = partition ID as I understand they are meant to keep network scenarios = clean and avoid the mixing up of different layer informations.=20 =20 Woj> The existing "conventions" amount to partition-id beingthere, = like other GSMP fields, but its use is not currently specified in ANCP. =20 Regards, Woj.=20 =20 Best Regards, =20 Lothar Reith Detecon International GmbH (Deutsche Telekom Group) ________________________________ Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Freitag, 30. Oktober 2009 18:19 An: Reith, Lothar; Haag, Thomas; roberta.maglione@telecomitalia.it; = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: RE: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 Hi Lothar, =20 =09 Having the NAS/controller verify the sender-name (as is done today), = with each partition using a different sender name, would accomplish the = use-case below, without partition-id. Any problem with this? =20 Thanks, Woj. =20 ________________________________ From: Reith, Lothar [mailto:Lothar.Reith@detecon.com]=20 Sent: 30 October 2009 17:17 To: Wojciech Dec (wdec); Haag, Thomas; = roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 Hi Woj, dear all, =20 I fully support Thomas Haag`s point in his mail. =20 I also noticed that the following section is no longer present in = the current version, and propose to re-include: =20 Partition ID: =09 This field is a 8 bit number which signifies a partition on = the AN. [ TBD How AN and NAS agree on the partition numbers. = Possible options: =09 1 - The partition ID could be configured on the AN and learnt = by NAS in the adjacency message; =09 2 - The partition ID could be statically configured on the NAS = as part of configuring the neighbor information.] =20 =20 I further suggest to enhance the text as follows: =20 Partition ID: =09 This field is a 8 bit number which signifies a partition on = the AN. AN and NAS MAY agree on the partition ID using one of the = following possible options: =09 1 - The partition ID could be configured on the AN and learnt = by NAS in the adjacency message; =09 2 - The partition ID could be statically configured on the NAS = as part of configuring the neighbor information. =20 =20 A potential use case could be in assurance, e.g. to enable = verification that the proper (intended) partition ID is used over a = particular adjacency in cases where the AN has multiple adjacencies to = different NAS/Controller.=20 =20 Best Regards, Lothar Reith =20 Detecon International GmbH (Deutsche Telekom Group) ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im = Auftrag von Wojciech Dec (wdec) Gesendet: Donnerstag, 29. Oktober 2009 19:45 An: Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: Re: [ANCP] ANCP Versioning - next steps; partition ID =09 =09 While keeping the GSMP derived partition-id in the protocol spec = "as is" is fine, a note should perhaps also be inserted stating that = this field is effectively not currently used by ANCP. At least this is = my recollection of the discussion on this matter, ie partition-id is = fine, but we don't really have a use for it now given that functional = partitioning is not covered and that an AN will have 1 adjacency to each = NAS/controller. =20 -Woj. ________________________________ From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 28 October 2009 15:52 To: roberta.maglione@telecomitalia.it; Wojciech Dec (wdec); = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID =09 =09 Hi Roberta, all, =20 thanks for providing the updated protocol draft. =20 So far I recognized that the update covers issues regarding = versioning, tech Type for GPON and Range of values of the code field. =20 But I notice on page 17 of version 07 that the whole section of = partition ID including definition is deleted. From my understanding (and as result from the minutes) it was = agreed during 75th IETF meeting to keep the partition ID. =20 Extract from 75th IETF minutes:=20 =20 (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces = extensibility. Thomas Haag: need multiple partition-ids because one might need to = distinguish=20 between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational = problems=20 if partition-id not available.=20 No one felt strongly -- will keep "as is". =20 =09 So we had consensus not to remove and keep partion ID. But I didn't = find it in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are = there any reasons for doing this? =20 So I recommend update the protocol draft before upcoming meeting = keeping partition ID. =20 Regards =20 Thomas .=20 =20 ________________________________ Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps =09 =09 Hi All, I updated the ancp protocol draft following the chairs' = recommendations on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the = end of section 2:=20 "At the time of writing of this specification some implementations = of the ANCP protocol, based on pre-standards drafts are already = available. All these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use = version/ sub-version 3.2 [Editor's note: sub-version needs to be changed = from 1 to 2 upon publication.] Adopting a new sub-version value = provides a way to disambiguate the two protocols and allows for = supporting running a pre-standard and a standards compliant ANCP = implementation on any given ANCP node. The mechanism used to identify the = protocol version/sub-version is part of the adjacency negotiation process = and it is described in details in Section 5.2. It is important to = note that this mechanism does not guarantee backwards compatibility = of the ANCP RFC specification to those early-draft implementations." 2. I explained the version/sub-version negotiation process in = section 5.2:=20 "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 = upon publication.] In the adjacency protocol the version and the = sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In = a SYN message the version/sub-version fields always contain the = highest version understood by the sender. A receiver receiving a SYN = message with a version/sub-version higher than understood will ignore = that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but = a version/sub-version that it understands, will reply with a = SYNACK with the version/sub-version from the received SYN in its ANCP = version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol = remains synchronised. All other messages will use the agreed version in = the version/sub-version fields." =20 3. I added a non-normative appendix. This appendix will contain a = clarification of what version of the ANCP protocol draft specification = constitutes version 3.1 as soon as the WG decides on 3.1=20 "6. Appendix: Handling of pre-RFC deployments of the ANCP = protocol =20 This appendix is non normative. =20 Prior to completion of this document, several pre-RFC versions = of the protocol were documented and implemented. There were numerous = pre- standard versions of the protocol all using a = version/sub-version fields set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document = may, on a peer basis, use the version and sub-version fields to = detect a pre-RFC implementation of the protocol and choose to work with = such pre-RFC peers. The version and sub-version negotiation phase is = part of the adjacency protocol and is performed before = synchronisation is achieved." =20 Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not = or if you have additional comments please let me know. =20 Best Regards, Roberta =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Wojciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps =20 =20 Hi All,=20 During the ITEF75 WG meeting a discussion was had on ANCP protocol = versioning and the need to revise the protocol version. A follow-up = e-mail discussion on the WG alias took place and it seems appropriate = now (if not overdue) to draw up a set of recommendations and settle the = issue: Recommended protocol draft changes and WG actions=20 - The currently used ANCP version 3.1 is to change to 3.2 at the = time of publishing as an RFC. An instruction to execute such a change = should be placed as part of an editors' note in the next revision of = draft-ietf-ancp-protocol. This instruction is expected to only come into = effect at the time of final review past a WG last-call, which means that = until then v3.1 will be in evidence. Current implementers should make a = note of this fact. - Another note (not editorial though) should be placed in an = appropriate section, possibly Section 2 or Section 5, to convey in-brief = the historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) = based on early versions of the ANCP protocol draft. The note should be = clear in offering no guarantees in terms of backwards compatibility of = the RFC spec to those early-draft implementations. The note must also = not be seen as passing a normative reference to the early protocol = draft.=20 - Along with the above note, the existing GSMP/ANCP version = negotiation mechanisms could be highlighted, indicating that it provides = a way to distinguish between the different versions if the adjacency = establishment negotiation mechanism followed by all is as per GSMPv3 = (rfc3292). - For the sake of clarity it is recommended that the adjacency = negotiation be more fully described in the ANCP protocol draft instead = of the current reference to rfc3292. Specifically, it would appear = reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP = protocol spec, with the re-edit describing the version negotiation = behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic statements as to the expected behaviour in case of version = differences, but such text is in evidence in the descriptive part of = Section 11.1. - The WG should identify what version of the ANCP protocol draft = specification constitutes v3.1. A non-normative reference to such a = reference could be passed in the v3.2 spec. Rationale=20 From a technical point of view, given that a "current" (i.e. = draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols = are identical, with any newly added functions covered as negotiable = capabilities, the version change does not appear to be fully warranted = and not fully in line with the guidelines previously laid down = (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html = ). = That said, from an operational perspective a reasonable case for such a = version change has made based and presented in = https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docume= nt.htm = .=20 Now, given that normative compliance to an interim draft (such as = draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text = which may be perceived as mandating or claiming compatibility to such = interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 = and have plans for v3.2, the version negotiation mechanism that ANCP = inherited from GSMPv3 provides a way to disambiguate the two protocols = and thus allows in theory for supporting running a pre-standard (v3.1) = and a standards compliant v3.2 on any given ANCP node. The issue of = where v3.1 is documented can be solved by using non-normative references = to one of the interim drafts. The issue of what rev of draft-ietf-ancp = is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be = extending the protocol spec to cover issues around protocol version = negotiation or remediation of incompatibilities of draft = implementations. As such no such work is expected. We welcome clarification questions on the above.=20 Regards,=20 Wojciech & Matthew.=20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.=20 ------_=_NextPart_002_01CA5C7B.F365D3A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: ANCP = Versioning - next steps
Hi Thomas,
 
the framework is an informative document whose purpose is (was) = used to=20 help the WG steer at a high level the protocol design. Previous = discussions=20 have not revealed that a partition-id is needed, hence the "legacy = status" of=20 the partition field. It's perhaps also worth noting that current=20 implementations largely do not support it.
The latest discussion about the use-case from Lothar is a new = one (and=20 the use-case is not part of the framework), which is welcome to = continue. As=20 discussed so far, there appears to be another way for realizing this = use-case,=20 which does not require any new functionality. More opinions along with=20 reasons are welcome.
 
Thanks,
Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 02 November 2009=20 16:09
To: Wojciech Dec (wdec); Lothar.Reith@detecon.com;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net;=20 Manuel.Paul@telekom.de; B.Witschurke@telekom.de
Subject: AW: = [ANCP]=20 ANCP Versioning - next steps; partition ID

All,
 
I'm really concerned about the way = partition ID is=20 beeing discussed now.
The use of partitioning is described in = ANCP=20 Framework - final version.
Considering chapter 4.6.1 General = Architecture,=20 R-37,38,39,40 specifies exactly requirements for partitioning which is = naturally served by using of an appropriate partition ID. =
From my = understanding ANCP protocol=20 draft must follow ANCP framework requirements not = having diverge=20 work.
 
Derived from given descriptive text from = ANCP=20 framework it would be very useful for introduction in chapter = "partition=20 ID":
 
Textproposal:
 "The Access Node Control Mechanism is = defined=20 to operate between an Access Node (AN) and a NAS.  In such a = model, the=20 physical AN needs to be split in virtual ANs, each = having
   its=20 own Access Node Control reporting and/or enforcement function.=20 A partition ID is used for seperation=20 of different partions in one physical access node." =
 
 
As agreed in San = Francisco minutes the=20 partition ID remains as protocol field.
I strongly insist on following that = agreement=20 and keeping this field in protocol draft.
 
 
Regards
Thomas
 

Von: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Gesendet: Montag, 2. November 2009=20 14:54
An: Reith, Lothar; Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, = Manuel;=20 Witschurke, Birgit
Betreff: RE: [ANCP] ANCP Versioning - = next steps;=20 partition ID

Hi Lothar,
 
From: Reith, Lothar=20 [mailto:Lothar.Reith@detecon.com]
Sent: 02 November 2009=20 10:39
To: Wojciech Dec (wdec); Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, = Manuel;=20 Witschurke, Birgit
Subject: AW: [ANCP] ANCP Versioning - = next steps;=20 partition ID

 
Hi Woj,
 
I am afraid that your proposal means that = we=20 should use =20 "sender-name" instead=20 of "partition-ID" to = identify an=20 AN partition.
 
Known=20 implementations use  "sender-name" to convey either the management name of the = AN (and=20 the NAS/Controller respectively) or = a MAC=20 address as GSMPv3 = describes.
 
Woj> = The choice=20 of what goes into the sender-name is rather arbitrary; having a name = +=20 partition-id is pretty much as the same as having a name with=20 partition-id.
Furthermore, we're=20 now at v3.2 of ANCP...
 
So for = two reasons=20 it is not possible to use "sender name" instead of "partition=20 ID":
 
1.=20 The associated functionality to verify if = one is=20 talking to the proper (intended) AN (or NAS/Controller=20 respectively) 
    would be = lost=20 if when using the sender-id to convey the partition-ID = instead of=20 the management name of the device. 
 
Woj> = How so? The=20 name is an opaque value that has significance to the operator, very = much=20 like partition-id.

 
2. If a MAC address = information in "sender=20 name" would be used for "partition ID" only one partition can be = used=20 because usually a AN uses one MAC address. So we have a conflict on=20 networking because usually an access node use one MAC Adresse = regardles of=20 partitioning.  
&nbs= p;
Woj> Please note that GSMP recommended the use of = MAC=20 addresses because it was meant to run on TCP/IP. In ANCP , you = can=20 identify each AN with the IP = address and the=20 sender-name is pretty much redudnant today. However it appears it = could well=20 be used for the use-case you=20 described.
 
For that reasons I don't want to = effectively=20 abandon the partition-ID. I highly = recommend=20 keeping the conventions (75th meeting minutes) for partition ID = as I understand they=20 are meant to keep = network=20 scenarios clean and avoid the=20 mixing up of = different=20 layer informations. 
 
Woj> The=20 existing "conventions" amount to partition-id beingthere, = like=20 other GSMP fields, but its use is not currently specified in=20 ANCP.
 
Regards,=
Woj. 
&nbs= p;
Best=20 Regards,
&nbs= p;
Lothar=20 Reith
Detecon=20 International GmbH (Deutsche Telekom=20 = Group)
=
Von: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Gesendet: Freitag, 30. Oktober = 2009=20 18:19
An: Reith, Lothar; Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke,=20 Birgit
Betreff: RE: [ANCP] ANCP Versioning - next steps; = partition ID

Hi Lothar,
 
Having the NAS/controller verify the sender-name (as is = done=20 today), with each partition using a different sender name, = would=20 accomplish the use-case below, without partition-id. Any problem = with=20 this?
 
Thanks,
Woj.
 

From: Reith, Lothar=20 [mailto:Lothar.Reith@detecon.com]
Sent: 30 October = 2009=20 17:17
To: Wojciech Dec (wdec); Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke,=20 Birgit
Subject: AW: [ANCP] ANCP Versioning - next = steps;=20 partition ID

Hi = Woj, dear=20 all,
 
I fully support Thomas Haag`s point in = his=20 mail.
 
I also noticed that the following = section is no=20 longer present in the current version, and propose to=20 re-include:
 
Partition=20 ID:

      This field is a 8 bit = number=20 which signifies a partition on = the
      AN.=20 [ TBD How AN and NAS agree on the partition numbers. =20 Possible
     =20 options:

      1 - The partition = ID=20 could be configured on the AN and learnt=20 by
      NAS in the adjacency=20 message;

      2 - The partition = ID=20 could be statically configured on the NAS=20 as
      part of configuring the = neighbor=20 information.]
 
 
I further suggest to enhance the text = as=20 follows:
 
Partition=20 ID:

      This field is a 8 bit = number=20 which signifies a partition on = the
     =20 AN.  AN and NAS MAY agree on the partition ID using one of = the=20 following possible
     =20 options:

      1 - The partition = ID=20 could be configured on the AN and learnt=20 by
      NAS in the adjacency=20 message;

      2 - The partition = ID=20 could be statically configured on the NAS=20 as
      part of configuring the = neighbor=20 information.
 
 
A potential use case could be in = assurance,=20 e.g. to enable verification that the proper=20 (intended) partition ID is used over a = particular adjacency in=20 cases where the AN has multiple adjacencies to different=20 NAS/Controller. 
 
 Best Regards, Lothar=20 Reith
 
Detecon International GmbH (Deutsche = Telekom=20 Group)

Von: ancp-bounces@ietf.org = [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech = Dec=20 (wdec)
Gesendet: Donnerstag, 29. Oktober 2009=20 19:45
An: Haag, Thomas; = roberta.maglione@telecomitalia.it;=20 ancp@ietf.org; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; = Paul,=20 Manuel; Witschurke, Birgit
Betreff: Re: [ANCP] ANCP=20 Versioning - next steps; partition ID

While keeping the GSMP = derived partition-id in=20 the protocol spec "as is" is fine, a note should perhaps also = be=20 inserted stating that this field is effectively not currently = used by=20 ANCP. At least this is my recollection of the discussion on = this=20 matter, ie partition-id is fine, but we don't really have a = use for it=20 now given that functional partitioning is not covered and that = an AN=20 will have 1 adjacency to each = NAS/controller.
 
-Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 28 October 2009=20 15:52
To: roberta.maglione@telecomitalia.it; = Wojciech Dec=20 (wdec); ancp@ietf.org; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net;=20 Manuel.Paul@telekom.de; = B.Witschurke@telekom.de
Subject:=20 AW: ANCP Versioning - next steps; partition = ID

Hi Roberta, = all,
 
thanks for providing = the updated=20 protocol draft.
 
So far I recognized = that the update=20 covers issues regarding versioning, tech Type for GPON and = Range of=20 values of the code field.
 
But I notice on page = 17 of version=20 07 that the whole section of partition ID including = definition is=20 deleted.
From my understanding = (and as=20 result from the minutes) it was agreed during 75th IETF = meeting=20 to keep the partition ID.
 
Extract from 75th = IETF minutes:=20
 
(1)=20 Partition-id
    ------------
Sanjay: = concerned=20 that removing the partition-id reduces = extensibility.
Thomas=20 Haag: need multiple partition-ids because one might need to=20 distinguish
between BRASs when expanding the = network.
Woj:=20 send e-mail. Thomas: already did. Makes for operational = problems=20
if partition-id not available.
No one felt strongly = -- will=20 keep "as is".
 
So we = had consensus not to=20 remove and keep partion ID. But I didn't find it in the = whole=20 document any more.
Based on that agreements I wonder why this issue is = deleted. Are there any = reasons for=20 doing this?
 
So I recommend update = the protocol=20 draft before upcoming meeting keeping partition=20 ID.
 
Regards
 
Thomas
.
 

Von: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it] =
Gesendet:=20 Montag, 19. Oktober 2009 16:16
An: 'Wojciech Dec = (wdec)';=20 ancp@ietf.org; Haag, Thomas; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net; BOCCI = Matthew;=20 'tom111.taylor@bell.net'
Betreff: RE: ANCP = Versioning -=20 next steps

Hi=20 All,

    =20 I updated the ancp protocol draft following the chairs=92=20 recommendations on the ANCP = versioning.

In=20 particular:

  1. I added some = text to=20 explain the history and rationale, at the end of section=20 2:

 =93At=20 the time of writing of this specification some = implementations of=20 the ANCP protocol, based on pre-standards drafts are already = available.  All these early-draft implementations use=20 protocol

  =20 version/sub-version 3.1; standard ANCP protocol will use=20 version/

  =20 sub-version 3.2 [Editor's note: sub-version needs to be = changed=20 from

  =20 1 to 2 upon publication.]  Adopting a new sub-version = value=20 provides

  =20 a way to disambiguate the two protocols and allows for=20 supporting

  =20 running a pre-standard and a standards compliant ANCP=20 implementation

  =20 on any given ANCP node.  The mechanism used to identify = the=20 protocol

  =20 version/sub-version is part of the adjacency negotiation = process=20 and

  =20 it is described in details in Section 5.2.  It is = important to=20 note

  =20 that this mechanism does not guarantee backwards = compatibility of=20 the

  =20 ANCP RFC specification to those early-draft=20 implementations.=94

  1. I explained = the=20 version/sub-version negotiation process in section=20 5.2:=20

=93ANCP=20 uses version 3 and sub-version 1 of GSMP=20 protocol.

  =20 [RFC Editor's note: sub-version needs to be changed from 1 = to 2=20 upon

  =20 publication.]  In the adjacency protocol the version = and the=20 sub-

  =20 version fields are used for version negotiation.  The=20 version

  =20 negotiation is performed before synchronisation is = achieved. =20 In a

  =20 SYN message the version/sub-version fields always contain = the=20 highest

  =20 version understood by the sender.  A receiver receiving = a SYN=20 message

  =20 with a version/sub-version higher than understood will = ignore=20 that

  =20 message.  A receiver receiving a SYN message with a=20 version/

  =20 sub-vresion lower than its own highest version/sub-version, = but=20 a

  =20 version/sub-version that it understands, will reply with a=20 SYNACK

  =20 with the version/sub-version from the received SYN in its = ANCP=20 version/sub-version fields.  This defines the=20 version/sub-version of

  =20 the ANCP protocol to be used while the adjacency protocol=20 remains

  =20 synchronised.  All other messages will use the agreed = version=20 in the

  =20 version/sub-version fields.=94

 

  1. I added a=20 non-normative appendix. This = appendix will=20 contain a clarification of what version of the ANCP = protocol draft=20 specification constitutes version 3.1 as soon as the WG = decides on=20 3.1=20

=936. =20 Appendix: Handling of pre-RFC deployments of the ANCP =20 protocol

 

  =20 This appendix is non normative.

 

  =20 Prior to completion of this document, several pre-RFC = versions of=20 the

  =20 protocol were documented and implemented.  There were = numerous=20 pre-

  =20 standard versions of the protocol all using a=20 version/sub-version

  =20 fields set to 3.1.

 

  =20 A NAS implementing the ANCP protocol as defined in this = document=20 may,

  =20 on a peer basis, use the version and sub-version fields to = detect=20 a

  =20 pre-RFC implementation of the protocol and choose to work = with=20 such

  =20 pre-RFC peers.  The version and sub-version negotiation = phase=20 is part

  =20 of the adjacency protocol and is performed before = synchronisation=20 is

  =20 achieved.=94

 

Please find=20 new version of draft attached.

I = hope I=92ve=20 captured most of your feedback in the new draft, if not or = if you=20 have additional comments please let me=20 know.

 

Best=20 Regards,

Roberta

 

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On=20 Behalf Of Wojciech Dec (wdec)
Sent: Wednesday, = October 14,=20 2009 1:07 PM
To:=20 ancp@ietf.org
Subject: [ANCP] FW: = ANCP=20 Versioning - next steps

 

 

Hi=20 All,

During the = ITEF75 WG=20 meeting a discussion was had on ANCP protocol versioning and = the=20 need to revise the protocol version. A follow-up e-mail = discussion=20 on the WG alias took place and it seems appropriate now (if not=20 overdue) to draw up a set of recommendations = and=20 settle the issue:

Recommended = protocol=20 draft changes and WG=20 actions=20

- The = currently used=20 ANCP version 3.1 is to change to 3.2 at the time of = publishing as an=20 RFC. An instruction to execute such a change should be = placed as=20 part of an editors' note in the next revision of=20 draft-ietf-ancp-protocol. This instruction is expected to = only come=20 into effect at the time of final review past a WG last-call, = which=20 means that until then v3.1 will be in evidence. Current = implementers=20 should make a note of this = fact.

- Another note = (not=20 editorial though) should be placed in an appropriate = section,=20 possibly Section 2 or Section 5, to convey in-brief the = historic=20 aspect of GSMP/ANCP v3.1 implementations, which are (were?) = based on=20 early versions of the ANCP protocol draft. The note should = be clear=20 in offering no guarantees in terms of backwards = compatibility of the=20 RFC spec to those early-draft implementations. The note must = also=20 not be seen as passing a normative reference to the early = protocol=20 draft.

- Along with = the above=20 note, the existing GSMP/ANCP version negotiation mechanisms = could be=20 highlighted, indicating that it provides a way to = distinguish=20 between the different versions if the adjacency = establishment=20 negotiation mechanism followed by all is as per GSMPv3=20 (rfc3292).

- For the sake = of=20 clarity it is recommended that the adjacency negotiation be = more=20 fully described in the ANCP protocol draft instead of the = current=20 reference to rfc3292. Specifically, it would appear = reasonable to=20 adopt and re-edit Section 11.2 of rfc3292 into the ANCP = protocol=20 spec, with the re-edit describing the version negotiation = behaviour.=20 Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic=20 statements as to the expected behaviour in case of version=20 differences, but such text is in evidence in the descriptive = part of=20 Section 11.1.

- The WG=20 should identify what version of the ANCP protocol draft=20 specification constitutes v3.1. A non-normative reference to = such a=20 reference could be passed in the v3.2=20 spec.

Rationale

From a = technical point=20 of view, given that a "current" (i.e. draft-ietf-protocol-06 = based) and=20 future (i.e. ANCP RFC = based)=20 protocols are identical, with any newly = added functions covered as=20 negotiable = capabilities,=20 the version change does=20 not appear to be = fully warranted and = not fully=20 in line with the guidelines previously laid down = (= http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That said, = from=20 an=20 operational=20 perspective a = reasonable=20 case for such a version = change has made based = and = presented=20 in https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3= _document.htm.=20

Now,=20 given that = normative=20 compliance to an interim draft (such = as draft-ietf-protocol-06=20 based) = cannot be = passed by the=20 ANCP RFC, text which may be perceived = as=20 mandating or claiming compatibility to such  interim = drafts needs=20 to be avoided.

In the case = of=20 vendors and = operators=20 that already = support/use v3.1=20 and have plans for v3.2, the version negotiation mechanism = that ANCP=20 inherited from GSMPv3 provides a way to disambiguate the two = protocols and thus allows = in theory=20 for = supporting = running a=20 pre-standard (v3.1) and a standards compliant v3.2 on any = given ANCP=20 node. The = issue of=20 where v3.1 is documented can be solved by using = non-normative=20 references to one of the interim drafts. The issue of what = rev of=20 draft-ietf-ancp is considered to be v3.1 needs to be=20 clarified.

Other than the = above the=20 WG is currently not chartered to be = extending the=20 protocol spec to cover issues around protocol version = negotiation or=20 remediation of incompatibilities of draft = implementations. As such no such = work is=20 expected.

We welcome=20 clarification questions on the above.=20

Regards,=20
Wojciech &=20 Matthew.=20

Questo=20 messaggio e i suoi allegati sono indirizzati = esclusivamente=20 alle persone indicate. La diffusione, copia o = qualsiasi altra=20 azione derivante dalla conoscenza di queste = informazioni sono=20 rigorosamente vietate. Qualora abbiate ricevuto questo = documento per errore siete cortesemente pregati di = darne=20 immediata comunicazione al mittente e di provvedere = alla sua=20 distruzione, Grazie.

This=20 e-mail and any attachments is confidential=20 and may contain privileged information intended for = the=20 addressee(s) only. Dissemination, copying, printing or = use by=20 anybody else is unauthorised. If you are not the = intended=20 recipient, please delete this message and any = attachments and=20 advise the sender by return e-mail, = Thanks.=20

3D"rispettaRispetta l'ambiente. Non stampare questa = mail se non=20 =E8 necessario.=20 =

<= /BLOCKQUOTE>
------_=_NextPart_002_01CA5C7B.F365D3A8-- ------_=_NextPart_001_01CA5C7B.F365D3A8 Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: <733103611@03112009-1A75> Content-Description: logo Ambiente_foglia.jpg Content-Location: logo%20Ambiente_foglia.jpg R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------_=_NextPart_001_01CA5C7B.F365D3A8-- From wdec@cisco.com Tue Nov 3 04:33:25 2009 Return-Path: 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 B620E3A68DE for ; Tue, 3 Nov 2009 04:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.7 X-Spam-Level: X-Spam-Status: No, score=-9.7 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 wDTUiqKTD9Wz for ; Tue, 3 Nov 2009 04:33:24 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D6DE03A6819 for ; Tue, 3 Nov 2009 04:33:23 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcAAMux70qQ/uCWe2dsb2JhbACbVQEBFiQGqiiXc4Q9BIFk X-IronPort-AV: E=Sophos;i="4.44,674,1249257600"; d="scan'208";a="53491950" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2009 12:33:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3CXheX006728; Tue, 3 Nov 2009 12:33:43 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 13:33:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2009 13:33:38 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Agenda items for IETF76 ANCP WG meeting Thread-Index: Acn+6ltl92lm+d4MS0WQoGhkOfvVhRMJzVNgA59idbAAvKcoEA== References: From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 03 Nov 2009 12:33:43.0270 (UTC) FILETIME=[E13A2060:01CA5C81] Subject: Re: [ANCP] Agenda items for IETF76 ANCP WG meeting 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: , X-List-Received-Date: Tue, 03 Nov 2009 12:33:26 -0000 Hi All, latest agenda is as follows: Tuesday, November 10, 2009 -----------------------------------=20 CHAIRS: Wojciech Dec & Matthew Bocci=20 =20 10 mins WG Status and Update - Chairs=20 10 mins - Protocol for Access Node Control Mechanism in Broadband Networks - R. Maglione, S. Wadhwa http://tools.ietf.org/html/draft-ietf-ancp-protocol 10 mins - TR-147 gap overview - Hongyu Li 15 mins - ANCP Restart - Shridhar Rao=20 http://tools.ietf.org/html/draft-ancp-restart 15 mins - Multicast Control Extensions for ANCP - Francois Le Faucheur=20 http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions=20 From roberta.maglione@telecomitalia.it Wed Nov 4 01:50:59 2009 Return-Path: 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 3F63B3A67B8 for ; Wed, 4 Nov 2009 01:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.569 X-Spam-Level: X-Spam-Status: No, score=0.569 tagged_above=-999 required=5 tests=[AWL=1.132, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SUBJECT_FUZZY_TION=0.156] 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 9skg5DGwaxqV for ; Wed, 4 Nov 2009 01:50:57 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 3FD9F3A676A for ; Wed, 4 Nov 2009 01:50:56 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 4 Nov 2009 10:51:15 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Wed, 4 Nov 2009 10:51:14 +0100 From: Maglione Roberta To: "HaagT@telekom.de" , "wdec@cisco.com" , "ancp@ietf.org" , "alan.kavanagh@ericsson.com" , "Robert.Rennison@ecitele.com" , "swadhwa@juniper.net" , "matthew.bocci@alcatel-lucent.co.uk" , "tom111.taylor@bell.net" , "Manuel.Paul@telekom.de" , "B.Witschurke@telekom.de" Date: Wed, 4 Nov 2009 10:51:13 +0100 Thread-Topic: ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAFWvoXq Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3E686D304A@GRFMBX704BA020.griffon.local> References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local>, <5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID 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: , X-List-Received-Date: Wed, 04 Nov 2009 09:50:59 -0000 Hi All, Just a clarification on Partition-Id: Version 07 of the protocol still contains Partition-Id field and original = definition, on page 18, I didn=92t remove the partition ID field I've just = deleted the two options to select this value, on page 18: =93 Partition ID: This field is a 8 bit number which signifies a partition on the AN. My understanding from SF meeting =93No one felt strongly -- will keep "as i= s" was that we keep current definition of Partition ID as it was originally= , thus I removed the two options. If the WG feels we need the two options I= can update the draft with the text proposed by Rothar: Partition ID: This field is a 8 bit number which signifies a partition on the AN. AN and NAS MAY agree on the partition ID using one of the follow= ing possible options: 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; 2 - The partition ID could be statically configured on the NAS as part of configuring the neighbor information. Please let me know, thanks. Best Regards, Roberta ________________________________________ From: HaagT@telekom.de [HaagT@telekom.de] Sent: Wednesday, October 28, 2009 3:52 PM To: Maglione Roberta; wdec@cisco.com; ancp@ietf.org; alan.kavanagh@ericsson= .com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; matthew.bocci@alcat= el-lucent.co.uk; tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschur= ke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID Hi Roberta, all, thanks for providing the updated protocol draft. So far I recognized that the update covers issues regarding versioning, tec= h Type for GPON and Range of values of the code field. But I notice on page 17 of version 07 that the whole section of partition I= D including definition is deleted. >From my understanding (and as result from the minutes) it was agreed during= 75th IETF meeting to keep the partition ID. Extract from 75th IETF minutes: (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces extensibility. Thomas Haag: need multiple partition-ids because one might need to distingu= ish between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational problems if partition-id not available. No one felt strongly -- will keep "as is". So we had consensus not to remove and keep partion ID. But I didn't find it= in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are there any = reasons for doing this? So I recommend update the protocol draft before upcoming meeting keeping pa= rtition ID. Regards Thomas . ________________________________ Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; alan.kavanagh@erics= son.com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; BOCCI Matthew; '= tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps Hi All, I updated the ancp protocol draft following the chairs=92 recommendati= ons on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the end of = section 2: =93At the time of writing of this specification some implementations of th= e ANCP protocol, based on pre-standards drafts are already available. All = these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] Adopting a new sub-version value provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP implementation on any given ANCP node. The mechanism used to identify the protocol version/sub-version is part of the adjacency negotiation process and it is described in details in Section 5.2. It is important to note that this mechanism does not guarantee backwards compatibility of the ANCP RFC specification to those early-draft implementations.=94 1. I explained the version/sub-version negotiation process in section 5.2= : =93ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the highest version understood by the sender. A receiver receiving a SYN message with a version/sub-version higher than understood will ignore that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP version/s= ub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in the version/sub-version fields.=94 1. I added a non-normative appendix. This appendix will contain a clarifi= cation of what version of the ANCP protocol draft specification constitutes= version 3.1 as soon as the WG decides on 3.1 =936. Appendix: Handling of pre-RFC deployments of the ANCP protocol This appendix is non normative. Prior to completion of this document, several pre-RFC versions of the protocol were documented and implemented. There were numerous pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. A NAS implementing the ANCP protocol as defined in this document may, on a peer basis, use the version and sub-version fields to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers. The version and sub-version negotiation phase is part of the adjacency protocol and is performed before synchronisation is achieved.=94 Please find new version of draft attached. I hope I=92ve captured most of your feedback in the new draft, if not or if= you have additional comments please let me know. Best Regards, Roberta ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps Hi All, During the ITEF75 WG meeting a discussion was had on ANCP protocol versioni= ng and the need to revise the protocol version. A follow-up e-mail discussi= on on the WG alias took place and it seems appropriate now (if not overdue)= to draw up a set of recommendations and settle the issue: Recommended protocol draft changes and WG actions - The currently used ANCP version 3.1 is to change to 3.2 at the time of pu= blishing as an RFC. An instruction to execute such a change should be place= d as part of an editors' note in the next revision of draft-ietf-ancp-proto= col. This instruction is expected to only come into effect at the time of f= inal review past a WG last-call, which means that until then v3.1 will be i= n evidence. Current implementers should make a note of this fact. - Another note (not editorial though) should be placed in an appropriate se= ction, possibly Section 2 or Section 5, to convey in-brief the historic asp= ect of GSMP/ANCP v3.1 implementations, which are (were?) based on early ver= sions of the ANCP protocol draft. The note should be clear in offering no g= uarantees in terms of backwards compatibility of the RFC spec to those earl= y-draft implementations. The note must also not be seen as passing a normat= ive reference to the early protocol draft. - Along with the above note, the existing GSMP/ANCP version negotiation mec= hanisms could be highlighted, indicating that it provides a way to distingu= ish between the different versions if the adjacency establishment negotiati= on mechanism followed by all is as per GSMPv3 (rfc3292). - For the sake of clarity it is recommended that the adjacency negotiation = be more fully described in the ANCP protocol draft instead of the current r= eference to rfc3292. Specifically, it would appear reasonable to adopt and = re-edit Section 11.2 of rfc3292 into the ANCP protocol spec, with the re-ed= it describing the version negotiation behaviour. Rather confusingly Rfc3292= Section 11.2 does not carry text or logic statements as to the expected be= haviour in case of version differences, but such text is in evidence in the= descriptive part of Section 11.1. - The WG should identify what version of the ANCP protocol draft specificat= ion constitutes v3.1. A non-normative reference to such a reference could b= e passed in the v3.2 spec. Rationale >From a technical point of view, given that a "current" (i.e. draft-ietf-pro= tocol-06 based) and future (i.e. ANCP RFC based) protocols are identical, w= ith any newly added functions covered as negotiable capabilities, the versi= on change does not appear to be fully warranted and not fully in line with = the guidelines previously laid down (http://www.ietf.org/mail-archive/web/a= ncp/current/msg00152.html). That said, from an operational perspective a re= asonable case for such a version change has made based and presented in htt= ps://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_document.ht= m. Now, given that normative compliance to an interim draft (such as draft-iet= f-protocol-06 based) cannot be passed by the ANCP RFC, text which may be pe= rceived as mandating or claiming compatibility to such interim drafts need= s to be avoided. In the case of vendors and operators that already support/use v3.1 and have= plans for v3.2, the version negotiation mechanism that ANCP inherited from= GSMPv3 provides a way to disambiguate the two protocols and thus allows in= theory for supporting running a pre-standard (v3.1) and a standards compli= ant v3.2 on any given ANCP node. The issue of where v3.1 is documented can = be solved by using non-normative references to one of the interim drafts. T= he issue of what rev of draft-ietf-ancp is considered to be v3.1 needs to b= e clarified. Other than the above the WG is currently not chartered to be extending the = protocol spec to cover issues around protocol version negotiation or remedi= ation of incompatibilities of draft implementations. As such no such work i= s expected. We welcome clarification questions on the above. Regards, Wojciech & Matthew. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:906131214@28102009-136B]Rispetta l'ambiente. Non stampare questa mail = se non =E8 necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From HaagT@telekom.de Wed Nov 4 02:03:22 2009 Return-Path: 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 5956C3A699F for ; Wed, 4 Nov 2009 02:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=1.230, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156] 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 h42PHXhQpP1a for ; Wed, 4 Nov 2009 02:03:20 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 196A93A67B8 for ; Wed, 4 Nov 2009 02:03:19 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 04 Nov 2009 11:03:32 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 11:03:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2009 11:03:30 +0100 Message-ID: <5661758E3E93364685B91DD8272F2876020F76AC@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3E686D304A@GRFMBX704BA020.griffon.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAFWvoXqAAA5JfA= References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local>, <5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> <282BBE8A501E1F4DA9C775F964BB21FE3E686D304A@GRFMBX704BA020.griffon.local> From: To: , , , , , , , , , X-OriginalArrivalTime: 04 Nov 2009 10:03:32.0185 (UTC) FILETIME=[109D6C90:01CA5D36] Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID 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: , X-List-Received-Date: Wed, 04 Nov 2009 10:03:22 -0000 Roberta, all, Thanx for clarification, I noticed the changes which triggered my = comment I strongly support keeping also the options as they are because it was = no agreement to delete them. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Gesendet: Mittwoch, 4. November 2009 10:51 An: Haag, Thomas; wdec@cisco.com; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: RE: ANCP Versioning - next steps; partition ID Hi All, Just a clarification on Partition-Id: Version 07 of the protocol still contains Partition-Id field and = original definition, on page 18, I didn't remove the partition ID field = I've just deleted the two options to select this value, on page 18: " Partition ID: This field is a 8 bit number which signifies a partition on the AN. My understanding from SF meeting "No one felt strongly -- will keep "as = is" was that we keep current definition of Partition ID as it was = originally, thus I removed the two options. If the WG feels we need the = two options I can update the draft with the text proposed by Rothar: Partition ID: This field is a 8 bit number which signifies a partition on the AN. AN and NAS MAY agree on the partition ID using one of the = following possible options: 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; 2 - The partition ID could be statically configured on the NAS as part of configuring the neighbor information. Please let me know, thanks. Best Regards, Roberta ________________________________________ From: HaagT@telekom.de [HaagT@telekom.de] Sent: Wednesday, October 28, 2009 3:52 PM To: Maglione Roberta; wdec@cisco.com; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID Hi Roberta, all, thanks for providing the updated protocol draft. So far I recognized that the update covers issues regarding versioning, = tech Type for GPON and Range of values of the code field. But I notice on page 17 of version 07 that the whole section of = partition ID including definition is deleted. >From my understanding (and as result from the minutes) it was agreed = during 75th IETF meeting to keep the partition ID. Extract from 75th IETF minutes: (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces extensibility. Thomas Haag: need multiple partition-ids because one might need to = distinguish between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational problems if partition-id not available. No one felt strongly -- will keep "as is". So we had consensus not to remove and keep partion ID. But I didn't find = it in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are there = any reasons for doing this? So I recommend update the protocol draft before upcoming meeting keeping = partition ID. Regards Thomas . ________________________________ Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps Hi All, I updated the ancp protocol draft following the chairs' = recommendations on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the end = of section 2: "At the time of writing of this specification some implementations of = the ANCP protocol, based on pre-standards drafts are already available. = All these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] Adopting a new sub-version value provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP implementation on any given ANCP node. The mechanism used to identify the protocol version/sub-version is part of the adjacency negotiation process and it is described in details in Section 5.2. It is important to note that this mechanism does not guarantee backwards compatibility of the ANCP RFC specification to those early-draft implementations." 1. I explained the version/sub-version negotiation process in section = 5.2: "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the highest version understood by the sender. A receiver receiving a SYN message with a version/sub-version higher than understood will ignore that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP = version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in the version/sub-version fields." 1. I added a non-normative appendix. This appendix will contain a = clarification of what version of the ANCP protocol draft specification = constitutes version 3.1 as soon as the WG decides on 3.1 "6. Appendix: Handling of pre-RFC deployments of the ANCP protocol This appendix is non normative. Prior to completion of this document, several pre-RFC versions of the protocol were documented and implemented. There were numerous pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. A NAS implementing the ANCP protocol as defined in this document may, on a peer basis, use the version and sub-version fields to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers. The version and sub-version negotiation phase is part of the adjacency protocol and is performed before synchronisation is achieved." Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not or = if you have additional comments please let me know. Best Regards, Roberta ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps Hi All, During the ITEF75 WG meeting a discussion was had on ANCP protocol = versioning and the need to revise the protocol version. A follow-up = e-mail discussion on the WG alias took place and it seems appropriate = now (if not overdue) to draw up a set of recommendations and settle the = issue: Recommended protocol draft changes and WG actions - The currently used ANCP version 3.1 is to change to 3.2 at the time of = publishing as an RFC. An instruction to execute such a change should be = placed as part of an editors' note in the next revision of = draft-ietf-ancp-protocol. This instruction is expected to only come into = effect at the time of final review past a WG last-call, which means that = until then v3.1 will be in evidence. Current implementers should make a = note of this fact. - Another note (not editorial though) should be placed in an appropriate = section, possibly Section 2 or Section 5, to convey in-brief the = historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) = based on early versions of the ANCP protocol draft. The note should be = clear in offering no guarantees in terms of backwards compatibility of = the RFC spec to those early-draft implementations. The note must also = not be seen as passing a normative reference to the early protocol = draft. - Along with the above note, the existing GSMP/ANCP version negotiation = mechanisms could be highlighted, indicating that it provides a way to = distinguish between the different versions if the adjacency = establishment negotiation mechanism followed by all is as per GSMPv3 = (rfc3292). - For the sake of clarity it is recommended that the adjacency = negotiation be more fully described in the ANCP protocol draft instead = of the current reference to rfc3292. Specifically, it would appear = reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP = protocol spec, with the re-edit describing the version negotiation = behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic statements as to the expected behaviour in case of version = differences, but such text is in evidence in the descriptive part of = Section 11.1. - The WG should identify what version of the ANCP protocol draft = specification constitutes v3.1. A non-normative reference to such a = reference could be passed in the v3.2 spec. Rationale >From a technical point of view, given that a "current" (i.e. = draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols = are identical, with any newly added functions covered as negotiable = capabilities, the version change does not appear to be fully warranted = and not fully in line with the guidelines previously laid down = (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That = said, from an operational perspective a reasonable case for such a = version change has made based and presented in = https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docume= nt.htm. Now, given that normative compliance to an interim draft (such as = draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text = which may be perceived as mandating or claiming compatibility to such = interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 and = have plans for v3.2, the version negotiation mechanism that ANCP = inherited from GSMPv3 provides a way to disambiguate the two protocols = and thus allows in theory for supporting running a pre-standard (v3.1) = and a standards compliant v3.2 on any given ANCP node. The issue of = where v3.1 is documented can be solved by using non-normative references = to one of the interim drafts. The issue of what rev of draft-ietf-ancp = is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be extending = the protocol spec to cover issues around protocol version negotiation or = remediation of incompatibilities of draft implementations. As such no = such work is expected. We welcome clarification questions on the above. Regards, Wojciech & Matthew. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. [cid:906131214@28102009-136B]Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. From Lothar.Reith@detecon.com Wed Nov 4 02:53:01 2009 Return-Path: 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 AFDF93A683E for ; Wed, 4 Nov 2009 02:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[AWL=1.834, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] 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 ypLKZRfylV8z for ; Wed, 4 Nov 2009 02:53:00 -0800 (PST) Received: from dtc034.detecon.net (dtc034.detecon.net [194.25.60.134]) by core3.amsl.com (Postfix) with ESMTP id 91C5D3A677D for ; Wed, 4 Nov 2009 02:52:59 -0800 (PST) Received: from unknown (HELO dc00356.detecon.com) ([172.16.10.106]) by relay.dtc034.detecon.net with ESMTP; 04 Nov 2009 11:53:07 +0100 Received: from DC00331.detecon.com ([172.16.10.78]) by dc00356.detecon.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 11:53:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2009 11:53:06 +0100 Message-ID: In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3E686D304A@GRFMBX704BA020.griffon.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Versioning - next steps; partition ID Thread-Index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAFWvoXqAAIYzpA= References: <282BBE8A501E1F4DA9C775F964BB21FE3E670E8000@GRFMBX704BA020.griffon.local>, <5661758E3E93364685B91DD8272F287602072816@S4DE8PSAAQC.mitte.t-com.de> <282BBE8A501E1F4DA9C775F964BB21FE3E686D304A@GRFMBX704BA020.griffon.local> From: "Reith, Lothar" To: "Maglione Roberta" , "Haag, Thomas" , , , , , , , , "Paul, Manuel" , "Witschurke, Birgit" X-OriginalArrivalTime: 04 Nov 2009 10:53:07.0234 (UTC) FILETIME=[FDE1E020:01CA5D3C] Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID 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: , X-List-Received-Date: Wed, 04 Nov 2009 10:53:01 -0000 Hi Roberta, all, I also support to re-insert the Partition ID options, and welcome your = suggestion to adopt my respective wording proposal. Best Regards, Lothar Reith=20 Detecon International GmbH=20 -----Urspr=FCngliche Nachricht----- Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von = Maglione Roberta Gesendet: Mittwoch, 4. November 2009 10:51 An: Haag, Thomas; wdec@cisco.com; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: Re: [ANCP] ANCP Versioning - next steps; partition ID Hi All, Just a clarification on Partition-Id: Version 07 of the protocol still contains Partition-Id field and = original definition, on page 18, I didn't remove the partition ID field = I've just deleted the two options to select this value, on page 18: " Partition ID: This field is a 8 bit number which signifies a partition on the AN. My understanding from SF meeting "No one felt strongly -- will keep "as = is" was that we keep current definition of Partition ID as it was = originally, thus I removed the two options. If the WG feels we need the = two options I can update the draft with the text proposed by Rothar: Partition ID: This field is a 8 bit number which signifies a partition on the AN. AN and NAS MAY agree on the partition ID using one of the = following possible options: 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; 2 - The partition ID could be statically configured on the NAS as part of configuring the neighbor information. Please let me know, thanks. Best Regards, Roberta ________________________________________ From: HaagT@telekom.de [HaagT@telekom.de] Sent: Wednesday, October 28, 2009 3:52 PM To: Maglione Roberta; wdec@cisco.com; ancp@ietf.org; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID Hi Roberta, all, thanks for providing the updated protocol draft. So far I recognized that the update covers issues regarding versioning, = tech Type for GPON and Range of values of the code field. But I notice on page 17 of version 07 that the whole section of = partition ID including definition is deleted. >From my understanding (and as result from the minutes) it was agreed = during 75th IETF meeting to keep the partition ID. Extract from 75th IETF minutes: (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces extensibility. Thomas Haag: need multiple partition-ids because one might need to = distinguish between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational problems if = partition-id not available. No one felt strongly -- will keep "as is". So we had consensus not to remove and keep partion ID. But I didn't find = it in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are there = any reasons for doing this? So I recommend update the protocol draft before upcoming meeting keeping = partition ID. Regards Thomas . ________________________________ Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; = alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; = swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps Hi All, I updated the ancp protocol draft following the chairs' = recommendations on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the end = of section 2: "At the time of writing of this specification some implementations of = the ANCP protocol, based on pre-standards drafts are already available. = All these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] Adopting a new sub-version value provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP implementation on any given ANCP node. The mechanism used to identify the protocol version/sub-version is part of the adjacency negotiation process and it is described in details in Section 5.2. It is important to note that this mechanism does not guarantee backwards compatibility of the ANCP RFC specification to those early-draft implementations." 1. I explained the version/sub-version negotiation process in section = 5.2: "ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the highest version understood by the sender. A receiver receiving a SYN message with a version/sub-version higher than understood will ignore that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP = version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in the version/sub-version fields." 1. I added a non-normative appendix. This appendix will contain a = clarification of what version of the ANCP protocol draft specification = constitutes version 3.1 as soon as the WG decides on 3.1 "6. Appendix: = Handling of pre-RFC deployments of the ANCP protocol This appendix is non normative. Prior to completion of this document, several pre-RFC versions of the protocol were documented and implemented. There were numerous pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. A NAS implementing the ANCP protocol as defined in this document may, on a peer basis, use the version and sub-version fields to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers. The version and sub-version negotiation phase is part of the adjacency protocol and is performed before synchronisation is achieved." Please find new version of draft attached. I hope I've captured most of your feedback in the new draft, if not or = if you have additional comments please let me know. Best Regards, Roberta ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps Hi All, During the ITEF75 WG meeting a discussion was had on ANCP protocol = versioning and the need to revise the protocol version. A follow-up = e-mail discussion on the WG alias took place and it seems appropriate = now (if not overdue) to draw up a set of recommendations and settle the = issue: Recommended protocol draft changes and WG actions - The currently used ANCP version 3.1 is to change to 3.2 at the time of = publishing as an RFC. An instruction to execute such a change should be = placed as part of an editors' note in the next revision of = draft-ietf-ancp-protocol. This instruction is expected to only come into = effect at the time of final review past a WG last-call, which means that = until then v3.1 will be in evidence. Current implementers should make a = note of this fact. - Another note (not editorial though) should be placed in an appropriate = section, possibly Section 2 or Section 5, to convey in-brief the = historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) = based on early versions of the ANCP protocol draft. The note should be = clear in offering no guarantees in terms of backwards compatibility of = the RFC spec to those early-draft implementations. The note must also = not be seen as passing a normative reference to the early protocol = draft. - Along with the above note, the existing GSMP/ANCP version negotiation = mechanisms could be highlighted, indicating that it provides a way to = distinguish between the different versions if the adjacency = establishment negotiation mechanism followed by all is as per GSMPv3 = (rfc3292). - For the sake of clarity it is recommended that the adjacency = negotiation be more fully described in the ANCP protocol draft instead = of the current reference to rfc3292. Specifically, it would appear = reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP = protocol spec, with the re-edit describing the version negotiation = behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text = or logic statements as to the expected behaviour in case of version = differences, but such text is in evidence in the descriptive part of = Section 11.1. - The WG should identify what version of the ANCP protocol draft = specification constitutes v3.1. A non-normative reference to such a = reference could be passed in the v3.2 spec. Rationale >From a technical point of view, given that a "current" (i.e. = draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols = are identical, with any newly added functions covered as negotiable = capabilities, the version change does not appear to be fully warranted = and not fully in line with the guidelines previously laid down = (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That = said, from an operational perspective a reasonable case for such a = version change has made based and presented in = https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docume= nt.htm. Now, given that normative compliance to an interim draft (such as = draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text = which may be perceived as mandating or claiming compatibility to such = interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 and = have plans for v3.2, the version negotiation mechanism that ANCP = inherited from GSMPv3 provides a way to disambiguate the two protocols = and thus allows in theory for supporting running a pre-standard (v3.1) = and a standards compliant v3.2 on any given ANCP node. The issue of = where v3.1 is documented can be solved by using non-normative references = to one of the interim drafts. The issue of what rev of draft-ietf-ancp = is considered to be v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be extending = the protocol spec to cover issues around protocol version negotiation or = remediation of incompatibilities of draft implementations. As such no = such work is expected. We welcome clarification questions on the above. Regards, Wojciech & Matthew. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. [cid:906131214@28102009-136B]Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From lihy@huawei.com Thu Nov 5 04:41:26 2009 Return-Path: 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 BCC723A687D for ; Thu, 5 Nov 2009 04:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.238 X-Spam-Level: * X-Spam-Status: No, score=1.238 tagged_above=-999 required=5 tests=[AWL=1.577, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SUBJECT_FUZZY_TION=0.156] 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 vNalD7RHbHn1 for ; Thu, 5 Nov 2009 04:41:23 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id A9D2D3A69AF for ; Thu, 5 Nov 2009 04:41:15 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSM00MUUZ93IR@szxga01-in.huawei.com> for ancp@ietf.org; Thu, 05 Nov 2009 20:41:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSM00LU0Z92L0@szxga01-in.huawei.com> for ancp@ietf.org; Thu, 05 Nov 2009 20:41:26 +0800 (CST) Received: from l00150618 ([10.70.40.69]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSM00MSMZ8XGS@szxml04-in.huawei.com> for ancp@ietf.org; Thu, 05 Nov 2009 20:41:26 +0800 (CST) Date: Thu, 05 Nov 2009 20:41:21 +0800 From: Hongyu Li In-reply-to: To: "'Wojciech Dec (wdec)'" , HaagT@telekom.de, Lothar.Reith@detecon.com, roberta.maglione@telecomitalia.it, ancp@ietf.org, alan.kavanagh@ericsson.com, Robert.Rennison@ecitele.com, swadhwa@juniper.net, matthew.bocci@alcatel-lucent.co.uk, tom111.taylor@bell.net, Manuel.Paul@telekom.de, B.Witschurke@telekom.de Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/related; boundary="Boundary_(ID_dwtXShC1I/gqvbAyWpZ2Yw)" Thread-index: AcpA++GPna8y1YjFThasr1lRqME5vwLwMVMgAQHn4tABxRe8UAA7n/FAACxIQTAAAdj3kACIEpIgAAjG22AAAS+RMAAsglTgAGXqf6A= Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID 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: , X-List-Received-Date: Thu, 05 Nov 2009 12:41:26 -0000 This is a multi-part message in MIME format. --Boundary_(ID_dwtXShC1I/gqvbAyWpZ2Yw) Content-type: multipart/alternative; boundary="Boundary_(ID_HDX+IweVTZjtNMm3WEswhQ)" --Boundary_(ID_HDX+IweVTZjtNMm3WEswhQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi all, =20 I am working on a gap analysis between current ANCP and BBF TR-147, = which is the igniter. Partition is an important feature required by TR-147. It = would push ANCP farther away from TR-147 if we lose this feature. As for identification of a partition, I would strongly support keeping partition ID. Technically, "sender-name" may be used to identify = partitions. However, the 48 bits "sender-name" is 8 times longer as the 8 bits "partition ID". This tells that "sender-name" is more for a global identification of the peer of an AN control adjacency and may be = globally unique for management purpose, while "partition ID" is a local ID and = may be repeated over Access Nodes.=20 Replacing partition ID by "sender-name" will actually extend the length = of partition ID by no benefits. Keeping both "sender-name" and "partition = ID" as is offers us a protocol with clear hierarchies and better = expandability. =20 Hongyu _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Tuesday, November 03, 2009 7:50 PM To: HaagT@telekom.de; Lothar.Reith@detecon.com; roberta.maglione@telecomitalia.it; ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID Hi Thomas, =20 the framework is an informative document whose purpose is (was) used to = help the WG steer at a high level the protocol design. Previous discussions = have not revealed that a partition-id is needed, hence the "legacy status" of = the partition field. It's perhaps also worth noting that current = implementations largely do not support it.=20 The latest discussion about the use-case from Lothar is a new one (and = the use-case is not part of the framework), which is welcome to continue. As discussed so far, there appears to be another way for realizing this use-case, which does not require any new functionality. More opinions = along with reasons are welcome. =20 Thanks, Woj. _____ =20 From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 02 November 2009 16:09 To: Wojciech Dec (wdec); Lothar.Reith@detecon.com; roberta.maglione@telecomitalia.it; ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID All, =20 I'm really concerned about the way partition ID is beeing discussed now. = The use of partitioning is described in ANCP Framework - final version. Considering chapter 4.6.1 General Architecture, R-37,38,39,40 specifies exactly requirements for partitioning which is naturally served by using = of an appropriate partition ID.=20 >From my understanding ANCP protocol draft must follow ANCP framework requirements not having diverge work. =20 Derived from given descriptive text from ANCP framework it would be very useful for introduction in chapter "partition ID": =20 Textproposal: "The Access Node Control Mechanism is defined to operate between an = Access Node (AN) and a NAS. In such a model, the physical AN needs to be split = in virtual ANs, each having its own Access Node Control reporting and/or enforcement function. A partition ID is used for seperation of different partions in one = physical access node."=20 =20 =20 As agreed in San Francisco minutes the partition ID remains as protocol field. I strongly insist on following that agreement and keeping this field in protocol draft. =20 =20 Regards Thomas =20 _____ =20 Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Montag, 2. November 2009 14:54 An: Reith, Lothar; Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: RE: [ANCP] ANCP Versioning - next steps; partition ID Hi Lothar, =20 _____ =20 From: Reith, Lothar [mailto:Lothar.Reith@detecon.com]=20 Sent: 02 November 2009 10:39 To: Wojciech Dec (wdec); Haag, Thomas; = roberta.maglione@telecomitalia.it; ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID =20 Hi Woj, =20 I am afraid that your proposal means that we should use "sender-name" instead of "partition-ID" to identify an AN partition. =20 Known implementations use "sender-name" to convey either the management name of the AN (and the NAS/Controller respectively) or a MAC address as GSMPv3 describes. =20 Woj> The choice of what goes into the sender-name is rather arbitrary; having a name + partition-id is pretty much as the same as having a name with partition-id. Furthermore, we're now at v3.2 of ANCP... =20 So for two reasons it is not possible to use "sender name" instead of "partition ID": =20 1. The associated functionality to verify if one is talking to the = proper (intended) AN (or NAS/Controller respectively)=20 would be lost if when using the sender-id to convey the partition-ID instead of the management name of the device.=20 =20 Woj> How so? The name is an opaque value that has significance to the operator, very much like partition-id. =20 2. If a MAC address information in "sender name" would be used for "partition ID" only one partition can be used because usually a AN uses = one MAC address. So we have a conflict on networking because usually an = access node use one MAC Adresse regardles of partitioning. =20 =20 Woj> Please note that GSMP recommended the use of MAC addresses because = it was meant to run on TCP/IP. In ANCP , you can identify each AN with the = IP address and the sender-name is pretty much redudnant today. However it appears it could well be used for the use-case you described. =20 For that reasons I don't want to effectively abandon the partition-ID. I highly recommend keeping the conventions (75th meeting minutes) for partition ID as I understand they are meant to keep network scenarios = clean and avoid the mixing up of different layer informations.=20 =20 Woj> The existing "conventions" amount to partition-id beingthere, like other GSMP fields, but its use is not currently specified in ANCP. =20 Regards, Woj.=20 =20 Best Regards, =20 Lothar Reith Detecon International GmbH (Deutsche Telekom Group) _____ =20 Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Freitag, 30. Oktober 2009 18:19 An: Reith, Lothar; Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: RE: [ANCP] ANCP Versioning - next steps; partition ID Hi Lothar, =20 Having the NAS/controller verify the sender-name (as is done today), = with each partition using a different sender name, would accomplish the = use-case below, without partition-id. Any problem with this? =20 Thanks, Woj. =20 _____ =20 From: Reith, Lothar [mailto:Lothar.Reith@detecon.com]=20 Sent: 30 October 2009 17:17 To: Wojciech Dec (wdec); Haag, Thomas; = roberta.maglione@telecomitalia.it; ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID Hi Woj, dear all, =20 I fully support Thomas Haag`s point in his mail. =20 I also noticed that the following section is no longer present in the current version, and propose to re-include: =20 Partition ID: This field is a 8 bit number which signifies a partition on the AN. [ TBD How AN and NAS agree on the partition numbers. Possible options: 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; 2 - The partition ID could be statically configured on the NAS as part of configuring the neighbor information.] =20 =20 I further suggest to enhance the text as follows: =20 Partition ID: This field is a 8 bit number which signifies a partition on the AN. AN and NAS MAY agree on the partition ID using one of the following possible options: 1 - The partition ID could be configured on the AN and learnt by NAS in the adjacency message; 2 - The partition ID could be statically configured on the NAS as part of configuring the neighbor information. =20 =20 A potential use case could be in assurance, e.g. to enable verification = that the proper (intended) partition ID is used over a particular adjacency = in cases where the AN has multiple adjacencies to different NAS/Controller. = =20 Best Regards, Lothar Reith =20 Detecon International GmbH (Deutsche Telekom Group) _____ =20 Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec (wdec) Gesendet: Donnerstag, 29. Oktober 2009 19:45 An: Haag, Thomas; roberta.maglione@telecomitalia.it; ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, Manuel; Witschurke, Birgit Betreff: Re: [ANCP] ANCP Versioning - next steps; partition ID While keeping the GSMP derived partition-id in the protocol spec "as is" = is fine, a note should perhaps also be inserted stating that this field is effectively not currently used by ANCP. At least this is my recollection = of the discussion on this matter, ie partition-id is fine, but we don't = really have a use for it now given that functional partitioning is not covered = and that an AN will have 1 adjacency to each NAS/controller. =20 -Woj. _____ =20 From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 28 October 2009 15:52 To: roberta.maglione@telecomitalia.it; Wojciech Dec (wdec); = ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Manuel.Paul@telekom.de; B.Witschurke@telekom.de Subject: AW: ANCP Versioning - next steps; partition ID Hi Roberta, all, =20 thanks for providing the updated protocol draft. =20 So far I recognized that the update covers issues regarding versioning, = tech Type for GPON and Range of values of the code field. =20 But I notice on page 17 of version 07 that the whole section of = partition ID including definition is deleted. >From my understanding (and as result from the minutes) it was agreed = during 75th IETF meeting to keep the partition ID. =20 Extract from 75th IETF minutes:=20 =20 (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces extensibility. Thomas Haag: need multiple partition-ids because one might need to distinguish=20 between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational problems=20 if partition-id not available.=20 No one felt strongly -- will keep "as is". =20 So we had consensus not to remove and keep partion ID. But I didn't find = it in the whole document any more. Based on that agreements I wonder why this issue is deleted. Are there = any reasons for doing this? =20 So I recommend update the protocol draft before upcoming meeting keeping partition ID. =20 Regards =20 Thomas .=20 =20 _____ =20 Von: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Gesendet: Montag, 19. Oktober 2009 16:16 An: 'Wojciech Dec (wdec)'; ancp@ietf.org; Haag, Thomas; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com; swadhwa@juniper.net; BOCCI Matthew; 'tom111.taylor@bell.net' Betreff: RE: ANCP Versioning - next steps Hi All, I updated the ancp protocol draft following the chairs=92 = recommendations on the ANCP versioning. In particular: 1. I added some text to explain the history and rationale, at the end of section 2:=20 =93At the time of writing of this specification some implementations of = the ANCP protocol, based on pre-standards drafts are already available. All these early-draft implementations use protocol version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.2 [Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] Adopting a new sub-version value provides a way to disambiguate the two protocols and allows for supporting running a pre-standard and a standards compliant ANCP implementation on any given ANCP node. The mechanism used to identify the protocol version/sub-version is part of the adjacency negotiation process and it is described in details in Section 5.2. It is important to note that this mechanism does not guarantee backwards compatibility of the ANCP RFC specification to those early-draft implementations.=94 2. I explained the version/sub-version negotiation process in section 5.2:=20 =93ANCP uses version 3 and sub-version 1 of GSMP protocol. [RFC Editor's note: sub-version needs to be changed from 1 to 2 upon publication.] In the adjacency protocol the version and the sub- version fields are used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the version/sub-version fields always contain the highest version understood by the sender. A receiver receiving a SYN message with a version/sub-version higher than understood will ignore that message. A receiver receiving a SYN message with a version/ sub-vresion lower than its own highest version/sub-version, but a version/sub-version that it understands, will reply with a SYNACK with the version/sub-version from the received SYN in its ANCP version/sub-version fields. This defines the version/sub-version of the ANCP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in the version/sub-version fields.=94 =20 3. I added a non-normative appendix. This appendix will contain a clarification of what version of the ANCP protocol draft specification constitutes version 3.1 as soon as the WG decides on 3.1=20 =936. Appendix: Handling of pre-RFC deployments of the ANCP protocol =20 This appendix is non normative. =20 Prior to completion of this document, several pre-RFC versions of the protocol were documented and implemented. There were numerous pre- standard versions of the protocol all using a version/sub-version fields set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document may, on a peer basis, use the version and sub-version fields to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers. The version and sub-version negotiation phase is part of the adjacency protocol and is performed before synchronisation is achieved.=94 =20 Please find new version of draft attached. I hope I=92ve captured most of your feedback in the new draft, if not or = if you have additional comments please let me know. =20 Best Regards, Roberta =20 _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Wednesday, October 14, 2009 1:07 PM To: ancp@ietf.org Subject: [ANCP] FW: ANCP Versioning - next steps =20 =20 Hi All,=20 During the ITEF75 WG meeting a discussion was had on ANCP protocol versioning and the need to revise the protocol version. A follow-up = e-mail discussion on the WG alias took place and it seems appropriate now (if = not overdue) to draw up a set of recommendations and settle the issue: Recommended protocol draft changes and WG actions=20 - The currently used ANCP version 3.1 is to change to 3.2 at the time of publishing as an RFC. An instruction to execute such a change should be placed as part of an editors' note in the next revision of draft-ietf-ancp-protocol. This instruction is expected to only come into effect at the time of final review past a WG last-call, which means that until then v3.1 will be in evidence. Current implementers should make a = note of this fact. - Another note (not editorial though) should be placed in an appropriate section, possibly Section 2 or Section 5, to convey in-brief the = historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) based on = early versions of the ANCP protocol draft. The note should be clear in = offering no guarantees in terms of backwards compatibility of the RFC spec to those early-draft implementations. The note must also not be seen as passing a normative reference to the early protocol draft.=20 - Along with the above note, the existing GSMP/ANCP version negotiation mechanisms could be highlighted, indicating that it provides a way to distinguish between the different versions if the adjacency = establishment negotiation mechanism followed by all is as per GSMPv3 (rfc3292). - For the sake of clarity it is recommended that the adjacency = negotiation be more fully described in the ANCP protocol draft instead of the = current reference to rfc3292. Specifically, it would appear reasonable to adopt = and re-edit Section 11.2 of rfc3292 into the ANCP protocol spec, with the re-edit describing the version negotiation behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text or logic statements as to the expected behaviour in case of version differences, but such text is in evidence in the descriptive part of Section 11.1. - The WG should identify what version of the ANCP protocol draft specification constitutes v3.1. A non-normative reference to such a reference could be passed in the v3.2 spec. Rationale=20 >From a technical point of view, given that a "current" (i.e. draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols = are identical, with any newly added functions covered as negotiable capabilities, the version change does not appear to be fully warranted = and not fully in line with the guidelines previously laid down ( http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That = said, from an operational perspective a reasonable case for such a version = change has made based and presented in https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docume= nt. htm.=20 Now, given that normative compliance to an interim draft (such as draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text = which may be perceived as mandating or claiming compatibility to such interim drafts needs to be avoided. In the case of vendors and operators that already support/use v3.1 and = have plans for v3.2, the version negotiation mechanism that ANCP inherited = from GSMPv3 provides a way to disambiguate the two protocols and thus allows = in theory for supporting running a pre-standard (v3.1) and a standards compliant v3.2 on any given ANCP node. The issue of where v3.1 is = documented can be solved by using non-normative references to one of the interim drafts. The issue of what rev of draft-ietf-ancp is considered to be = v3.1 needs to be clarified. Other than the above the WG is currently not chartered to be extending = the protocol spec to cover issues around protocol version negotiation or remediation of incompatibilities of draft implementations. As such no = such work is expected. We welcome clarification questions on the above.=20 Regards,=20 Wojciech & Matthew.=20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. = Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati = di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the = intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=20 rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non = =E8 necessario.=20 --Boundary_(ID_HDX+IweVTZjtNMm3WEswhQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable FW: ANCP = Versioning - next steps
Hi all,
 
I am working on a gap analysis between=20 current ANCP and BBF TR-147, which is the igniter. Partition is an=20 important feature required by TR-147. It would push ANCP farther away = from=20 TR-147 if we lose this feature.
As for identification of a partition, I would = strongly=20 support keeping partition ID. Technically, "sender-name" may be used to = identify=20 partitions.  However, the 48 bits "sender-name" is 8 times longer = as the 8=20 bits "partition ID". This tells that "sender-name" is more for a global=20 identification of the peer of an AN control adjacency and may be = globally unique=20 for management purpose, while "partition ID" is a local ID and may be = repeated=20 over Access Nodes.
Replacing partition ID by "sender-name" = will=20 actually extend the length of partition ID by no benefits. Keeping both=20 "sender-name" and "partition ID" as is offers us a protocol with clear=20 hierarchies and better expandability.
 
Hongyu

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: Tuesday, November 03, 2009 7:50 PM
To:=20 HaagT@telekom.de; Lothar.Reith@detecon.com; = roberta.maglione@telecomitalia.it;=20 ancp@ietf.org; alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk; = tom111.taylor@bell.net;=20 Manuel.Paul@telekom.de; B.Witschurke@telekom.de
Subject: Re: = [ANCP]=20 ANCP Versioning - next steps; partition ID

Hi Thomas,
 
the framework is an informative document whose purpose is = (was) used=20 to help the WG steer at a high level the protocol design. Previous=20 discussions have not revealed that a partition-id is needed, hence the = "legacy=20 status" of the partition field. It's perhaps also worth noting that = current=20 implementations largely do not support it.
The latest discussion about the use-case from Lothar is a = new one=20 (and the use-case is not part of the framework), which is welcome to = continue.=20 As discussed so far, there appears to be another way for realizing this=20 use-case, which does not require any new functionality. More opinions = along with=20 reasons are welcome.
 
Thanks,
Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 02 November 2009=20 16:09
To: Wojciech Dec (wdec); Lothar.Reith@detecon.com;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net;=20 Manuel.Paul@telekom.de; B.Witschurke@telekom.de
Subject: AW: = [ANCP]=20 ANCP Versioning - next steps; partition ID

All,
 
I'm really concerned about the way = partition ID is=20 beeing discussed now.
The use of partitioning is described in = ANCP=20 Framework - final version.
Considering chapter 4.6.1 General = Architecture,=20 R-37,38,39,40 specifies exactly requirements for partitioning which is = naturally served by using of an appropriate partition ID. =
From my = understanding ANCP=20 protocol draft must follow ANCP framework requirements not=20 having diverge work.
 
Derived from given descriptive text from = ANCP=20 framework it would be very useful for introduction in chapter = "partition=20 ID":
 
Textproposal:
 "The Access Node Control Mechanism is = defined=20 to operate between an Access Node (AN) and a NAS.  In such a = model, the=20 physical AN needs to be split in virtual ANs, each = having
   its=20 own Access Node Control reporting and/or enforcement function.=20 A partition ID is used for seperation=20 of different partions in one physical access node." =
 
 
As agreed in San Francisco minutes = the partition=20 ID remains as protocol field.
I strongly insist on following that = agreement=20 and keeping this field in protocol draft.
 
 
Regards
Thomas
 

Von: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Gesendet: Montag, 2. November 2009=20 14:54
An: Reith, Lothar; Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, = Manuel;=20 Witschurke, Birgit
Betreff: RE: [ANCP] ANCP Versioning - = next steps;=20 partition ID

Hi Lothar,
 
From: Reith, Lothar=20 [mailto:Lothar.Reith@detecon.com]
Sent: 02 November 2009=20 10:39
To: Wojciech Dec (wdec); Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org; = alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; Paul, = Manuel;=20 Witschurke, Birgit
Subject: AW: [ANCP] ANCP Versioning - = next steps;=20 partition ID

 
Hi Woj,
 
I am afraid that your proposal means that = we=20 should use =20 "sender-name" instead=20 of "partition-ID" to = identify an=20 AN partition.
 
Known=20 implementations use  "sender-name" to convey either the management name of the = AN (and=20 the NAS/Controller respectively) or = a MAC=20 address as GSMPv3 = describes.
 
Woj> = The choice=20 of what goes into the sender-name is rather arbitrary; having a name = +=20 partition-id is pretty much as the same as having a name with=20 partition-id.
Furthermore, we're=20 now at v3.2 of ANCP...
 
So for = two reasons=20 it is not possible to use "sender name" instead of "partition=20 ID":
 
1.=20 The associated functionality to verify if = one is=20 talking to the proper (intended) AN (or NAS/Controller=20 respectively) 
    would be = lost=20 if when using the sender-id to convey the partition-ID = instead of=20 the management name of the device. 
 
Woj> = How so? The=20 name is an opaque value that has significance to the operator, very = much=20 like partition-id.

 
2. If a MAC address = information in "sender=20 name" would be used for "partition ID" only one partition can be = used=20 because usually a AN uses one MAC address. So we have a conflict on=20 networking because usually an access node use one MAC Adresse = regardles of=20 partitioning.  
&nbs= p;
Woj> Please note that GSMP recommended the use of = MAC=20 addresses because it was meant to run on TCP/IP. In ANCP , you = can=20 identify each AN with the IP = address and the=20 sender-name is pretty much redudnant today. However it appears it = could well=20 be used for the use-case you=20 described.
 
For that reasons I don't want to = effectively=20 abandon the partition-ID. I highly = recommend=20 keeping the conventions (75th meeting minutes) for partition ID = as I understand they=20 are meant to keep = network=20 scenarios clean and avoid the=20 mixing up of = different=20 layer informations. 
 
Woj> The=20 existing "conventions" amount to partition-id beingthere, = like=20 other GSMP fields, but its use is not currently specified in=20 ANCP.
 
Regards,=
Woj. 
&nbs= p;
Best=20 Regards,
&nbs= p;
Lothar=20 Reith
Detecon=20 International GmbH (Deutsche Telekom=20 = Group)
=
Von: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Gesendet: Freitag, 30. Oktober = 2009=20 18:19
An: Reith, Lothar; Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke,=20 Birgit
Betreff: RE: [ANCP] ANCP Versioning - next steps; = partition ID

Hi Lothar,
 
Having the NAS/controller verify the sender-name (as = is done=20 today), with each partition using a different sender name, = would=20 accomplish the use-case below, without partition-id. Any problem = with=20 this?
 
Thanks,
Woj.
 

From: Reith, Lothar=20 [mailto:Lothar.Reith@detecon.com]
Sent: 30 October = 2009=20 17:17
To: Wojciech Dec (wdec); Haag, Thomas;=20 roberta.maglione@telecomitalia.it; ancp@ietf.org;=20 alan.kavanagh@ericsson.com; Robert.Rennison@ecitele.com;=20 swadhwa@juniper.net; matthew.bocci@alcatel-lucent.co.uk;=20 tom111.taylor@bell.net; Paul, Manuel; Witschurke,=20 Birgit
Subject: AW: [ANCP] ANCP Versioning - next = steps;=20 partition ID

Hi = Woj, dear=20 all,
 
I fully support Thomas = Haag`s point in=20 his mail.
 
I also noticed that the = following=20 section is no longer present in the current version, and propose = to=20 re-include:
 
Partition=20 ID:

      This field is a 8 bit = number=20 which signifies a partition on = the
      AN.=20 [ TBD How AN and NAS agree on the partition numbers. =20 Possible
     =20 options:

      1 - The partition = ID=20 could be configured on the AN and learnt=20 by
      NAS in the adjacency=20 message;

      2 - The partition = ID=20 could be statically configured on the NAS=20 as
      part of configuring the = neighbor=20 information.]
 
 
I further suggest to enhance the text = as=20 follows:
 
Partition=20 ID:

      This field is a 8 bit = number=20 which signifies a partition on = the
     =20 AN.  AN and NAS MAY agree on the partition ID using one of = the=20 following possible
     =20 options:

      1 - The partition = ID=20 could be configured on the AN and learnt=20 by
      NAS in the adjacency=20 message;

      2 - The partition = ID=20 could be statically configured on the NAS=20 as
      part of configuring the = neighbor=20 information.
 
 
A potential use case could be in = assurance,=20 e.g. to enable verification that the proper=20 (intended) partition ID is used over a = particular adjacency in=20 cases where the AN has multiple adjacencies to different=20 NAS/Controller. 
 
 Best Regards, Lothar=20 Reith
 
Detecon International GmbH (Deutsche = Telekom=20 Group)

Von: ancp-bounces@ietf.org = [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech = Dec=20 (wdec)
Gesendet: Donnerstag, 29. Oktober 2009=20 19:45
An: Haag, Thomas; = roberta.maglione@telecomitalia.it;=20 ancp@ietf.org; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net; = Paul,=20 Manuel; Witschurke, Birgit
Betreff: Re: [ANCP] ANCP=20 Versioning - next steps; partition ID

While keeping the GSMP derived partition-id = in the=20 protocol spec "as is" is fine, a note should perhaps also be = inserted=20 stating that this field is effectively not currently used by = ANCP. At=20 least this is my recollection of the discussion on this = matter, ie=20 partition-id is fine, but we don't really have a use for it = now given=20 that functional partitioning is not covered and that an AN = will have 1=20 adjacency to each NAS/controller.
 
-Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 28 October 2009=20 15:52
To: roberta.maglione@telecomitalia.it; = Wojciech Dec=20 (wdec); ancp@ietf.org; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net;=20 matthew.bocci@alcatel-lucent.co.uk; tom111.taylor@bell.net;=20 Manuel.Paul@telekom.de; = B.Witschurke@telekom.de
Subject:=20 AW: ANCP Versioning - next steps; partition = ID

Hi Roberta, = all,
 
thanks for providing = the updated=20 protocol draft.
 
So far I recognized = that the update=20 covers issues regarding versioning, tech Type for GPON and = Range of=20 values of the code field.
 
But I notice on page = 17 of version=20 07 that the whole section of partition ID including = definition is=20 deleted.
From my understanding = (and as=20 result from the minutes) it was agreed during 75th IETF = meeting=20 to keep the partition ID.
 
Extract from 75th = IETF minutes:=20
 
(1)=20 Partition-id
    ------------
Sanjay: = concerned=20 that removing the partition-id reduces = extensibility.
Thomas=20 Haag: need multiple partition-ids because one might need to=20 distinguish
between BRASs when expanding the = network.
Woj:=20 send e-mail. Thomas: already did. Makes for operational = problems=20
if partition-id not available.
No one felt strongly = -- will=20 keep "as is".
 
So we = had consensus not to=20 remove and keep partion ID. But I didn't find it in the = whole=20 document any more.
Based on that agreements I wonder why this issue is = deleted. Are there any = reasons for=20 doing this?
 
So I recommend update = the protocol=20 draft before upcoming meeting keeping partition=20 ID.
 
Regards
 
Thomas
.
 

Von: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it] =
Gesendet:=20 Montag, 19. Oktober 2009 16:16
An: 'Wojciech Dec = (wdec)';=20 ancp@ietf.org; Haag, Thomas; alan.kavanagh@ericsson.com;=20 Robert.Rennison@ecitele.com; swadhwa@juniper.net; BOCCI = Matthew;=20 'tom111.taylor@bell.net'
Betreff: RE: ANCP = Versioning -=20 next steps

Hi All,

     I updated the ancp = protocol=20 draft following the chairs=92 recommendations on the ANCP=20 versioning.

In particular:

  1. I added=20 some text to explain the history and rationale, at the end = of=20 section 2:

 =93At the time of writing of this specification = some=20 implementations of the ANCP protocol, based on pre-standards = drafts=20 are already available.  All these early-draft = implementations=20 use protocol

   version/sub-version 3.1; standard = ANCP=20 protocol will use version/

   sub-version 3.2 [Editor's note: = sub-version=20 needs to be changed from

   1 to 2 upon publication.]  = Adopting a=20 new sub-version value provides

   a way to disambiguate the two = protocols and=20 allows for supporting

   running a pre-standard and a = standards=20 compliant ANCP implementation

   on any given ANCP node.  The = mechanism=20 used to identify the protocol

   version/sub-version is part of the = adjacency=20 negotiation process and

   it is described in details in = Section=20 5.2.  It is important to = note

   that this mechanism does not = guarantee=20 backwards compatibility of the

   ANCP RFC specification to those = early-draft=20 implementations.=94

  1. I explained=20 the version/sub-version negotiation process in section=20 5.2:

=93ANCP uses version 3 and sub-version 1 of = GSMP=20 protocol.

   [RFC Editor's note: sub-version = needs to be=20 changed from 1 to 2 upon

   publication.]  In the = adjacency=20 protocol the version and the = sub-

   version fields are used for = version=20 negotiation.  The version

   negotiation is performed before=20 synchronisation is achieved.  In = a

   SYN message the = version/sub-version fields=20 always contain the highest

   version understood by the = sender.  A=20 receiver receiving a SYN = message

   with a version/sub-version higher = than=20 understood will ignore that

   message.  A receiver = receiving a SYN=20 message with a version/

   sub-vresion lower than its own = highest=20 version/sub-version, but a

   version/sub-version that it = understands,=20 will reply with a SYNACK

   with the version/sub-version from = the=20 received SYN in its ANCP version/sub-version fields.  = This=20 defines the version/sub-version = of

   the ANCP protocol to be used while = the=20 adjacency protocol remains

   synchronised.  All other = messages will=20 use the agreed version in the

   version/sub-version=20 fields.=94

 

  1. I added a=20 non-normative appendix. This appendix will contain a clarification of = what=20 version of the ANCP protocol draft specification = constitutes=20 version 3.1 as soon as the WG decides on = 3.1

=936.  Appendix: Handling of pre-RFC = deployments of=20 the ANCP  protocol

 

   This appendix is non=20 normative.

 

   Prior to completion of this = document,=20 several pre-RFC versions of the

   protocol were documented and=20 implemented.  There were numerous=20 pre-

   standard versions of the protocol = all using=20 a version/sub-version

   fields set to=20 3.1.

 

   A NAS implementing the ANCP = protocol as=20 defined in this document may,

   on a peer basis, use the version = and=20 sub-version fields to detect a

   pre-RFC implementation of the = protocol and=20 choose to work with such

   pre-RFC peers.  The version = and=20 sub-version negotiation phase is = part

   of the adjacency protocol and is = performed=20 before synchronisation is

   = achieved.=94

 

Please find new version of draft=20 attached.

I hope I=92ve captured most of your feedback in = the new=20 draft, if not or if you have additional comments please let = me=20 know.

 

Best Regards,

Roberta

 

From: = ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On Behalf Of Wojciech = Dec=20 (wdec)
Sent:=20 Wednesday, October 14, 2009 1:07 PM
To: ancp@ietf.org
Subject: [ANCP] FW: = ANCP=20 Versioning - next steps

 

 

Hi=20 All,

During the=20 ITEF75 WG meeting a discussion was had on ANCP protocol = versioning=20 and the need to revise the protocol version. A follow-up = e-mail=20 discussion on the WG alias took place and it seems = appropriate=20 now (if not = overdue) to draw up a set of recommendations = and=20 settle the issue:

Recommended=20 protocol draft changes and WG=20 actions=20

- = The=20 currently used ANCP version 3.1 is to change to 3.2 at the = time of=20 publishing as an RFC. An instruction to execute such a = change should=20 be placed as part of an editors' note in the next revision = of=20 draft-ietf-ancp-protocol. This instruction is expected to = only come=20 into effect at the time of final review past a WG last-call, = which=20 means that until then v3.1 will be in evidence. Current = implementers=20 should make a note of this = fact.

- = Another=20 note (not editorial though) should be placed in an = appropriate=20 section, possibly Section 2 or Section 5, to convey in-brief = the=20 historic aspect of GSMP/ANCP v3.1 implementations, which are = (were?)=20 based on early versions of the ANCP protocol draft. The note = should=20 be clear in offering no guarantees in terms of backwards=20 compatibility of the RFC spec to those early-draft = implementations.=20 The note must also not be seen as passing a normative = reference to=20 the early protocol draft.

- = Along with=20 the above note, the existing GSMP/ANCP version negotiation=20 mechanisms could be highlighted, indicating that it provides = a way=20 to distinguish between the different versions if the = adjacency=20 establishment negotiation mechanism followed by all is as = per GSMPv3=20 (rfc3292).

- = For the=20 sake of clarity it is recommended that the adjacency = negotiation be=20 more fully described in the ANCP protocol draft instead of = the=20 current reference to rfc3292. Specifically, it would appear=20 reasonable to adopt and re-edit Section 11.2 of rfc3292 into = the=20 ANCP protocol spec, with the re-edit describing the version=20 negotiation behaviour. Rather confusingly Rfc3292 Section = 11.2 does=20 not carry text or logic statements as to the expected = behaviour in=20 case of version differences, but such text is in evidence in = the=20 descriptive part of Section = 11.1.

- The WG should identify what version of the = ANCP=20 protocol draft specification constitutes v3.1. A = non-normative=20 reference to such a reference could be passed in the v3.2=20 spec.

Rationale=20

From a=20 technical point of view, given that a "current" (i.e. draft-ietf-protocol-06 based) and future = (i.e. ANCP RFC = based)=20 protocols are identical, with any newly = added functions covered as=20 negotiable=20 capabilities, the version change does not appear to = be=20 fully = warranted and not fully in line with the = guidelines=20 previously laid down (= http://www.ietf.org/mail-archive/web/ancp/current/msg00152.h= tml). That said, from an = operational perspective a=20 reasonable case for such a = version=20 change has made based=20 and=20 presented in https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_fi= les/v3_document.htm.

Now, given that=20 normative compliance to an interim draft (such = as draft-ietf-protocol-06 = based) cannot be=20 passed by the ANCP RFC, text which may be perceived=20 as mandating or claiming compatibility to such  interim = drafts needs=20 to be avoided.

In the case=20 of=20 vendors and=20 operators that already=20 support/use v3.1 and have plans for v3.2, the version = negotiation=20 mechanism that ANCP inherited from GSMPv3 provides a way to=20 disambiguate the two protocols and thus allows = in theory=20 for = supporting=20 running a pre-standard (v3.1) and a standards=20 compliant v3.2 on any given ANCP node. The issue of where v3.1 is documented = can be=20 solved by using non-normative references to one of the = interim=20 drafts. The issue of what rev of draft-ietf-ancp is = considered to be=20 v3.1 needs to be=20 clarified.

Other than=20 the above the WG is currently not chartered to be = extending the=20 protocol spec to cover issues around protocol version = negotiation or=20 remediation of incompatibilities of draft = implementations. As such no such = work is=20 expected.

We welcome clarification questions on the=20 above. =

Regards,
Wojciech &=20 Matthew.=20

Questo=20 messaggio e i suoi allegati sono indirizzati = esclusivamente=20 alle persone indicate. La diffusione, copia o = qualsiasi altra=20 azione derivante dalla conoscenza di queste = informazioni sono=20 rigorosamente vietate. Qualora abbiate ricevuto questo = documento per errore siete cortesemente pregati di = darne=20 immediata comunicazione al mittente e di provvedere = alla sua=20 distruzione, Grazie.

This e-mail and any = attachments is confidential and may contain privileged = information=20 intended for the addressee(s) only. Dissemination, = copying,=20 printing or use by anybody else is unauthorised. If = you are=20 not the intended recipient, please delete this message = and any=20 attachments and advise the sender by return e-mail,=20 Thanks.

Rispetta l'ambiente. Non = stampare questa=20 mail se non =E8 necessario.=20 =

<= /BLOCKQUOTE> --Boundary_(ID_HDX+IweVTZjtNMm3WEswhQ)-- --Boundary_(ID_dwtXShC1I/gqvbAyWpZ2Yw) Content-id: <930201412@05112009-014E> Content-type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-transfer-encoding: base64 Content-disposition: attachment; filename="logo Ambiente_foglia.jpg" R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --Boundary_(ID_dwtXShC1I/gqvbAyWpZ2Yw)-- From Matthew.Bocci@alcatel-lucent.com Thu Nov 5 06:13:46 2009 Return-Path: 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 CC8A028C1CF for ; Thu, 5 Nov 2009 06:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 nYJzCBnRIUol for ; Thu, 5 Nov 2009 06:13:46 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id BF31B28C1D3 for ; Thu, 5 Nov 2009 06:13:44 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nA5EE24J003078 for ; Thu, 5 Nov 2009 15:14:05 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.36]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 15:14:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5E22.3B364777" Date: Thu, 5 Nov 2009 15:14:04 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A04C3A40D@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF76 Slides Thread-Index: AcpeIjrNJgzFiDqiSEi7QNI5KuKemw== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 05 Nov 2009 14:14:05.0345 (UTC) FILETIME=[3B7D5910:01CA5E22] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: [ANCP] IETF76 Slides 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: , X-List-Received-Date: Thu, 05 Nov 2009 14:13:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5E22.3B364777 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, If you have a slot in Hiroshima, please can you send your slides to me and Woj by Tuesday 10th November at the earliest?=20 This is to give us time to upload the slides and for attendees to read them in advance. Best regards Matthew ------_=_NextPart_001_01CA5E22.3B364777 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF76 Slides

All,

If you have a slot in Hiroshima, please can you send your slides to = me and Woj by Tuesday = 10th = November at = the earliest? =

This is to give us = time to = upload the slides and for attendees to read them in = advance.

Best = regards

Matthew

------_=_NextPart_001_01CA5E22.3B364777-- From Matthew.Bocci@alcatel-lucent.com Thu Nov 5 06:15:29 2009 Return-Path: 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 555D228C1CE for ; Thu, 5 Nov 2009 06:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Awm0sXrrsqXm for ; Thu, 5 Nov 2009 06:15:28 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 17E2628C1C0 for ; Thu, 5 Nov 2009 06:15:27 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nA5EFn8b009473 for ; Thu, 5 Nov 2009 15:15:49 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.36]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 15:15:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5E22.793AC68B" Date: Thu, 5 Nov 2009 15:15:48 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A04C3A411@FRVELSMBS11.ad2.ad.alcatel.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A04C3A40D@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] IETF76 Slides Thread-Index: AcpeIjrNJgzFiDqiSEi7QNI5KuKemwAADDgQ References: <0458D2EE0C36744BABB36BE37805C29A04C3A40D@FRVELSMBS11.ad2.ad.alcatel.com> From: "BOCCI Matthew" To: "BOCCI Matthew" , X-OriginalArrivalTime: 05 Nov 2009 14:15:49.0395 (UTC) FILETIME=[79821E30:01CA5E22] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [ANCP] IETF76 Slides 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: , X-List-Received-Date: Thu, 05 Nov 2009 14:15:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5E22.793AC68B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Correction, please send us the slides by Sunday 8th November. =20 Matthew =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: 05 November 2009 14:14 To: ancp@ietf.org Subject: [ANCP] IETF76 Slides =20 All, If you have a slot in Hiroshima, please can you send your slides to me and Woj by Tuesday 10th November at the earliest?=20 This is to give us time to upload the slides and for attendees to read them in advance. Best regards Matthew ------_=_NextPart_001_01CA5E22.793AC68B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF76 Slides

Correction, please send us the = slides by Sunday 8th November.

 

Matthew

=

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOCCI Matthew
Sent: 05 November 2009 = 14:14
To: ancp@ietf.org
Subject: [ANCP] IETF76 = Slides

 

All,

If you have a slot in Hiroshima, please can you send your slides to me and = Woj by Tuesday 10th November = at = the earliest?

This is to give us time to upload the = slides and for attendees to read them in advance.

Best regards

Matthew

------_=_NextPart_001_01CA5E22.793AC68B-- From bwelch@juniper.net Thu Nov 5 20:08:09 2009 Return-Path: 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 A286A3A6A2A for ; Thu, 5 Nov 2009 20:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] 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 WY11Yud01mq8 for ; Thu, 5 Nov 2009 20:08:07 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 50A653A6895 for ; Thu, 5 Nov 2009 20:08:07 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSvOhO0LgL4JVWy1HpVYq1oxJ5eMUMXwt@postini.com; Thu, 05 Nov 2009 20:08:30 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 5 Nov 2009 20:06:32 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 5 Nov 2009 23:06:31 -0500 From: Bill Welch To: "ancp@ietf.org" Date: Thu, 5 Nov 2009 23:06:29 -0500 Thread-Topic: We need to add Partition ID back into ANCP spec Thread-Index: AcpeloRl60TmRDFCTfmF0KZJiuMWhg== Message-ID: <13205C286662DE4387D9AF3AC30EF456AFA9A1A551@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456AFA9A1A551EMBX01WFjnprn_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 06 Nov 2009 04:01:49 -0800 Cc: "Manuel.Paul@telekom.de" , "HaagT@telekom.de" Subject: [ANCP] We need to add Partition ID back into ANCP spec 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: , X-List-Received-Date: Fri, 06 Nov 2009 04:08:09 -0000 --_000_13205C286662DE4387D9AF3AC30EF456AFA9A1A551EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To all, I have been monitoring the discussion from a far but I want to make two poi= nts on this topic. There are implementations that include the use of Partition ID. What is the underlying technical reason for it's removal? If there is no overwelming reason for it's removal it should remain until i= t's proven completely unnecessary. I don't think it really causes issue wi= th implementations to keep partition ID. There have been several people who have easily made the case to keep it at = this time. And what is going on with the procedural issue here? There was a noted agr= eement in the meeting minutes but this agreement has been ignored. Best regards, Bill Welch Juniper Networks --_000_13205C286662DE4387D9AF3AC30EF456AFA9A1A551EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To all,

 

I have been monitoring the discussion from a far but I w= ant to make two points on this topic.

 

There are implementations that include the use of Partit= ion ID.

 

What is the underlying technical reason for it’s r= emoval?

 

If there is no overwelming reason for it’s removal= it should remain until it’s proven completely unnecessary.  I don’t = think it really causes issue with implementations to keep partition ID. 

 

There have been several people who have easily made the = case to keep it at this time.

 

And what is going on with the procedural issue here? &nb= sp;There was a noted agreement in the meeting minutes but this agreement has been ignored.

 

Best regards,

Bill Welch

Juniper Networks

 

 

 

 

 

--_000_13205C286662DE4387D9AF3AC30EF456AFA9A1A551EMBX01WFjnprn_-- From roberta.maglione@telecomitalia.it Fri Nov 6 05:15:49 2009 Return-Path: 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 6D1873A635F for ; Fri, 6 Nov 2009 05:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.408 X-Spam-Level: X-Spam-Status: No, score=0.408 tagged_above=-999 required=5 tests=[AWL=0.970, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, SUBJECT_FUZZY_TION=0.156] 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 w+fjYHGYv+C5 for ; Fri, 6 Nov 2009 05:15:44 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 575E13A67C2 for ; Fri, 6 Nov 2009 05:15:43 -0800 (PST) Content-Type: multipart/mixed; boundary="_1519f2f6-5e23-4578-a2e5-10e2c52072d5_" Received: from grfhub705ba020.griffon.local (10.188.101.118) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 6 Nov 2009 14:16:04 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub705ba020.griffon.local ([10.188.101.118]) with mapi; Fri, 6 Nov 2009 14:16:04 +0100 From: Maglione Roberta To: 'Bill Welch' , "ancp@ietf.org" , "Matthew.Bocci@alcatel-lucent.com" , "wdec@cisco.com" Date: Fri, 6 Nov 2009 14:16:03 +0100 Thread-Topic: We need to add Partition ID back into ANCP spec Thread-Index: AcpeloRl60TmRDFCTfmF0KZJiuMWhgAS5a6w Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3E6877B5A1@GRFMBX704BA020.griffon.local> References: <13205C286662DE4387D9AF3AC30EF456AFA9A1A551@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456AFA9A1A551@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "Manuel.Paul@telekom.de" , "HaagT@telekom.de" Subject: Re: [ANCP] We need to add Partition ID back into ANCP spec 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: , X-List-Received-Date: Fri, 06 Nov 2009 13:15:49 -0000 --_1519f2f6-5e23-4578-a2e5-10e2c52072d5_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3E6877B5A1GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3E6877B5A1GRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Bill and All, http://tools.ietf.org/html/draft-ietf-ancp-protocol-07 Partition ID has NOT been removed from the ancp protocol draft, if you chec= k the draft it is there on page 18. "Partition ID: This field is a 8 bit number which signifies a partition on the AN." The only thing removed compare to version -06 are the two options that coul= d be used to select the partition ID, because my interpretation (but I may= have miss understood the discussion) of the meeting minutes "keep as-is" w= as keep original text for Partition ID thus without including a clarificati= on on the different ways to select it. Again Partition ID is still part of the version -07 of the ancp draft and t= he two options to select it will be put back in version 08. Regards, Roberta ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Bil= l Welch Sent: Friday, November 06, 2009 5:06 AM To: ancp@ietf.org Cc: Manuel.Paul@telekom.de; HaagT@telekom.de Subject: [ANCP] We need to add Partition ID back into ANCP spec To all, I have been monitoring the discussion from a far but I want to make two poi= nts on this topic. There are implementations that include the use of Partition ID. What is the underlying technical reason for it's removal? If there is no overwelming reason for it's removal it should remain until i= t's proven completely unnecessary. I don't think it really causes issue wi= th implementations to keep partition ID. There have been several people who have easily made the case to keep it at = this time. And what is going on with the procedural issue here? There was a noted agr= eement in the meeting minutes but this agreement has been ignored. Best regards, Bill Welch Juniper Networks Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non ? necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE3E6877B5A1GRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

He= llo Bill and All,

http://tools.ietf.org/html/draft-ietf-ancp-protocol-07

 

Par= tition ID has NOT been removed from the ancp protocol draft, if you check t= he draft it is there on page 18.

 

“Par=
tition ID:
      This field is a 8 bit number=
 which signifies a partition on the
      AN.”=

 

The= only thing removed compare to version -06 are the two options that could b= e used to select the partition ID, because my interpretation  (but I may have miss understood the discussion) of th= e meeting minutes “keep as-is” was keep original text for Parti= tion ID thus without including a clarification on the different ways to sel= ect it.

 

Aga= in Partition ID is still part of the version -07 of the ancp draft and the = two options to select it will be put back in version 08.

 

Reg= ards,

Rob= erta

 

 

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Bill Welch
Sent: Friday, November 06, 2= 009 5:06 AM
To: ancp@ietf.org
Cc: Manuel.Paul@telekom.de; = HaagT@telekom.de
Subject: [ANCP] We need to a= dd Partition ID back into ANCP spec=

 

To all,

 

I have been monitoring the discussion from a far = but I want to make two points on this topic.

 

There are implementations that include the use of= Partition ID.

 

What is the underlying technical reason for it= 217;s removal?

 

If there is no overwelming reason for it’s = removal it should remain until it’s proven completely unnecessary. &n= bsp;I don’t think it really causes issue with implementations to keep partition ID.  =

 

There have been several people who have easily ma= de the case to keep it at this time.

 

And what is going on with the procedural issue he= re?  There was a noted agreement in the meeting minutes but this agree= ment has been ignored.

 

Best regards,

B= ill Welch<= /span>

Juniper Networks

 

 

 

 

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3E6877B5A1GRFMBX704BA02_-- --_1519f2f6-5e23-4578-a2e5-10e2c52072d5_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_1519f2f6-5e23-4578-a2e5-10e2c52072d5_-- From root@core3.amsl.com Sun Nov 8 21:00:02 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 725F728C0E5; Sun, 8 Nov 2009 21:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109050002.725F728C0E5@core3.amsl.com> Date: Sun, 8 Nov 2009 21:00:02 -0800 (PST) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-protocol-08.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: , X-List-Received-Date: Mon, 09 Nov 2009 05:00:02 -0000 --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 : Protocol for Access Node Control Mechanism in Broadband Networks Author(s) : S. Wadhwa, et al. Filename : draft-ietf-ancp-protocol-08.txt Pages : 59 Date : 2009-11-08 This document describes proposed extensions to the GSMPv3 protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). These proposed extensions are required to realize a protocol for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK]. The resulting protocol with the proposed extensions to GSMPv3 [RFC3292] is referred to as "Access Node Control Protocol" (ANCP). This document currently focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM as described in ANCP framework document [ANCP-FRAMEWORK]. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases in detail. Illustrative text for the use-cases is included here to help the protocol implementer understand the greater context of ANCP protocol interactions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-08.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-protocol-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-08205139.I-D@ietf.org> --NextPart-- From wdec@cisco.com Mon Nov 9 01:46:53 2009 Return-Path: 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 1795A3A6876 for ; Mon, 9 Nov 2009 01:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.668 X-Spam-Level: X-Spam-Status: No, score=-5.668 tagged_above=-999 required=5 tests=[AWL=-3.106, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, SUBJECT_FUZZY_TION=0.156] 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 P-RHc-+OEmYX for ; Mon, 9 Nov 2009 01:46:51 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 911B03A6961 for ; Mon, 9 Nov 2009 01:46:51 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.gif : 677 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAFt090qrR7H+/2dsb2JhbACCJCwhwSaWRYQ+BA X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="gif'147?scan'147,208,217,147";a="268115867" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2009 09:47:17 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA99l8m3020123; Mon, 9 Nov 2009 09:47:17 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 10:47:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA6121.9EB9E600" Date: Mon, 9 Nov 2009 10:47:06 +0100 Message-ID: In-Reply-To: <13205C286662DE4387D9AF3AC30EF456AFA9A1A6A5@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: We need to add Partition ID back into ANCP spec Thread-Index: AcpeloRl60TmRDFCTfmF0KZJiuMWhgAS5a6wAAI9lmAAjJ1e8A== References: <13205C286662DE4387D9AF3AC30EF456AFA9A1A551@EMBX01-WF.jnpr.net> <282BBE8A501E1F4DA9C775F964BB21FE3E6877B5A1@GRFMBX704BA020.griffon.local> <13205C286662DE4387D9AF3AC30EF456AFA9A1A6A5@EMBX01-WF.jnpr.net> From: "Wojciech Dec (wdec)" To: "Bill Welch" , "Maglione Roberta" , , X-OriginalArrivalTime: 09 Nov 2009 09:47:16.0294 (UTC) FILETIME=[9F010660:01CA6121] Cc: Manuel.Paul@telekom.de, HaagT@telekom.de Subject: Re: [ANCP] We need to add Partition ID back into ANCP spec 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: , X-List-Received-Date: Mon, 09 Nov 2009 09:46:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6121.9EB9E600 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA6121.9EB9E600" ------_=_NextPart_002_01CA6121.9EB9E600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bill, =20 let me add a few comments to articulate the direction and address your = questions on procedure: - Following a recent ANCP WG decision, the ANCP protocol version that = will be covered in the RFC is v3.2. This version change is a significant = event, which for better or for worse allows "existing" v3.1 fields to be = obsolete or re-defined, as well as new ones defined. - A use-case which would call for a partition-id has not been = articulated and by and large it appears as a GSMP derived candidate for = being deprecated, also considering its current level of specification. = The reason for it not being deprecated was to follow a "do no harm" = approach to any pre-standard implementations. A more recent use-case = proposal has however been put forward and a discussion on whether the = partition-id is a suitable solution for it is on-going (and expected) - IETF Meeting minutes, perhaps unlike some other SDOs, although being = significant by themselves do not constitute formal consensus. Following = IETF tradition and process a mailer discussion is used by the chairs as = an indicator of consensus which is called by the chairs. In the case of = the partition-id discussion, aside from "leaving things as they are", = there has not been another consensus call, or a rough one, yet. =20 Regards, Woj. =20 ________________________________ From: Bill Welch [mailto:bwelch@juniper.net]=20 Sent: 06 November 2009 15:16 To: Maglione Roberta; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.com; = Wojciech Dec (wdec) Cc: Manuel.Paul@telekom.de; HaagT@telekom.de Subject: RE: We need to add Partition ID back into ANCP spec =09 =09 Roberta, =20 Thanks for clarifying this and the quick response. I thought this = might be a misunderstand but if it wasn't the discussion was heading = toward the wrong direction. =20 =20 Enjoy IETF and I will see you at BBF. =20 =20 Best regards, Bill Welch Juniper Networks =20 =20 =09 ________________________________ From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Sent: Friday, November 06, 2009 8:16 AM To: Bill Welch; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.com; = wdec@cisco.com Cc: Manuel.Paul@telekom.de; HaagT@telekom.de Subject: RE: We need to add Partition ID back into ANCP spec =20 Hello Bill and All, http://tools.ietf.org/html/draft-ietf-ancp-protocol-07 =20 Partition ID has NOT been removed from the ancp protocol draft, if you = check the draft it is there on page 18. =20 "Partition ID: This field is a 8 bit number which signifies a partition on the AN." =20 The only thing removed compare to version -06 are the two options that = could be used to select the partition ID, because my interpretation = (but I may have miss understood the discussion) of the meeting minutes = "keep as-is" was keep original text for Partition ID thus without = including a clarification on the different ways to select it. =20 Again Partition ID is still part of the version -07 of the ancp draft = and the two options to select it will be put back in version 08. =20 Regards, Roberta =20 =20 =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Bill Welch Sent: Friday, November 06, 2009 5:06 AM To: ancp@ietf.org Cc: Manuel.Paul@telekom.de; HaagT@telekom.de Subject: [ANCP] We need to add Partition ID back into ANCP spec =20 To all, =20 I have been monitoring the discussion from a far but I want to make two = points on this topic. =20 There are implementations that include the use of Partition ID. =20 What is the underlying technical reason for it's removal?=20 =20 If there is no overwelming reason for it's removal it should remain = until it's proven completely unnecessary. I don't think it really = causes issue with implementations to keep partition ID. =20 =20 There have been several people who have easily made the case to keep it = at this time. =20 And what is going on with the procedural issue here? There was a noted = agreement in the meeting minutes but this agreement has been ignored. =20 Best regards, Bill Welch Juniper Networks =20 =20 =20 =20 =20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.=20 =20 ------_=_NextPart_002_01CA6121.9EB9E600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Bill,
 
let me add a few comments to articulate the direction and = address your=20 questions on procedure:
-=20 Following a recent ANCP WG decision, the ANCP protocol version that will = be=20 covered in the RFC is v3.2. This version change is a significant event, = which=20 for better or for worse allows "existing" v3.1 fields to = be obsolete or=20 re-defined, as well as new ones defined.
-=20 A use-case which would call for a partition-id has not been = articulated and=20 by and large it appears as a GSMP derived candidate for = being=20 deprecated, also considering its current level of = specification. The=20 reason for it not being deprecated was to follow a "do no = harm"=20 approach to any pre-standard implementations. A more recent = use-case=20 proposal has however been put forward and a discussion on whether = the=20 partition-id is a suitable solution for it is on-going (and=20 expected)
-=20 IETF Meeting minutes, perhaps unlike some other SDOs, although=20 being significant by themselves do not constitute formal=20 consensus. Following IETF tradition and process a mailer discussion = is used=20 by the chairs as an indicator of consensus which is called by the = chairs.=20 In the case of the partition-id discussion, aside from "leaving things = as they=20 are", there has not been another consensus call, or a rough = one,=20 yet.
 
Regards,
Woj.
 

From: Bill Welch = [mailto:bwelch@juniper.net]=20
Sent: 06 November 2009 15:16
To: Maglione = Roberta;=20 ancp@ietf.org; Matthew.Bocci@alcatel-lucent.com; Wojciech Dec=20 (wdec)
Cc: Manuel.Paul@telekom.de;=20 HaagT@telekom.de
Subject: RE: We need to add Partition ID = back into=20 ANCP spec

Roberta,

 

Thanks for = clarifying=20 this and the quick response.   I thought this might be a=20 misunderstand but if it wasn=92t the discussion was heading toward the = wrong=20 direction.

 

 

Enjoy IETF = and I will=20 see you at BBF.

 

 

Best=20 regards,

Bill=20 Welch

Juniper=20 Networks

 

 

From:=20 Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] =
Sent: Friday, November 06, 2009 = 8:16=20 AM
To: Bill Welch;=20 ancp@ietf.org;=20 Matthew.Bocci@alcatel-lucent.com; wdec@cisco.com
Cc: Manuel.Paul@telekom.de;=20 HaagT@telekom.de
Subject: RE:=20 We need to add Partition ID back into ANCP=20 spec

 

Hello Bill = and=20 All,

http://to= ols.ietf.org/html/draft-ietf-ancp-protocol-07

 

Partition = ID has NOT=20 been removed from the ancp protocol draft, if you check the draft it = is there=20 on page 18.

 

=93Partition =
ID:
      This field is a =
8 bit number which signifies a partition on =
the
      =
AN.=94

 

The only = thing=20 removed compare to version -06 are the two options that could be used = to=20 select the partition ID, because my interpretation  (but I may = have miss=20 understood the discussion) of the meeting minutes =93keep as-is=94 was = keep=20 original text for Partition ID thus without including a clarification = on the=20 different ways to select it.

 

Again = Partition ID is=20 still part of the version -07 of the ancp draft and the two options to = select=20 it will be put back in version 08.

 

Regards,

Roberta

 

 

 

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Bill Welch
Sent: Friday, November 06, 2009 = 5:06=20 AM
To: = ancp@ietf.org
Cc: Manuel.Paul@telekom.de;=20 HaagT@telekom.de
Subject:=20 [ANCP] We need to add Partition ID back into ANCP=20 spec

 

To=20 all,

 

I have been monitoring = the=20 discussion from a far but I want to make two points on this=20 topic.

 

There are = implementations that=20 include the use of Partition ID.

 

What is the underlying = technical=20 reason for it=92s removal?

 

If there is no = overwelming reason=20 for it=92s removal it should remain until it=92s proven completely = unnecessary.=20  I don=92t think it really causes issue with implementations to = keep=20 partition ID. 

 

There have been several = people who=20 have easily made the case to keep it at this=20 time.

 

And what is going on = with the=20 procedural issue here?  There was a noted agreement in the = meeting=20 minutes but this agreement has been = ignored.

 

Best=20 regards,

Bill=20 Welch

Juniper=20 Networks

 

 

 

 

 

Questo=20 messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone=20 indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla=20 conoscenza di queste informazioni sono rigorosamente vietate. = Qualora=20 abbiate ricevuto questo documento per errore siete cortesemente = pregati=20 di darne immediata comunicazione al mittente e di provvedere = alla sua=20 distruzione, Grazie.

This=20 e-mail and any attachments is confidential=20 and may contain privileged information intended for the = addressee(s)=20 only. Dissemination, copying, printing or use by anybody else is = unauthorised. If you are not the intended recipient, please = delete this=20 message and any attachments and advise the sender by return = e-mail,=20 Thanks.=20

Rispetta l'ambiente.=20 Non stampare questa mail se non =E8 = necessario.=20

 

------_=_NextPart_002_01CA6121.9EB9E600-- ------_=_NextPart_001_01CA6121.9EB9E600 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: <023581709@09112009-0140> Content-Description: image001.gif Content-Location: image001.gif R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------_=_NextPart_001_01CA6121.9EB9E600-- From bwelch@juniper.net Fri Nov 6 06:20:23 2009 Return-Path: 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 197B43A6858 for ; Fri, 6 Nov 2009 06:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.025 X-Spam-Level: X-Spam-Status: No, score=-4.025 tagged_above=-999 required=5 tests=[AWL=-2.417, BAYES_40=-0.185, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, SUBJECT_FUZZY_TION=0.156] 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 UQSQpVvV4Vmo for ; Fri, 6 Nov 2009 06:20:17 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id BF9B33A69FD for ; Fri, 6 Nov 2009 06:20:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSvQws7B5sFfZDG8aQuRJulD0B36dD5rZ@postini.com; Fri, 06 Nov 2009 06:20:40 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 6 Nov 2009 06:16:23 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 6 Nov 2009 09:16:22 -0500 From: Bill Welch To: Maglione Roberta , "ancp@ietf.org" , "Matthew.Bocci@alcatel-lucent.com" , "wdec@cisco.com" Date: Fri, 6 Nov 2009 09:16:20 -0500 Thread-Topic: We need to add Partition ID back into ANCP spec Thread-Index: AcpeloRl60TmRDFCTfmF0KZJiuMWhgAS5a6wAAI9lmA= Message-ID: <13205C286662DE4387D9AF3AC30EF456AFA9A1A6A5@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456AFA9A1A551@EMBX01-WF.jnpr.net> <282BBE8A501E1F4DA9C775F964BB21FE3E6877B5A1@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3E6877B5A1@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_13205C286662DE4387D9AF3AC30EF456AFA9A1A6A5EMBX01WFjnprn_"; type="multipart/alternative" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 10 Nov 2009 16:36:09 -0800 Cc: "Manuel.Paul@telekom.de" , "HaagT@telekom.de" Subject: Re: [ANCP] We need to add Partition ID back into ANCP spec 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: , X-List-Received-Date: Fri, 06 Nov 2009 14:20:23 -0000 --_004_13205C286662DE4387D9AF3AC30EF456AFA9A1A6A5EMBX01WFjnprn_ Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456AFA9A1A6A5EMBX01WFjnprn_" --_000_13205C286662DE4387D9AF3AC30EF456AFA9A1A6A5EMBX01WFjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roberta, Thanks for clarifying this and the quick response. I thought this might b= e a misunderstand but if it wasn't the discussion was heading toward the wr= ong direction. Enjoy IETF and I will see you at BBF. Best regards, Bill Welch Juniper Networks ________________________________ From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: Friday, November 06, 2009 8:16 AM To: Bill Welch; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.com; wdec@cisco= .com Cc: Manuel.Paul@telekom.de; HaagT@telekom.de Subject: RE: We need to add Partition ID back into ANCP spec Hello Bill and All, http://tools.ietf.org/html/draft-ietf-ancp-protocol-07 Partition ID has NOT been removed from the ancp protocol draft, if you chec= k the draft it is there on page 18. "Partition ID: This field is a 8 bit number which signifies a partition on the AN." The only thing removed compare to version -06 are the two options that coul= d be used to select the partition ID, because my interpretation (but I may= have miss understood the discussion) of the meeting minutes "keep as-is" w= as keep original text for Partition ID thus without including a clarificati= on on the different ways to select it. Again Partition ID is still part of the version -07 of the ancp draft and t= he two options to select it will be put back in version 08. Regards, Roberta ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Bil= l Welch Sent: Friday, November 06, 2009 5:06 AM To: ancp@ietf.org Cc: Manuel.Paul@telekom.de; HaagT@telekom.de Subject: [ANCP] We need to add Partition ID back into ANCP spec To all, I have been monitoring the discussion from a far but I want to make two poi= nts on this topic. There are implementations that include the use of Partition ID. What is the underlying technical reason for it's removal? If there is no overwelming reason for it's removal it should remain until i= t's proven completely unnecessary. I don't think it really causes issue wi= th implementations to keep partition ID. There have been several people who have easily made the case to keep it at = this time. And what is going on with the procedural issue here? There was a noted agr= eement in the meeting minutes but this agreement has been ignored. Best regards, Bill Welch Juniper Networks Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:image001.gif@01CA5EC1.CDC158E0]Rispetta l'ambiente. Non stampare quest= a mail se non =E8 necessario. --_000_13205C286662DE4387D9AF3AC30EF456AFA9A1A6A5EMBX01WFjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Roberta,

 

Thanks for clarifying this and the qui= ck response. =A0=A0I thought this might be a misunderstand but if it wasn̵= 7;t the discussion was heading toward the wrong direction.=

 

 

Enjoy IETF and I will see you at BBF.<= o:p>

 

 

Best regards,=

Bill Welch

Juniper Networks

 

 

From: Maglione= Roberta [mailto:roberta.maglione@telecomitalia.it]
Sent: Friday, November 06, 2= 009 8:16 AM
To: Bill Welch; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.co= m; wdec@cisco.com
Cc: Manuel.Paul@telekom.de; HaagT@telekom.de
Subject: RE: We need to add Partition ID back into ANCP spec

 

Hello Bill and All,=

http://tools.ietf.org/html/draft-ietf-ancp-protocol-07

 

Partition ID has NOT been removed from= the ancp protocol draft, if you check the draft it is there on page 18.

 

“Partition ID:=

  =
    This field is a 8 bit number which signifies a partition=
 on the
  =
    AN.”

 

The only thing removed compare to vers= ion -06 are the two options that could be used to select the partition ID, beca= use my interpretation  (but I may have miss understood the discussion) of = the meeting minutes “keep as-is” was keep original text for Partiti= on ID thus without including a clarification on the different ways to select it.<= /o:p>

 

Again Partition ID is still part of th= e version -07 of the ancp draft and the two options to select it will be put = back in version 08.

 

Regards,

Roberta

 

 

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Bill Welch
Sent: Friday, November 06, 2= 009 5:06 AM
To: ancp@ietf.org
Cc: Manuel.Paul@telekom.de; HaagT@telekom.de
Subject: [ANCP] We need to a= dd Partition ID back into ANCP spec

 

To all,

 

I have been monitoring the discussion from a far but I w= ant to make two points on this topic.

 

There are implementations that include the use of Partit= ion ID.

 

What is the underlying technical reason for it’s r= emoval?

 

If there is no overwelming reason for it’s removal= it should remain until it’s proven completely unnecessary.  I don’t = think it really causes issue with implementations to keep partition ID. 

 

There have been several people who have easily made the = case to keep it at this time.

 

And what is going on with the procedural issue here?  There was a noted agreement in the meeting minutes but this agreement= has been ignored.

 

Best regards,

Bill Welch

Juniper Networks

 

 

 

 

 

Questo messaggi= o e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. <= /span>

This e-mail and any attachments is <= /font>confidential and may contain privileged information intended for the addressee(s) only= . Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

3D"rispettaRispetta l'ambiente. Non stampare questa mail= se non =E8 necessario.

 

--_000_13205C286662DE4387D9AF3AC30EF456AFA9A1A6A5EMBX01WFjnprn_-- --_004_13205C286662DE4387D9AF3AC30EF456AFA9A1A6A5EMBX01WFjnprn_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=677; creation-date="Fri, 06 Nov 2009 09:16:21 GMT"; modification-date="Fri, 06 Nov 2009 09:16:21 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_004_13205C286662DE4387D9AF3AC30EF456AFA9A1A6A5EMBX01WFjnprn_-- From James.huang@huawei.com Wed Nov 11 22:30:07 2009 Return-Path: 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 8176428C107 for ; Wed, 11 Nov 2009 22:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 v9e-daGiuwxA for ; Wed, 11 Nov 2009 22:30:03 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5FB583A6910 for ; Wed, 11 Nov 2009 22:30:02 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSZ00GZWGQAP1@szxga04-in.huawei.com> for ancp@ietf.org; Thu, 12 Nov 2009 14:30:10 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSZ00I3VGQ904@szxga04-in.huawei.com> for ancp@ietf.org; Thu, 12 Nov 2009 14:30:09 +0800 (CST) Received: from h00144451a ([10.70.40.98]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSZ00FL2GQ9IQ@szxml06-in.huawei.com> for ancp@ietf.org; Thu, 12 Nov 2009 14:30:09 +0800 (CST) Date: Thu, 12 Nov 2009 14:29:49 +0800 From: James Huang To: ancp@ietf.org Message-id: <004e01ca6361$894fb400$6228460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_XdP2kkrJ0bQVvqttVk5RLQ)" Thread-index: AcpjYYkwaK2+4bxQRhKVfLrzrU94Ug== Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity 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: , X-List-Received-Date: Thu, 12 Nov 2009 06:30:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_XdP2kkrJ0bQVvqttVk5RLQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, all, I have some questions about the implementation of ANCP MIB item ancpAnSessionConfigRelatedEntity; can anybody give me some idea? Thanks in advance! http://tools.ietf.org/html/draft-ietf-ancp-mib-an-04 ancpAnSessionConfigRelatedEntity OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the name of an object instance uniquely identifying a lower layer entity associated with this session. For example, in the case where the session is associated with an ATM VCC, this object might be set to an object identifier uniquely identifying that VCC (e.g., an object instance in atmVclTable). If unused, this object MUST have the value zeroDotZero. The value of this object is persistent." DEFVAL { zeroDotZero } ::= { ancpAnSessionConfigEntry 16 } Question: 1. "a lower layer entity associated with this session" What is the association between a lower layer entity and an ANCP session? Is it associated with partition id? What is the application scenario for this? 2. what is the format of the name/identifier "Access-Node-Identifier atm slot/port:vpi.vci", which is defined in TR-101, or an index, i.e. an index of the atmVclTable? Best Regards James --Boundary_(ID_XdP2kkrJ0bQVvqttVk5RLQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi, = all,

 

I have some questions about the = implementation of ANCP MIB item ancpAnSessionConfigRelatedEntity; can anybody give me = some idea? Thanks in advance!

 

http://tools.ietf.org/html/draft-ietf-ancp-mib-an-04

 

 ancpAnSessionConfigRelatedEntity OBJECT-TYPE

       SYNTAX      = RowPointer

       MAX-ACCESS  read-create

       = STATUS      current

       DESCRIPTION

         &= nbsp;   "This object contains the name of an object = instance

         &= nbsp;    uniquely identifying a lower layer entity = associated

         &= nbsp;    with this session.  For example, in the case = where

         &= nbsp;    the session is associated with an ATM VCC, this = object

         &= nbsp;    might be set to an object identifier uniquely = identifying

         &= nbsp;    that VCC (e.g., an object instance in = atmVclTable).

         &= nbsp;    If unused, this object MUST have the value = zeroDotZero.

         &= nbsp;    The value of this object is = persistent."

       = DEFVAL { zeroDotZero = }

       ::=3D { ancpAnSessionConfigEntry 16 }

 

Question:

1.    “a lower layer entity associated with this = session”

What is the association between a lower layer entity and an ANCP session? Is it associated with partition id?

What is the application scenario for this?

 

2.    what is the format of the = name/identifier

"Access-Node-Identifier atm slot/port:vpi.vci", which is defined in TR-101, or an index, = i.e. an index of the atmVclTable?

 

Best = Regards

James

--Boundary_(ID_XdP2kkrJ0bQVvqttVk5RLQ)-- From Moti.Morgenstern@ecitele.com Wed Nov 11 22:55:07 2009 Return-Path: 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 D02F53A6B95 for ; Wed, 11 Nov 2009 22:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 THWCk20-4nTX for ; Wed, 11 Nov 2009 22:55:03 -0800 (PST) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 7113B3A6A4F for ; Wed, 11 Nov 2009 22:55:01 -0800 (PST) Received: from ilptexfe.ecitele.com (HELO ILPTEXCH02.ecitele.com) ([147.234.245.181]) by ilptiron01.ecitele.com with ESMTP; 12 Nov 2009 08:45:53 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 12 Nov 2009 08:55:29 +0200 From: Moti Morgenstern To: James Huang Date: Thu, 12 Nov 2009 08:55:27 +0200 Thread-Topic: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity Thread-Index: AcpjYYkwaK2+4bxQRhKVfLrzrU94UgAANOzw Message-ID: <741F3E4A466A1D439C616902C7F8A8C6FD535357E9@ILPTMAIL02.ecitele.com> References: <004e01ca6361$894fb400$6228460a@china.huawei.com> In-Reply-To: <004e01ca6361$894fb400$6228460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_741F3E4A466A1D439C616902C7F8A8C6FD535357E9ILPTMAIL02eci_" MIME-Version: 1.0 Cc: "ancp@ietf.org" Subject: Re: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity 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: , X-List-Received-Date: Thu, 12 Nov 2009 06:55:07 -0000 --_000_741F3E4A466A1D439C616902C7F8A8C6FD535357E9ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi James, The ANCP session is always associated with some lower-layer entity, e.g., a= virtual bridge port, an ATM VCC, Ethernet interface, etc. Notice that each one of the "lower-layer" entities listed here has a differ= ent identifier-type. The bridge port has a port id, the VCC is identified b= y (ifIndex, VPI, VCI) and the Ethernet interface has a unique ifIndex value= . So, the value in ancpAnSessionConfigRelatedEntity is the SNMP Object ID tha= t uniquely identifies the associated lower-layer entity. The format is therefore, as you understand, an index into another SNMP tabl= e. Regards, Moti Morgenstern From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Jam= es Huang Sent: Thursday, November 12, 2009 8:30 AM To: ancp@ietf.org Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEnti= ty Hi, all, I have some questions about the implementation of ANCP MIB item ancpAnSessi= onConfigRelatedEntity; can anybody give me some idea? Thanks in advance! http://tools.ietf.org/html/draft-ietf-ancp-mib-an-04 ancpAnSessionConfigRelatedEntity OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the name of an object instance uniquely identifying a lower layer entity associated with this session. For example, in the case where the session is associated with an ATM VCC, this object might be set to an object identifier uniquely identifying that VCC (e.g., an object instance in atmVclTable). If unused, this object MUST have the value zeroDotZero. The value of this object is persistent." DEFVAL { zeroDotZero } ::=3D { ancpAnSessionConfigEntry 16 } Question: 1. "a lower layer entity associated with this session" What is the association between a lower layer entity and an ANCP session? I= s it associated with partition id? What is the application scenario for this? 2. what is the format of the name/identifier "Access-Node-Identifier atm slot/port:vpi.vci", which is defined in TR-101,= or an index, i.e. an index of the atmVclTable? Best Regards James --_000_741F3E4A466A1D439C616902C7F8A8C6FD535357E9ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi James,

 

The ANCP session is always associated with some lower-layer = entity, e.g., a virtual bridge port, an ATM VCC, Ethernet interface, etc.

Notice that each one of the “lower-layer” entiti= es listed here has a different identifier-type. The bridge port has a port id,= the VCC is identified by (ifIndex, VPI, VCI) and the Ethernet interface has a unique ifIndex value.

So, the value in ancpAnSessionConfigRelatedEntity is the SNM= P Object ID that uniquely identifies the associated lower-layer entity.

The format is therefore, as you understand, an index into another SNMP table.

 

Regards,

Moti Morgenstern

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ja= mes Huang
Sent: Thursday, November 12, 2009 8:30 AM
To: ancp@ietf.org
Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

Hi, all,

 = ;

I have som= e questions about the implementation of ANCP MIB item ancpAnSessionConfigRelatedEntity; can anybody give me some idea? Thanks in advance!

 = ;

http://too= ls.ietf.org/html/draft-ietf-ancp-mib-an-04

 = ;

 ancp= AnSessionConfigRelatedEntity OBJECT-TYPE

 &nbs= p;     SYNTAX      RowPointer

 &nbs= p;     MAX-ACCESS  read-create

 &nbs= p;     STATUS      current

 &nbs= p;     DESCRIPTION

 &nbs= p;           "This object contains the name of an object instance=

 &nbs= p;            uniquely identifying a lower layer entity associated

 &nbs= p;            with this session.  For example, in the case where

 &nbs= p;            the session is associated with an ATM VCC, this object

 &nbs= p;            might be set to an object identifier uniquely identifying=

 &nbs= p;            that VCC (e.g., an object instance in atmVclTable).

 &nbs= p;            If unused, this object MUST have the value zeroDotZero.

 &nbs= p;            The value of this object is persistent."

 &nbs= p;     DEFVAL { zeroDotZero }

       ::=3D { ancpAnSessionConfigEntry 16 }

 

Question:

1.&n= bsp; “a lower layer entity associated with this session”= ;

What is the association between a lower layer entity and an AN= CP session? Is it associated with partition id?

What is the application scenario for this?

 

2.&n= bsp; what is the format of the name/identifier

"Access-Node-Identifier atm slot/port:vpi.vci", whic= h is defined in TR-101, or an index, i.e. an index of the atmVclTable?

 = ;

Best Regar= ds

James=

--_000_741F3E4A466A1D439C616902C7F8A8C6FD535357E9ILPTMAIL02eci_-- From James.huang@huawei.com Wed Nov 11 23:58:35 2009 Return-Path: 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 9B62A3A6405 for ; Wed, 11 Nov 2009 23:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.173 X-Spam-Level: * X-Spam-Status: No, score=1.173 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] 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 kDtsYhQADhxE for ; Wed, 11 Nov 2009 23:58:34 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4F2BA3A699C for ; Wed, 11 Nov 2009 23:58:28 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSZ008QIKTYRQ@szxga03-in.huawei.com> for ancp@ietf.org; Thu, 12 Nov 2009 15:58:46 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSZ00GJUKTXLS@szxga03-in.huawei.com> for ancp@ietf.org; Thu, 12 Nov 2009 15:58:46 +0800 (CST) Received: from h00144451a ([10.70.40.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSZ008EHKTXUQ@szxml04-in.huawei.com> for ancp@ietf.org; Thu, 12 Nov 2009 15:58:45 +0800 (CST) Date: Thu, 12 Nov 2009 15:58:44 +0800 From: James Huang In-reply-to: <741F3E4A466A1D439C616902C7F8A8C6FD535357E9@ILPTMAIL02.ecitele.com> To: 'Moti Morgenstern' Message-id: <005c01ca636d$f52d1d00$6228460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_f+wS5wWHUeLtTXrQTWS8mA)" Thread-index: AcpjYYkwaK2+4bxQRhKVfLrzrU94UgAANOzwAAJewnA= Cc: ancp@ietf.org Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity 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: , X-List-Received-Date: Thu, 12 Nov 2009 07:58:35 -0000 This is a multi-part message in MIME format. --Boundary_(ID_f+wS5wWHUeLtTXrQTWS8mA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi, Moti, =20 Do you mean we should specify which lower-layer entity should be used to transmit ANCP message by using ancpAnSessionConfigRelatedEntity? If yes, then what is the difference between ancpAnSessionConfigRelatedInterface and = ancpAnSessionConfigRelatedEntity, as shown below? I think they both specify an interface in case of = Ethernet, it is duplicated. =20 =A1=AD=A1=AD (taken from = draft-ietf-ancp-mib-an-04 ) ancpAnSessionConfigRelatedInterface = InterfaceIndex, ancpAnSessionConfigRelatedEntity = RowPointer, ancpAnSessionConfigSvid VlanIdOrNone, =A1=AD=A1=AD =20 BTW, when creating an ANCP session, we need to specify the IP addr of = the ANCP server =A8C BRAS; that would be sufficient; what is the point to = specify the lower-layer entity? The AN should choose the lower-layer entity = itself. Thanks! =20 Best Regards James =20 _____ =20 =B7=A2=BC=FE=C8=CB: Moti Morgenstern = [mailto:Moti.Morgenstern@ecitele.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 14:55 =CA=D5=BC=FE=C8=CB: James Huang =B3=AD=CB=CD: ancp@ietf.org =D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity =20 Hi James, =20 The ANCP session is always associated with some lower-layer entity, = e.g., a virtual bridge port, an ATM VCC, Ethernet interface, etc. Notice that each one of the =A1=B0lower-layer=A1=B1 entities listed here = has a different identifier-type. The bridge port has a port id, the VCC is identified by (ifIndex, VPI, VCI) and the Ethernet interface has a = unique ifIndex value. So, the value in ancpAnSessionConfigRelatedEntity is the SNMP Object ID = that uniquely identifies the associated lower-layer entity. The format is therefore, as you understand, an index into another SNMP table.=20 =20 Regards, Moti Morgenstern From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of James Huang Sent: Thursday, November 12, 2009 8:30 AM To: ancp@ietf.org Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity =20 Hi, all, =20 I have some questions about the implementation of ANCP MIB item ancpAnSessionConfigRelatedEntity; can anybody give me some idea? Thanks = in advance! =20 http://tools.ietf.org/html/draft-ietf-ancp-mib-an-04 =20 ancpAnSessionConfigRelatedEntity OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the name of an object instance uniquely identifying a lower layer entity associated with this session. For example, in the case where the session is associated with an ATM VCC, this object might be set to an object identifier uniquely identifying that VCC (e.g., an object instance in atmVclTable). If unused, this object MUST have the value zeroDotZero. The value of this object is persistent." DEFVAL { zeroDotZero } ::=3D { ancpAnSessionConfigEntry 16 } =20 Question: 1. =A1=B0a lower layer entity associated with this session=A1=B1 What is the association between a lower layer entity and an ANCP = session? Is it associated with partition id? What is the application scenario for this? =20 2. what is the format of the name/identifier "Access-Node-Identifier atm slot/port:vpi.vci", which is defined in = TR-101, or an index, i.e. an index of the atmVclTable? =20 Best Regards James --Boundary_(ID_f+wS5wWHUeLtTXrQTWS8mA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi, = Moti,

 <= /o:p>

Do you mean = we should specify which lower-layer entity should be used to transmit ANCP = message by using ancpAnSessionConfigRelatedEntity?

If yes, = then what is the difference between = ancpAnSessionConfigRelatedInterface    and ancpAnSessionConfigRelatedEntity, as shown below? I think they both = specify an interface in case of Ethernet, it is = duplicated.

 <= /o:p>

  =             &= nbsp;    =A1=AD=A1=AD            (taken from = draft-ietf-ancp-mib-an-04 )

       =             = ancpAnSessionConfigRelatedInterface      InterfaceIndex,

       =             = ancpAnSessionConfigRelatedEntity            RowPointer,

  =                &= nbsp; = ancpAnSessionConfigSvid        &n= bsp;                  &= nbsp;    VlanIdOrNone,

  =             &= nbsp;    =A1=AD=A1=AD

 <= /o:p>

BTW, when = creating an ANCP session, we need to specify the IP addr of the ANCP server =A8C = BRAS; that would be sufficient; what is the point to specify the lower-layer = entity? The AN should choose the lower-layer entity = itself.

Thanks!=

 <= /o:p>

Best = Regards

James

 <= /o:p>

=B7=A2= =BC=FE=C8=CB: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 14:55
=CA=D5=BC=FE=C8=CB: James Huang
=B3=AD=CB=CD: ancp@ietf.org
=D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity

 

Hi = James,

 <= /o:p>

The ANCP = session is always associated with some lower-layer entity, e.g., a virtual bridge = port, an ATM VCC, Ethernet interface, etc.

Notice that = each one of the =A1=B0lower-layer=A1=B1 entities listed here has a different = identifier-type. The bridge port has a port id, the VCC is identified by (ifIndex, VPI, VCI) = and the Ethernet interface has a unique ifIndex = value.

So, the = value in ancpAnSessionConfigRelatedEntity is the SNMP Object ID that uniquely = identifies the associated lower-layer entity.

The format = is therefore, as you understand, an index into another SNMP table. =

 <= /o:p>

Regards,

Moti = Morgenstern

From: = ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of James Huang
Sent: Thursday, November = 12, 2009 8:30 AM
To: ancp@ietf.org
Subject: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity

 

Hi, = all,

 

I have some questions about the implementation of ANCP MIB item ancpAnSessionConfigRelatedEntity; can = anybody give me some idea? Thanks in advance!

 

http://tools.ietf.org/html/draft-ietf-ancp-mib-an-04

 

 ancpAnSessionConfigRelatedEntity OBJECT-TYPE

       SYNTAX      = RowPointer

       MAX-ACCESS  read-create

       STATUS      = current

       DESCRIPTION

         &= nbsp;   "This object contains the name of an object = instance

         &= nbsp;    uniquely identifying a lower layer entity = associated

         &= nbsp;    with this session.  For example, in the case = where

         &= nbsp;    the session is associated with an ATM VCC, this = object

         &= nbsp;    might be set to an object identifier uniquely = identifying

         &= nbsp;    that VCC (e.g., an object instance in = atmVclTable).

         &= nbsp;    If unused, this object MUST have the value = zeroDotZero.

         &= nbsp;    The value of this object is = persistent."

       DEFVAL { zeroDotZero }

       ::=3D { ancpAnSessionConfigEntry 16 }

 

Question:

1.    =A1=B0a lower layer entity associated with this = session=A1=B1

What is the association between a lower layer entity and an ANCP session? Is = it associated with partition id?

What is the application scenario for this?

 

2.    what is the format of the = name/identifier

"Access-Node-Identifier atm slot/port:vpi.vci", which is defined in TR-101, or an index, = i.e. an index of the atmVclTable?

 

Best = Regards

James

--Boundary_(ID_f+wS5wWHUeLtTXrQTWS8mA)-- From stefaan.de_cnodder@alcatel-lucent.be Thu Nov 12 01:10:17 2009 Return-Path: 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 9C5D528C107 for ; Thu, 12 Nov 2009 01:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 U8jY65hKoAyU for ; Thu, 12 Nov 2009 01:10:15 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 0391E3A6872 for ; Thu, 12 Nov 2009 01:10:14 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAC99pUF022211; Thu, 12 Nov 2009 10:09:53 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 10:09:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6377.DD6890C3" Date: Thu, 12 Nov 2009 10:09:40 +0100 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E0438C58F@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <005c01ca636d$f52d1d00$6228460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity Thread-Index: AcpjYYkwaK2+4bxQRhKVfLrzrU94UgAANOzwAAJewnAAAre0IA== References: <741F3E4A466A1D439C616902C7F8A8C6FD535357E9@ILPTMAIL02.ecitele.com> <005c01ca636d$f52d1d00$6228460a@china.huawei.com> From: "DE CNODDER Stefaan" To: "James Huang" , "Moti Morgenstern" X-OriginalArrivalTime: 12 Nov 2009 09:09:40.0719 (UTC) FILETIME=[DDD0D7F0:01CA6377] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: ancp@ietf.org Subject: Re: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity 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: , X-List-Received-Date: Thu, 12 Nov 2009 09:10:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6377.DD6890C3 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable =20 Hi James, =20 Some replies below =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = James Huang Sent: donderdag 12 november 2009 8:59 To: 'Moti Morgenstern' Cc: ancp@ietf.org Subject: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity =20 Hi, Moti, =20 Do you mean we should specify which lower-layer entity should be used to = transmit ANCP message by using ancpAnSessionConfigRelatedEntity? If yes, then what is the difference between = ancpAnSessionConfigRelatedInterface and = ancpAnSessionConfigRelatedEntity, as shown below? I think they both = specify an interface in case of Ethernet, it is duplicated. =20 [Stefaan] Not only Ethernet is covered but also ATM =20 =A1=AD=A1=AD (taken from = draft-ietf-ancp-mib-an-04 ) ancpAnSessionConfigRelatedInterface = InterfaceIndex, ancpAnSessionConfigRelatedEntity = RowPointer, ancpAnSessionConfigSvid = VlanIdOrNone, =A1=AD=A1=AD =20 BTW, when creating an ANCP session, we need to specify the IP addr of = the ANCP server =A8C BRAS; that would be sufficient; what is the point = to specify the lower-layer entity? The AN should choose the lower-layer = entity itself. =20 [Stefaan] these MIB objects have been added since version 02 of the = draft based on a discussion in February last year. In principle just = specifying the IP address of the NAS is sufficient but some people = preferred to also explicitly configure the underlying interface (VLAN, = PVC, ...). The discussion last year started with this message = http://www.ietf.org/mail-archive/web/ancp/current/msg00484.html = =20 =20 regards, Stefaan =20 =20 Thanks! =20 Best Regards James =20 ________________________________ =B7=A2=BC=FE=C8=CB: Moti Morgenstern = [mailto:Moti.Morgenstern@ecitele.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 14:55 =CA=D5=BC=FE=C8=CB: James Huang =B3=AD=CB=CD: ancp@ietf.org =D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity =20 Hi James, =20 The ANCP session is always associated with some lower-layer entity, = e.g., a virtual bridge port, an ATM VCC, Ethernet interface, etc. Notice that each one of the =A1=B0lower-layer=A1=B1 entities listed here = has a different identifier-type. The bridge port has a port id, the VCC = is identified by (ifIndex, VPI, VCI) and the Ethernet interface has a = unique ifIndex value. So, the value in ancpAnSessionConfigRelatedEntity is the SNMP Object ID = that uniquely identifies the associated lower-layer entity. The format is therefore, as you understand, an index into another SNMP = table.=20 =20 Regards, Moti Morgenstern From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = James Huang Sent: Thursday, November 12, 2009 8:30 AM To: ancp@ietf.org Subject: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity =20 Hi, all, =20 I have some questions about the implementation of ANCP MIB item = ancpAnSessionConfigRelatedEntity; can anybody give me some idea? Thanks = in advance! =20 http://tools.ietf.org/html/draft-ietf-ancp-mib-an-04 =20 ancpAnSessionConfigRelatedEntity OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the name of an object instance uniquely identifying a lower layer entity associated with this session. For example, in the case where the session is associated with an ATM VCC, this object might be set to an object identifier uniquely identifying that VCC (e.g., an object instance in atmVclTable). If unused, this object MUST have the value zeroDotZero. The value of this object is persistent." DEFVAL { zeroDotZero } ::=3D { ancpAnSessionConfigEntry 16 } =20 Question: 1. =A1=B0a lower layer entity associated with this session=A1=B1 What is the association between a lower layer entity and an ANCP = session? Is it associated with partition id? What is the application scenario for this? =20 2. what is the format of the name/identifier "Access-Node-Identifier atm slot/port:vpi.vci", which is defined in = TR-101, or an index, i.e. an index of the atmVclTable? =20 Best Regards James ------_=_NextPart_001_01CA6377.DD6890C3 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

Hi = James,

 

Some replies = below

 

From: = ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of James Huang
Sent: donderdag 12 = november 2009 8:59
To: 'Moti = Morgenstern'
Cc: ancp@ietf.org
Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

Hi, = Moti,

 <= /o:p>

Do you mean = we should specify which lower-layer entity should be used to transmit ANCP = message by using ancpAnSessionConfigRelatedEntity?

If yes, = then what is the difference between = ancpAnSessionConfigRelatedInterface    and ancpAnSessionConfigRelatedEntity, as shown below? I think they both = specify an interface in case of Ethernet, it is = duplicated.

 

[Stefaan] Not = only Ethernet is covered but also ATM

 =

  =             &= nbsp;    =A1=AD=A1=AD =            (taken from draft-ietf-ancp-mib-an-04 )

                   ancpAnSessionConfigRelatedInterface     =  InterfaceIndex,

                   ancpAnSessionConfigRelatedEntity            RowPointer,

  =                &= nbsp; ancpAnSessionConfigSvid        &n= bsp;                  &= nbsp;    VlanIdOrNone,

  =             &= nbsp;    =A1=AD=A1=AD

 <= /o:p>

BTW, when = creating an ANCP session, we need to specify the IP addr of the ANCP server =A8C = BRAS; that would be sufficient; what is the point to specify the lower-layer = entity? The AN should choose the lower-layer entity = itself.

 

[Stefaan] = these MIB objects have been added since version 02 of the draft based on a = discussion in February last year.  In principle just specifying the IP address of the NAS = is sufficient but some people preferred to also explicitly configure the underlying interface (VLAN, PVC, ...).  The discussion last year = started with this message = http://www.ietf.org/mail-archive/web/ancp/current/= msg00484.html

 

regards,

Stefaan

 =

 =

Thanks!=

 <= /o:p>

Best = Regards

James

 <= /o:p>

=B7=A2=BC=FE=C8=CB: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 14:55
=CA=D5=BC=FE=C8=CB: James Huang
=B3=AD=CB=CD: ancp@ietf.org
=D6=F7=CC=E2: RE: [ANCP] Questions = regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

Hi = James,

 <= /o:p>

The ANCP = session is always associated with some lower-layer entity, e.g., a virtual bridge = port, an ATM VCC, Ethernet interface, etc.

Notice that = each one of the =A1=B0lower-layer=A1=B1 entities listed here has a different = identifier-type. The bridge port has a port id, the VCC is identified by (ifIndex, VPI, VCI) = and the Ethernet interface has a unique ifIndex = value.

So, the = value in ancpAnSessionConfigRelatedEntity is the SNMP Object ID that uniquely = identifies the associated lower-layer entity.

The format = is therefore, as you understand, an index into another SNMP table. =

 <= /o:p>

Regards,

Moti = Morgenstern

From: = ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of James Huang
Sent: Thursday, November = 12, 2009 8:30 AM
To: ancp@ietf.org
Subject: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity

 

Hi, = all,

 

I have some questions about the implementation of ANCP MIB item ancpAnSessionConfigRelatedEntity; can = anybody give me some idea? Thanks in advance!

 

http://tools.ietf.org/html/draft-ietf-ancp-mib-an-04

 

 ancpAnSessionConfigRelatedEntity OBJECT-TYPE

       SYNTAX      = RowPointer

       MAX-ACCESS  read-create

       STATUS      = current

       DESCRIPTION

         &= nbsp;   "This object contains the name of an object = instance

         &= nbsp;    uniquely identifying a lower layer entity = associated

         &= nbsp;    with this session.  For example, in the case = where

         &= nbsp;    the session is associated with an ATM VCC, this = object

         &= nbsp;    might be set to an object identifier uniquely = identifying

         &= nbsp;    that VCC (e.g., an object instance in = atmVclTable).

         &= nbsp;    If unused, this object MUST have the value = zeroDotZero.

         &= nbsp;    The value of this object is = persistent."

       DEFVAL { zeroDotZero }

       ::=3D { ancpAnSessionConfigEntry 16 }

 

Question:

1.    =A1=B0a lower layer entity associated with this = session=A1=B1

What is the association between a lower layer entity and an ANCP session? Is it associated with partition id?

What is the application scenario for this?

 

2.    what is the format of the = name/identifier

"Access-Node-Identifier atm slot/port:vpi.vci", which is defined in TR-101, or an index, = i.e. an index of the atmVclTable?

 

Best = Regards

James

------_=_NextPart_001_01CA6377.DD6890C3-- From Moti.Morgenstern@ecitele.com Thu Nov 12 01:29:33 2009 Return-Path: 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 EA25F3A67F6 for ; Thu, 12 Nov 2009 01:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 aoxHINeWY-s6 for ; Thu, 12 Nov 2009 01:29:32 -0800 (PST) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 84C8D3A6A1B for ; Thu, 12 Nov 2009 01:29:29 -0800 (PST) Received: from ilptexfe.ecitele.com (HELO ILPTEXCH02.ecitele.com) ([147.234.245.181]) by ilptiron01.ecitele.com with ESMTP; 12 Nov 2009 11:20:21 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 12 Nov 2009 11:29:51 +0200 From: Moti Morgenstern To: James Huang Date: Thu, 12 Nov 2009 11:29:49 +0200 Thread-Topic: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity Thread-Index: AcpjYYkwaK2+4bxQRhKVfLrzrU94UgAANOzwAAJewnAAAyOG8A== Message-ID: <741F3E4A466A1D439C616902C7F8A8C6FD53535854@ILPTMAIL02.ecitele.com> References: <741F3E4A466A1D439C616902C7F8A8C6FD535357E9@ILPTMAIL02.ecitele.com> <005c01ca636d$f52d1d00$6228460a@china.huawei.com> In-Reply-To: <005c01ca636d$f52d1d00$6228460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_741F3E4A466A1D439C616902C7F8A8C6FD53535854ILPTMAIL02eci_" MIME-Version: 1.0 Cc: "ancp@ietf.org" Subject: Re: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity 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: , X-List-Received-Date: Thu, 12 Nov 2009 09:29:34 -0000 --_000_741F3E4A466A1D439C616902C7F8A8C6FD53535854ILPTMAIL02eci_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNClNlZSBlbWJlZGRlZCBhbnN3ZXIuDQoNClJlZ2FyZHMsIE1vdGkNCg0KRnJv bTogSmFtZXMgSHVhbmcgW21haWx0bzpKYW1lcy5odWFuZ0BodWF3ZWkuY29tXQ0KU2VudDogVGh1 cnNkYXksIE5vdmVtYmVyIDEyLCAyMDA5IDk6NTkgQU0NClRvOiBNb3RpIE1vcmdlbnN0ZXJuDQpD YzogYW5jcEBpZXRmLm9yZzsgJ3dhbmd5aW1pbmcnOyAnVGluYSBUU09VJzsgJ0ZvcnR1bmUgSFVB TkcnDQpTdWJqZWN0OiBbQU5DUF0gUXVlc3Rpb25zIHJlZ2FyZGluZyBBTkNQIE1JQiBhbmNwQW5T ZXNzaW9uQ29uZmlnUmVsYXRlZEVudGl0eQ0KDQpIaSwgTW90aSwNCg0KRG8geW91IG1lYW4gd2Ug c2hvdWxkIHNwZWNpZnkgd2hpY2ggbG93ZXItbGF5ZXIgZW50aXR5IHNob3VsZCBiZSB1c2VkIHRv IHRyYW5zbWl0IEFOQ1AgbWVzc2FnZSBieSB1c2luZyBhbmNwQW5TZXNzaW9uQ29uZmlnUmVsYXRl ZEVudGl0eT8NCklmIHllcywgdGhlbiB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYW5j cEFuU2Vzc2lvbkNvbmZpZ1JlbGF0ZWRJbnRlcmZhY2UgICAgYW5kIGFuY3BBblNlc3Npb25Db25m aWdSZWxhdGVkRW50aXR5LCBhcyBzaG93biBiZWxvdz8gSSB0aGluayB0aGV5IGJvdGggc3BlY2lm eSBhbiBpbnRlcmZhY2UgaW4gY2FzZSBvZiBFdGhlcm5ldCwgaXQgaXMgZHVwbGljYXRlZC4NCltN TV0gUGxlYXNlIGxvb2sgaW50byBSRkM0MTg4IChCUklER0UtTUlCKSB3aGVyZSB3ZSBoYXZlIGEg dmVyeSBzaW1pbGFyIGlzc3VlLiBJbiBjYXNlIHRoZSBicmlkZ2UgcG9ydCBpcyBhc3NvY2lhdGVk IHdpdGggYW4gaWZJbmRleCB0aGVuIGRvdDFkQmFzZVBvcnRJZkluZGV4IGlzIGVub3VnaCBidXQg aWYgbm90IHRoZW4gZG90MWRCYXNlUG9ydENpcmN1aXQgaXMgcmVxdWlyZWQuIEluIG91ciBjYXNl LCBpZiB0aGUgYW5jcEFuU2Vzc2lvbkNvbmZpZ1JlbGF0ZWRJbnRlcmZhY2UgdGhlbiB0aGUgb3Ro ZXIgb2JqZWN0cyBjYW4gYmUgbGVmdCB1bnVzZWQuIEhvd2V2ZXIsIHNvbWV0aW1lcyB5b3UgbmVl ZCB0byBzcGVjaWZ5IGFsc28gdGhlIFMtVkxBTiBJRC4NCg0KICAgICAgICAgICAgICAgICAgIKGt oa0gICAgICAgICAgICAodGFrZW4gZnJvbSBkcmFmdC1pZXRmLWFuY3AtbWliLWFuLTA0ICkNCiAg ICAgICAgICAgICAgICAgICBhbmNwQW5TZXNzaW9uQ29uZmlnUmVsYXRlZEludGVyZmFjZSAgICAg IEludGVyZmFjZUluZGV4LA0KICAgICAgICAgICAgICAgICAgIGFuY3BBblNlc3Npb25Db25maWdS ZWxhdGVkRW50aXR5ICAgICAgICAgICAgUm93UG9pbnRlciwNCiAgICAgICAgICAgICAgICAgICBh bmNwQW5TZXNzaW9uQ29uZmlnU3ZpZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVmxh bklkT3JOb25lLA0KICAgICAgICAgICAgICAgICAgIKGtoa0NCg0KQlRXLCB3aGVuIGNyZWF0aW5n IGFuIEFOQ1Agc2Vzc2lvbiwgd2UgbmVlZCB0byBzcGVjaWZ5IHRoZSBJUCBhZGRyIG9mIHRoZSBB TkNQIHNlcnZlciCoQyBCUkFTOyB0aGF0IHdvdWxkIGJlIHN1ZmZpY2llbnQ7IHdoYXQgaXMgdGhl IHBvaW50IHRvIHNwZWNpZnkgdGhlIGxvd2VyLWxheWVyIGVudGl0eT8gVGhlIEFOIHNob3VsZCBj aG9vc2UgdGhlIGxvd2VyLWxheWVyIGVudGl0eSBpdHNlbGYuDQpUaGFua3MhDQoNCkJlc3QgUmVn YXJkcw0KSmFtZXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7Iyzog TW90aSBNb3JnZW5zdGVybiBbbWFpbHRvOk1vdGkuTW9yZ2Vuc3Rlcm5AZWNpdGVsZS5jb21dDQq3 osvNyrG85DogMjAwOcTqMTHUwjEyyNUgMTQ6NTUNCsrVvP7IyzogSmFtZXMgSHVhbmcNCrOty806 IGFuY3BAaWV0Zi5vcmcNCtb3zOI6IFJFOiBbQU5DUF0gUXVlc3Rpb25zIHJlZ2FyZGluZyBBTkNQ IE1JQiBhbmNwQW5TZXNzaW9uQ29uZmlnUmVsYXRlZEVudGl0eQ0KDQpIaSBKYW1lcywNCg0KVGhl IEFOQ1Agc2Vzc2lvbiBpcyBhbHdheXMgYXNzb2NpYXRlZCB3aXRoIHNvbWUgbG93ZXItbGF5ZXIg ZW50aXR5LCBlLmcuLCBhIHZpcnR1YWwgYnJpZGdlIHBvcnQsIGFuIEFUTSBWQ0MsIEV0aGVybmV0 IGludGVyZmFjZSwgZXRjLg0KTm90aWNlIHRoYXQgZWFjaCBvbmUgb2YgdGhlIKGwbG93ZXItbGF5 ZXKhsSBlbnRpdGllcyBsaXN0ZWQgaGVyZSBoYXMgYSBkaWZmZXJlbnQgaWRlbnRpZmllci10eXBl LiBUaGUgYnJpZGdlIHBvcnQgaGFzIGEgcG9ydCBpZCwgdGhlIFZDQyBpcyBpZGVudGlmaWVkIGJ5 IChpZkluZGV4LCBWUEksIFZDSSkgYW5kIHRoZSBFdGhlcm5ldCBpbnRlcmZhY2UgaGFzIGEgdW5p cXVlIGlmSW5kZXggdmFsdWUuDQpTbywgdGhlIHZhbHVlIGluIGFuY3BBblNlc3Npb25Db25maWdS ZWxhdGVkRW50aXR5IGlzIHRoZSBTTk1QIE9iamVjdCBJRCB0aGF0IHVuaXF1ZWx5IGlkZW50aWZp ZXMgdGhlIGFzc29jaWF0ZWQgbG93ZXItbGF5ZXIgZW50aXR5Lg0KVGhlIGZvcm1hdCBpcyB0aGVy ZWZvcmUsIGFzIHlvdSB1bmRlcnN0YW5kLCBhbiBpbmRleCBpbnRvIGFub3RoZXIgU05NUCB0YWJs ZS4NCg0KUmVnYXJkcywNCk1vdGkgTW9yZ2Vuc3Rlcm4NCkZyb206IGFuY3AtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmFuY3AtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphbWVzIEh1 YW5nDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTIsIDIwMDkgODozMCBBTQ0KVG86IGFuY3BA aWV0Zi5vcmcNClN1YmplY3Q6IFtBTkNQXSBRdWVzdGlvbnMgcmVnYXJkaW5nIEFOQ1AgTUlCIGFu Y3BBblNlc3Npb25Db25maWdSZWxhdGVkRW50aXR5DQoNCkhpLCBhbGwsDQoNCkkgaGF2ZSBzb21l IHF1ZXN0aW9ucyBhYm91dCB0aGUgaW1wbGVtZW50YXRpb24gb2YgQU5DUCBNSUIgaXRlbSBhbmNw QW5TZXNzaW9uQ29uZmlnUmVsYXRlZEVudGl0eTsgY2FuIGFueWJvZHkgZ2l2ZSBtZSBzb21lIGlk ZWE/IFRoYW5rcyBpbiBhZHZhbmNlIQ0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWFuY3AtbWliLWFuLTA0DQoNCiBhbmNwQW5TZXNzaW9uQ29uZmlnUmVsYXRlZEVudGl0 eSBPQkpFQ1QtVFlQRQ0KICAgICAgIFNZTlRBWCAgICAgIFJvd1BvaW50ZXINCiAgICAgICBNQVgt QUNDRVNTICByZWFkLWNyZWF0ZQ0KICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAgICJUaGlzIG9iamVjdCBjb250YWlucyB0aGUgbmFtZSBv ZiBhbiBvYmplY3QgaW5zdGFuY2UNCiAgICAgICAgICAgICAgdW5pcXVlbHkgaWRlbnRpZnlpbmcg YSBsb3dlciBsYXllciBlbnRpdHkgYXNzb2NpYXRlZA0KICAgICAgICAgICAgICB3aXRoIHRoaXMg c2Vzc2lvbi4gIEZvciBleGFtcGxlLCBpbiB0aGUgY2FzZSB3aGVyZQ0KICAgICAgICAgICAgICB0 aGUgc2Vzc2lvbiBpcyBhc3NvY2lhdGVkIHdpdGggYW4gQVRNIFZDQywgdGhpcyBvYmplY3QNCiAg ICAgICAgICAgICAgbWlnaHQgYmUgc2V0IHRvIGFuIG9iamVjdCBpZGVudGlmaWVyIHVuaXF1ZWx5 IGlkZW50aWZ5aW5nDQogICAgICAgICAgICAgIHRoYXQgVkNDIChlLmcuLCBhbiBvYmplY3QgaW5z dGFuY2UgaW4gYXRtVmNsVGFibGUpLg0KICAgICAgICAgICAgICBJZiB1bnVzZWQsIHRoaXMgb2Jq ZWN0IE1VU1QgaGF2ZSB0aGUgdmFsdWUgemVyb0RvdFplcm8uDQogICAgICAgICAgICAgIFRoZSB2 YWx1ZSBvZiB0aGlzIG9iamVjdCBpcyBwZXJzaXN0ZW50LiINCiAgICAgICBERUZWQUwgeyB6ZXJv RG90WmVybyB9DQogICAgICAgOjo9IHsgYW5jcEFuU2Vzc2lvbkNvbmZpZ0VudHJ5IDE2IH0NCg0K UXVlc3Rpb246DQoxLiAgobBhIGxvd2VyIGxheWVyIGVudGl0eSBhc3NvY2lhdGVkIHdpdGggdGhp cyBzZXNzaW9uobENCldoYXQgaXMgdGhlIGFzc29jaWF0aW9uIGJldHdlZW4gYSBsb3dlciBsYXll ciBlbnRpdHkgYW5kIGFuIEFOQ1Agc2Vzc2lvbj8gSXMgaXQgYXNzb2NpYXRlZCB3aXRoIHBhcnRp dGlvbiBpZD8NCldoYXQgaXMgdGhlIGFwcGxpY2F0aW9uIHNjZW5hcmlvIGZvciB0aGlzPw0KDQoy LiAgd2hhdCBpcyB0aGUgZm9ybWF0IG9mIHRoZSBuYW1lL2lkZW50aWZpZXINCiJBY2Nlc3MtTm9k ZS1JZGVudGlmaWVyIGF0bSBzbG90L3BvcnQ6dnBpLnZjaSIsIHdoaWNoIGlzIGRlZmluZWQgaW4g VFItMTAxLCBvciBhbiBpbmRleCwgaS5lLiBhbiBpbmRleCBvZiB0aGUgYXRtVmNsVGFibGU/DQoN CkJlc3QgUmVnYXJkcw0KSmFtZXMNCg== --_000_741F3E4A466A1D439C616902C7F8A8C6FD53535854ILPTMAIL02eci_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi James,

 

See embedded answer.

 

Regards, Moti

 

From: James Huang [mailto:James.huang@huawei.com]
Sent: Thursday, November 12, 2009 9:59 AM
To: Moti Morgenstern
Cc: ancp@ietf.org; 'wangyiming'; 'Tina TSOU'; 'Fortune HUANG'
Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

Hi, Moti,

 

Do you mean we should specify which lower-layer entity shoul= d be used to transmit ANCP message by using ancpAnSessionConfigRelatedEntity?

If yes, then what is the difference between ancpAnSessionConfigRelatedInterface    and ancpAnSessionConfigRelatedEntity, as shown below? I think they both specify= an interface in case of Ethernet, it is duplicated.

[MM] Please look into RFC4188 (BRIDGE-MIB) where we have a v= ery similar issue. In case the bridge port is associated with an ifIndex then dot1dBase= PortIfIndex is enough but if not then dot1dBasePortCircuit is required. In our case, if= the ancpAnSessionConfigRelatedInterface then the other objects can be left unus= ed. However, sometimes you need to specify also the S-VLAN ID.

 

          =          =A1=AD=A1=AD            (= taken from draft-ietf-ancp-mib-an-04 )

                   ancpAnSessionConfigRelatedInterface      InterfaceIndex= ,

                   ancpAnSessionConfigRelatedEntity            RowPointer,

                 &nb= sp; ancpAnSessionConfigSvid        &nbs= p;                  &nb= sp;    VlanIdOrNone,

          =          =A1=AD=A1=AD

 

BTW, when creating an ANCP session, we need to specify the I= P addr of the ANCP server =A8C BRAS; that would be sufficient; what is the po= int to specify the lower-layer entity? The AN should choose the lower-layer entity itself.

Thanks!

 

Best Regards

James

 

=B7=A2=BC=FE=C8=CB<= /span>: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 14:55
=CA=D5=BC=FE=C8=CB: James Huang
=B3=AD=CB=CD: ancp@ietf.org
=D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

Hi James,

 

The ANCP session is always associated with some lower-layer entity, e.g., a virtual bridge port, an ATM VCC, Ethernet interface, etc.

Notice that each one of the =A1=B0lower-layer=A1=B1 entities= listed here has a different identifier-type. The bridge port has a port id, the VCC is identified by (ifIndex, VPI, VCI) and the Ethernet interface has a unique ifIndex value.

So, the value in ancpAnSessionConfigRelatedEntity is the SNM= P Object ID that uniquely identifies the associated lower-layer entity.<= /o:p>

The format is therefore, as you understand, an index into another SNMP table.

 

Regards,

Moti Morgenstern

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ja= mes Huang
Sent: Thursday, November 12, 2009 8:30 AM
To: ancp@ietf.org
Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

Hi, all,

 = ;

I have som= e questions about the implementation of ANCP MIB item ancpAnSessionConfigRelatedEntity; can anybody give me some idea? Thanks in advance!

 = ;

http://too= ls.ietf.org/html/draft-ietf-ancp-mib-an-04

 = ;

 ancp= AnSessionConfigRelatedEntity OBJECT-TYPE

 &nbs= p;     SYNTAX      RowPointer

 &nbs= p;     MAX-ACCESS  read-create

 &nbs= p;     STATUS      current

 &nbs= p;     DESCRIPTION

 &nbs= p;           "This object contains the name of an object instance=

 &nbs= p;            uniquely identifying a lower layer entity associated

 &nbs= p;            with this session.  For example, in the case where

 &nbs= p;            the session is associated with an ATM VCC, this object

 &nbs= p;            might be set to an object identifier uniquely identifying=

 &nbs= p;            that VCC (e.g., an object instance in atmVclTable).

 &nbs= p;            If unused, this object MUST have the value zeroDotZero.

 &nbs= p;            The value of this object is persistent."

 &nbs= p;     DEFVAL { zeroDotZero }

       ::=3D { ancpAnSessionConf= igEntry 16 }

 

Question:

1.&n= bsp; =A1=B0a lower layer entity associated with this session=A1=B1<= o:p>

What is the association between a lower layer entity and an AN= CP session? Is it associated with partition id?

What is the application scenario for this?

 

2.&n= bsp; what is the format of the name/identifier

"Access-Node-Identifier atm slot/port:vpi.vci", whic= h is defined in TR-101, or an index, i.e. an index of the atmVclTable?

 = ;

Best Regar= ds

James=

--_000_741F3E4A466A1D439C616902C7F8A8C6FD53535854ILPTMAIL02eci_-- From James.huang@huawei.com Thu Nov 12 18:48:52 2009 Return-Path: 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 700FC3A63C9 for ; Thu, 12 Nov 2009 18:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.377 X-Spam-Level: *** X-Spam-Status: No, score=3.377 tagged_above=-999 required=5 tests=[AWL=-2.204, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 xsbSpsa60cCP for ; Thu, 12 Nov 2009 18:48:51 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id E5EDC3A692A for ; Thu, 12 Nov 2009 18:47:40 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KT1002QK148XQ@szxga02-in.huawei.com> for ancp@ietf.org; Fri, 13 Nov 2009 10:48:09 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KT100HAT148ZT@szxga02-in.huawei.com> for ancp@ietf.org; Fri, 13 Nov 2009 10:48:08 +0800 (CST) Received: from h00144451a ([10.70.40.98]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KT100E1E1472E@szxml06-in.huawei.com> for ancp@ietf.org; Fri, 13 Nov 2009 10:48:08 +0800 (CST) Date: Fri, 13 Nov 2009 10:48:07 +0800 From: James Huang In-reply-to: <7A6D4815C5E8F74988784FEBD50F2F1E0438C58F@FRVELSMBS22.ad2.ad.alcatel.com> To: 'DE CNODDER Stefaan' , 'Moti Morgenstern' Message-id: <007601ca640b$bb1e3f60$6228460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_/W99gSEuLd7EHviVPjhqzQ)" Thread-index: AcpjYYkwaK2+4bxQRhKVfLrzrU94UgAANOzwAAJewnAAAre0IAAk5vEQ Cc: ancp@ietf.org Subject: [ANCP] =?gb2312?b?tPC4tDogIFF1ZXN0aW9ucyByZWdhcmRpbmcgQU5DUCBN?= =?gb2312?b?SUIgYW5jcEFuU2Vzc2lvbkNvbmZpZ1JlbGF0ZWRFbnRpdHk=?= 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: , X-List-Received-Date: Fri, 13 Nov 2009 02:48:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_/W99gSEuLd7EHviVPjhqzQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi, stefaan, =20 I have read the discussion thread carefully. In my understanding, in the case of Ethernet, when configuring an ANCP session in the AN, the steps should be followed: 1. specify which should be used by = ancpAnSessionConfigRelatedInterface 2. specify which VLAN should be used. If the VLAN does not exist, it should be created; and an IP address = should be assigned to this VLAN interface, which would be used as the=20 Source IP address in the ANCP packets; and also a routing table should = be added if necessary. =20 Is this correct? =20 But I still do not get the point why we should specify the layer2 = interface, although it is also defined in the ANCP framework. Thanks! =20 Best Regards James =20 _____ =20 =B7=A2=BC=FE=C8=CB: DE CNODDER Stefaan = [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 17:10 =CA=D5=BC=FE=C8=CB: James Huang; Moti Morgenstern =B3=AD=CB=CD: ancp@ietf.org =D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity =20 =20 Hi James, =20 Some replies below =20 _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of James Huang Sent: donderdag 12 november 2009 8:59 To: 'Moti Morgenstern' Cc: ancp@ietf.org Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity =20 Hi, Moti, =20 Do you mean we should specify which lower-layer entity should be used to transmit ANCP message by using ancpAnSessionConfigRelatedEntity? If yes, then what is the difference between ancpAnSessionConfigRelatedInterface and = ancpAnSessionConfigRelatedEntity, as shown below? I think they both specify an interface in case of = Ethernet, it is duplicated. =20 [Stefaan] Not only Ethernet is covered but also ATM =20 =A1=AD=A1=AD (taken from = draft-ietf-ancp-mib-an-04 ) ancpAnSessionConfigRelatedInterface = InterfaceIndex, ancpAnSessionConfigRelatedEntity = RowPointer, ancpAnSessionConfigSvid VlanIdOrNone, =A1=AD=A1=AD =20 BTW, when creating an ANCP session, we need to specify the IP addr of = the ANCP server =A8C BRAS; that would be sufficient; what is the point to = specify the lower-layer entity? The AN should choose the lower-layer entity = itself. =20 [Stefaan] these MIB objects have been added since version 02 of the = draft based on a discussion in February last year. In principle just = specifying the IP address of the NAS is sufficient but some people preferred to = also explicitly configure the underlying interface (VLAN, PVC, ...). The discussion last year started with this message http://www.ietf.org/mail-archive/web/ancp/current/msg00484.html=20 =20 regards, Stefaan =20 =20 Thanks! =20 Best Regards James =20 _____ =20 =B7=A2=BC=FE=C8=CB: Moti Morgenstern = [mailto:Moti.Morgenstern@ecitele.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 14:55 =CA=D5=BC=FE=C8=CB: James Huang =B3=AD=CB=CD: ancp@ietf.org =D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity =20 Hi James, =20 The ANCP session is always associated with some lower-layer entity, = e.g., a virtual bridge port, an ATM VCC, Ethernet interface, etc. Notice that each one of the =A1=B0lower-layer=A1=B1 entities listed here = has a different identifier-type. The bridge port has a port id, the VCC is identified by (ifIndex, VPI, VCI) and the Ethernet interface has a = unique ifIndex value. So, the value in ancpAnSessionConfigRelatedEntity is the SNMP Object ID = that uniquely identifies the associated lower-layer entity. The format is therefore, as you understand, an index into another SNMP table.=20 =20 Regards, Moti Morgenstern From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of James Huang Sent: Thursday, November 12, 2009 8:30 AM To: ancp@ietf.org Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity =20 Hi, all, =20 I have some questions about the implementation of ANCP MIB item ancpAnSessionConfigRelatedEntity; can anybody give me some idea? Thanks = in advance! =20 http://tools.ietf.org/html/draft-ietf-ancp-mib-an-04 =20 ancpAnSessionConfigRelatedEntity OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the name of an object instance uniquely identifying a lower layer entity associated with this session. For example, in the case where the session is associated with an ATM VCC, this object might be set to an object identifier uniquely identifying that VCC (e.g., an object instance in atmVclTable). If unused, this object MUST have the value zeroDotZero. The value of this object is persistent." DEFVAL { zeroDotZero } ::=3D { ancpAnSessionConfigEntry 16 } =20 Question: 1. =A1=B0a lower layer entity associated with this session=A1=B1 What is the association between a lower layer entity and an ANCP = session? Is it associated with partition id? What is the application scenario for this? =20 2. what is the format of the name/identifier "Access-Node-Identifier atm slot/port:vpi.vci", which is defined in = TR-101, or an index, i.e. an index of the atmVclTable? =20 Best Regards James --Boundary_(ID_/W99gSEuLd7EHviVPjhqzQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi, = stefaan,

 

I have read the discussion thread = carefully.

In my understanding, in the case of Ethernet, = when configuring an ANCP session in the AN, the steps should be = followed:

1.     = specify which should be used by ancpAnSessionConfigRelatedInterface   =    

2.     = specify which VLAN should be used.

If the = VLAN does not exist, it should be created; and an IP address should be assigned to this VLAN interface, which would be used as the

Source = IP address in the ANCP packets; and also a routing table should be added if = necessary.

 

Is this correct?

 

But I still do not get the point why we should = specify the layer2 interface, although it is also defined in the ANCP = framework.

Thanks!

 

Best Regards

James=

 <= /span>

=B7=A2= =BC=FE=C8=CB: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be]
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 17:10
=CA=D5=BC=FE=C8=CB: James Huang; Moti Morgenstern
=B3=AD=CB=CD: ancp@ietf.org
=D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity

 

 =


Hi = James,

 

Some replies = below

 =

From: = ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of James Huang
Sent: donderdag 12 = november 2009 8:59
To: 'Moti = Morgenstern'
Cc: ancp@ietf.org
Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

Hi, = Moti,

 <= /o:p>

Do you mean = we should specify which lower-layer entity should be used to transmit ANCP = message by using ancpAnSessionConfigRelatedEntity?

If yes, = then what is the difference between = ancpAnSessionConfigRelatedInterface    and ancpAnSessionConfigRelatedEntity, as shown below? I think they both = specify an interface in case of Ethernet, it is = duplicated.

 

[Stefaan] Not = only Ethernet is covered but also ATM

 =

  =             &= nbsp;    =A1=AD=A1=AD =            (taken from draft-ietf-ancp-mib-an-04 )

                   ancpAnSessionConfigRelatedInterface     =  InterfaceIndex,

                   ancpAnSessionConfigRelatedEntity            RowPointer,

  =                &= nbsp; ancpAnSessionConfigSvid        &n= bsp;                  &= nbsp;    VlanIdOrNone,

  =             &= nbsp;    =A1=AD=A1=AD

 <= /o:p>

BTW, when = creating an ANCP session, we need to specify the IP addr of the ANCP server =A8C = BRAS; that would be sufficient; what is the point to specify the lower-layer = entity? The AN should choose the lower-layer entity = itself.

 

[Stefaan] = these MIB objects have been added since version 02 of the draft based on a = discussion in February last year.  In principle just specifying the IP address of = the NAS is sufficient but some people preferred to also explicitly configure the underlying interface (VLAN, PVC, ...).  The discussion last year = started with this message = http://www.ietf.org/mail-archive/web/ancp/current/= msg00484.html

 

regards,

Stefaan

 =

 =

Thanks!=

 <= /o:p>

Best = Regards

James

 <= /o:p>

=B7=A2= =BC=FE=C8=CB: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com]
=B7=A2=CB=CD=CA=B1=BC=E4= : 2009=C4=EA11=D4=C212=C8=D5 14:55
=CA=D5=BC=FE=C8=CB: James Huang
=B3=AD=CB=CD: ancp@ietf.org
=D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity

 

Hi = James,

 <= /o:p>

The ANCP = session is always associated with some lower-layer entity, e.g., a virtual bridge = port, an ATM VCC, Ethernet interface, etc.

Notice that = each one of the =A1=B0lower-layer=A1=B1 entities listed here has a different = identifier-type. The bridge port has a port id, the VCC is identified by (ifIndex, VPI, VCI) = and the Ethernet interface has a unique ifIndex = value.

So, the = value in ancpAnSessionConfigRelatedEntity is the SNMP Object ID that uniquely = identifies the associated lower-layer entity.

The format = is therefore, as you understand, an index into another SNMP table. =

 <= /o:p>

Regards,

Moti = Morgenstern

From: = ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of James Huang
Sent: Thursday, November = 12, 2009 8:30 AM
To: ancp@ietf.org
Subject: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity

 

Hi, = all,

 

I have some questions about the implementation of ANCP MIB item ancpAnSessionConfigRelatedEntity; can = anybody give me some idea? Thanks in advance!

 

http://tools.ietf.org/html/draft-ietf-ancp-mib-an-04

 

 ancpAnSessionConfigRelatedEntity OBJECT-TYPE

       SYNTAX      = RowPointer

       MAX-ACCESS  read-create

       STATUS      = current

       = DESCRIPTION

         &= nbsp;   "This object contains the name of an object = instance

         &= nbsp;    uniquely identifying a lower layer entity = associated

         &= nbsp;    with this session.  For example, in the case = where

         &= nbsp;    the session is associated with an ATM VCC, this = object

         &= nbsp;    might be set to an object identifier uniquely = identifying

         &= nbsp;    that VCC (e.g., an object instance in = atmVclTable).

         &= nbsp;    If unused, this object MUST have the value = zeroDotZero.

         &= nbsp;    The value of this object is = persistent."

       DEFVAL { zeroDotZero }

       ::=3D { ancpAnSessionConfigEntry 16 }

 

Question:

1.    =A1=B0a lower layer entity associated with this = session=A1=B1

What is the association between a lower layer entity and an ANCP session? Is = it associated with partition id?

What is the application scenario for this?

 

2.    what is the format of the = name/identifier

"Access-Node-Identifier atm slot/port:vpi.vci", which is defined in TR-101, or an index, = i.e. an index of the atmVclTable?

 

Best = Regards

James

--Boundary_(ID_/W99gSEuLd7EHviVPjhqzQ)-- From Moti.Morgenstern@ecitele.com Mon Nov 16 07:53:40 2009 Return-Path: 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 F3FDE3A6978 for ; Mon, 16 Nov 2009 07:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.094 X-Spam-Level: *** X-Spam-Status: No, score=3.094 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 fIulShc3aXnK for ; Mon, 16 Nov 2009 07:53:38 -0800 (PST) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id F2DF23A67D3 for ; Mon, 16 Nov 2009 07:53:35 -0800 (PST) Received: from ilptexfe.ecitele.com (HELO ilptexch01.ecitele.com) ([172.31.244.40]) by ilptiron01.ecitele.com with ESMTP; 16 Nov 2009 17:43:48 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 16 Nov 2009 17:53:34 +0200 From: Moti Morgenstern To: James Huang , 'DE CNODDER Stefaan' Date: Mon, 16 Nov 2009 17:53:30 +0200 Thread-Topic: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity Thread-Index: AcpjYYkwaK2+4bxQRhKVfLrzrU94UgAANOzwAAJewnAAAre0IAAk5vEQALF5emA= Message-ID: <741F3E4A466A1D439C616902C7F8A8C6FD53535D2B@ILPTMAIL02.ecitele.com> References: <7A6D4815C5E8F74988784FEBD50F2F1E0438C58F@FRVELSMBS22.ad2.ad.alcatel.com> <007601ca640b$bb1e3f60$6228460a@china.huawei.com> In-Reply-To: <007601ca640b$bb1e3f60$6228460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_741F3E4A466A1D439C616902C7F8A8C6FD53535D2BILPTMAIL02eci_" MIME-Version: 1.0 Cc: "ancp@ietf.org" Subject: Re: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity 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: , X-List-Received-Date: Mon, 16 Nov 2009 15:53:40 -0000 --_000_741F3E4A466A1D439C616902C7F8A8C6FD53535D2BILPTMAIL02eci_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNClNlZSBteSBlbWJlZGRlZCByZW1hcmtzLg0KDQpSZWdhcmRzLA0KTW90aSBN b3JnZW5zdGVybg0KDQpGcm9tOiBKYW1lcyBIdWFuZyBbbWFpbHRvOkphbWVzLmh1YW5nQGh1YXdl aS5jb21dDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDEzLCAyMDA5IDQ6NDggQU0NClRvOiAnREUg Q05PRERFUiBTdGVmYWFuJzsgTW90aSBNb3JnZW5zdGVybg0KQ2M6IGFuY3BAaWV0Zi5vcmc7ICd3 YW5neWltaW5nJzsgJ1RpbmEgVFNPVScNClN1YmplY3Q6ILTwuLQ6IFtBTkNQXSBRdWVzdGlvbnMg cmVnYXJkaW5nIEFOQ1AgTUlCIGFuY3BBblNlc3Npb25Db25maWdSZWxhdGVkRW50aXR5DQoNCkhp LCBzdGVmYWFuLA0KDQpJIGhhdmUgcmVhZCB0aGUgZGlzY3Vzc2lvbiB0aHJlYWQgY2FyZWZ1bGx5 Lg0KSW4gbXkgdW5kZXJzdGFuZGluZywgaW4gdGhlIGNhc2Ugb2YgRXRoZXJuZXQsIHdoZW4gY29u ZmlndXJpbmcgYW4gQU5DUCBzZXNzaW9uIGluIHRoZSBBTiwgdGhlIHN0ZXBzIHNob3VsZCBiZSBm b2xsb3dlZDoNCjEuICAgICAgIHNwZWNpZnkgd2hpY2ggc2hvdWxkIGJlIHVzZWQgYnkgYW5jcEFu U2Vzc2lvbkNvbmZpZ1JlbGF0ZWRJbnRlcmZhY2UNCltNTV0gSWYgdGhlIHNlc3Npb24gaXMgbm90 IGFzc29jaWF0ZWQgd2l0aCBhbiBlbnRpdHkgdGhhdCBpcyBpZGVudGlmaWVkIHNvbGVseSBieSBh biBpZkluZGV4IHRoZSBhbmNwQW5TZXNzaW9uQ29uZmlnUmVsYXRlZEVudGl0eSBzaG91bGQgYmUg dXNlZCBpbnN0ZWFkIChvciBhcyB3ZWxsLCBkZXBlbmRpbmcgb24gdGhlIHNwZWNpZmljIGNhc2Up Lg0KMi4gICAgICAgc3BlY2lmeSB3aGljaCBWTEFOIHNob3VsZCBiZSB1c2VkLg0KSWYgdGhlIFZM QU4gZG9lcyBub3QgZXhpc3QsIGl0IHNob3VsZCBiZSBjcmVhdGVkOyBhbmQgYW4gSVAgYWRkcmVz cyBzaG91bGQgYmUgYXNzaWduZWQgdG8gdGhpcyBWTEFOIGludGVyZmFjZSwgd2hpY2ggd291bGQg YmUgdXNlZCBhcyB0aGUNClNvdXJjZSBJUCBhZGRyZXNzIGluIHRoZSBBTkNQIHBhY2tldHM7IGFu ZCBhbHNvIGEgcm91dGluZyB0YWJsZSBzaG91bGQgYmUgYWRkZWQgaWYgbmVjZXNzYXJ5Lg0KW01N XSBUaGUgbWFuYWdlbWVudCBtb2RlbCBvbmx5IGFsbG93cyB5b3UgdG8gaW5kaWNhdGUgdGhhdCBh IHNlc3Npb24gaXMgYXNzb2NpYXRlZCB3aXRoIFMtVkxBTiAob3IgYm90aCBTLSBhbmQgQy1WTEFO KS4gSXQgY3VycmVudGx5IGRvZXMgbm90IHJlZmVyIHRvIHF1ZXN0aW9ucyBsaWtlIKGwV2hhdCBp ZiB0aGUgVkxBTiBkb2VzIG5vdCBleGlzdD+hsSwgobBIb3cgaXMgdGhlIE1TQU6hr3MgSVAgYWRk cmVzcyBmb3IgZWFjaCBzZXNzaW9uIHNwZWNpZmllZD+hsSwgZXRjLg0KDQpJcyB0aGlzIGNvcnJl Y3Q/DQoNCkJ1dCBJIHN0aWxsIGRvIG5vdCBnZXQgdGhlIHBvaW50IHdoeSB3ZSBzaG91bGQgc3Bl Y2lmeSB0aGUgbGF5ZXIyIGludGVyZmFjZSwgYWx0aG91Z2ggaXQgaXMgYWxzbyBkZWZpbmVkIGlu IHRoZSBBTkNQIGZyYW1ld29yay4NCltNTV0gSaGvbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hh dCB5b3UgbWVhbiwgc28gSaGvbGwgdHJ5IHRvIHJlcGVhdCB3aGF0IEkgYWxyZWFkeSB3cm90ZS4g VGhlIEFOQ1Agc2Vzc2lvbiBtYXkgobByaWRlIG92ZXKhsSB2YXJpb3VzIGludGVyZmFjZXMvZW50 aXRpZXMuIFNvbWV0aW1lcyBzdWNoIGFuIGludGVyZmFjZSBoYXMgc2ltcGx5IGFuIGlmSW5kZXgg cGF0dGVybiBidXQgc29tZXRpbWVzIG5vdC4gT25lIGV4YW1wbGUgaXMgdGhlIEFUTSBWQ0MgYnV0 IGl0oa9zIG9ubHkgYW4gZXhhbXBsZS4NCg0KVGhhbmtzIQ0KDQpCZXN0IFJlZ2FyZHMNCkphbWVz DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IERFIENOT0RERVIg U3RlZmFhbiBbbWFpbHRvOnN0ZWZhYW4uZGVfY25vZGRlckBhbGNhdGVsLWx1Y2VudC5iZV0NCrei y83KsbzkOiAyMDA5xOoxMdTCMTLI1SAxNzoxMA0KytW8/sjLOiBKYW1lcyBIdWFuZzsgTW90aSBN b3JnZW5zdGVybg0Ks63LzTogYW5jcEBpZXRmLm9yZw0K1vfM4jogUkU6IFtBTkNQXSBRdWVzdGlv bnMgcmVnYXJkaW5nIEFOQ1AgTUlCIGFuY3BBblNlc3Npb25Db25maWdSZWxhdGVkRW50aXR5DQoN Cg0KDQpIaSBKYW1lcywNCg0KU29tZSByZXBsaWVzIGJlbG93DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBhbmNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphbmNw LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYW1lcyBIdWFuZw0KU2VudDogZG9uZGVy ZGFnIDEyIG5vdmVtYmVyIDIwMDkgODo1OQ0KVG86ICdNb3RpIE1vcmdlbnN0ZXJuJw0KQ2M6IGFu Y3BAaWV0Zi5vcmcNClN1YmplY3Q6IFtBTkNQXSBRdWVzdGlvbnMgcmVnYXJkaW5nIEFOQ1AgTUlC IGFuY3BBblNlc3Npb25Db25maWdSZWxhdGVkRW50aXR5DQoNCkhpLCBNb3RpLA0KDQpEbyB5b3Ug bWVhbiB3ZSBzaG91bGQgc3BlY2lmeSB3aGljaCBsb3dlci1sYXllciBlbnRpdHkgc2hvdWxkIGJl IHVzZWQgdG8gdHJhbnNtaXQgQU5DUCBtZXNzYWdlIGJ5IHVzaW5nIGFuY3BBblNlc3Npb25Db25m aWdSZWxhdGVkRW50aXR5Pw0KSWYgeWVzLCB0aGVuIHdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0 d2VlbiBhbmNwQW5TZXNzaW9uQ29uZmlnUmVsYXRlZEludGVyZmFjZSAgICBhbmQgYW5jcEFuU2Vz c2lvbkNvbmZpZ1JlbGF0ZWRFbnRpdHksIGFzIHNob3duIGJlbG93PyBJIHRoaW5rIHRoZXkgYm90 aCBzcGVjaWZ5IGFuIGludGVyZmFjZSBpbiBjYXNlIG9mIEV0aGVybmV0LCBpdCBpcyBkdXBsaWNh dGVkLg0KDQpbU3RlZmFhbl0gTm90IG9ubHkgRXRoZXJuZXQgaXMgY292ZXJlZCBidXQgYWxzbyBB VE0NCg0KICAgICAgICAgICAgICAgICAgIKGtoa0gICAgICAgICAgICAodGFrZW4gZnJvbSBkcmFm dC1pZXRmLWFuY3AtbWliLWFuLTA0ICkNCiAgICAgICAgICAgICAgICAgICBhbmNwQW5TZXNzaW9u Q29uZmlnUmVsYXRlZEludGVyZmFjZSAgICAgIEludGVyZmFjZUluZGV4LA0KICAgICAgICAgICAg ICAgICAgIGFuY3BBblNlc3Npb25Db25maWdSZWxhdGVkRW50aXR5ICAgICAgICAgICAgUm93UG9p bnRlciwNCiAgICAgICAgICAgICAgICAgICBhbmNwQW5TZXNzaW9uQ29uZmlnU3ZpZCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgVmxhbklkT3JOb25lLA0KICAgICAgICAgICAgICAgICAg IKGtoa0NCg0KQlRXLCB3aGVuIGNyZWF0aW5nIGFuIEFOQ1Agc2Vzc2lvbiwgd2UgbmVlZCB0byBz cGVjaWZ5IHRoZSBJUCBhZGRyIG9mIHRoZSBBTkNQIHNlcnZlciCoQyBCUkFTOyB0aGF0IHdvdWxk IGJlIHN1ZmZpY2llbnQ7IHdoYXQgaXMgdGhlIHBvaW50IHRvIHNwZWNpZnkgdGhlIGxvd2VyLWxh eWVyIGVudGl0eT8gVGhlIEFOIHNob3VsZCBjaG9vc2UgdGhlIGxvd2VyLWxheWVyIGVudGl0eSBp dHNlbGYuDQoNCltTdGVmYWFuXSB0aGVzZSBNSUIgb2JqZWN0cyBoYXZlIGJlZW4gYWRkZWQgc2lu Y2UgdmVyc2lvbiAwMiBvZiB0aGUgZHJhZnQgYmFzZWQgb24gYSBkaXNjdXNzaW9uIGluIEZlYnJ1 YXJ5IGxhc3QgeWVhci4gIEluIHByaW5jaXBsZSBqdXN0IHNwZWNpZnlpbmcgdGhlIElQIGFkZHJl c3Mgb2YgdGhlIE5BUyBpcyBzdWZmaWNpZW50IGJ1dCBzb21lIHBlb3BsZSBwcmVmZXJyZWQgdG8g YWxzbyBleHBsaWNpdGx5IGNvbmZpZ3VyZSB0aGUgdW5kZXJseWluZyBpbnRlcmZhY2UgKFZMQU4s IFBWQywgLi4uKS4gIFRoZSBkaXNjdXNzaW9uIGxhc3QgeWVhciBzdGFydGVkIHdpdGggdGhpcyBt ZXNzYWdlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hbmNwL2N1cnJlbnQv bXNnMDA0ODQuaHRtbA0KDQpyZWdhcmRzLA0KU3RlZmFhbg0KDQoNClRoYW5rcyENCg0KQmVzdCBS ZWdhcmRzDQpKYW1lcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjL OiBNb3RpIE1vcmdlbnN0ZXJuIFttYWlsdG86TW90aS5Nb3JnZW5zdGVybkBlY2l0ZWxlLmNvbV0N Creiy83KsbzkOiAyMDA5xOoxMdTCMTLI1SAxNDo1NQ0KytW8/sjLOiBKYW1lcyBIdWFuZw0Ks63L zTogYW5jcEBpZXRmLm9yZw0K1vfM4jogUkU6IFtBTkNQXSBRdWVzdGlvbnMgcmVnYXJkaW5nIEFO Q1AgTUlCIGFuY3BBblNlc3Npb25Db25maWdSZWxhdGVkRW50aXR5DQoNCkhpIEphbWVzLA0KDQpU aGUgQU5DUCBzZXNzaW9uIGlzIGFsd2F5cyBhc3NvY2lhdGVkIHdpdGggc29tZSBsb3dlci1sYXll ciBlbnRpdHksIGUuZy4sIGEgdmlydHVhbCBicmlkZ2UgcG9ydCwgYW4gQVRNIFZDQywgRXRoZXJu ZXQgaW50ZXJmYWNlLCBldGMuDQpOb3RpY2UgdGhhdCBlYWNoIG9uZSBvZiB0aGUgobBsb3dlci1s YXllcqGxIGVudGl0aWVzIGxpc3RlZCBoZXJlIGhhcyBhIGRpZmZlcmVudCBpZGVudGlmaWVyLXR5 cGUuIFRoZSBicmlkZ2UgcG9ydCBoYXMgYSBwb3J0IGlkLCB0aGUgVkNDIGlzIGlkZW50aWZpZWQg YnkgKGlmSW5kZXgsIFZQSSwgVkNJKSBhbmQgdGhlIEV0aGVybmV0IGludGVyZmFjZSBoYXMgYSB1 bmlxdWUgaWZJbmRleCB2YWx1ZS4NClNvLCB0aGUgdmFsdWUgaW4gYW5jcEFuU2Vzc2lvbkNvbmZp Z1JlbGF0ZWRFbnRpdHkgaXMgdGhlIFNOTVAgT2JqZWN0IElEIHRoYXQgdW5pcXVlbHkgaWRlbnRp ZmllcyB0aGUgYXNzb2NpYXRlZCBsb3dlci1sYXllciBlbnRpdHkuDQpUaGUgZm9ybWF0IGlzIHRo ZXJlZm9yZSwgYXMgeW91IHVuZGVyc3RhbmQsIGFuIGluZGV4IGludG8gYW5vdGhlciBTTk1QIHRh YmxlLg0KDQpSZWdhcmRzLA0KTW90aSBNb3JnZW5zdGVybg0KRnJvbTogYW5jcC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86YW5jcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFtZXMg SHVhbmcNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxMiwgMjAwOSA4OjMwIEFNDQpUbzogYW5j cEBpZXRmLm9yZw0KU3ViamVjdDogW0FOQ1BdIFF1ZXN0aW9ucyByZWdhcmRpbmcgQU5DUCBNSUIg YW5jcEFuU2Vzc2lvbkNvbmZpZ1JlbGF0ZWRFbnRpdHkNCg0KSGksIGFsbCwNCg0KSSBoYXZlIHNv bWUgcXVlc3Rpb25zIGFib3V0IHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBBTkNQIE1JQiBpdGVtIGFu Y3BBblNlc3Npb25Db25maWdSZWxhdGVkRW50aXR5OyBjYW4gYW55Ym9keSBnaXZlIG1lIHNvbWUg aWRlYT8gVGhhbmtzIGluIGFkdmFuY2UhDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtYW5jcC1taWItYW4tMDQNCg0KIGFuY3BBblNlc3Npb25Db25maWdSZWxhdGVkRW50 aXR5IE9CSkVDVC1UWVBFDQogICAgICAgU1lOVEFYICAgICAgUm93UG9pbnRlcg0KICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtY3JlYXRlDQogICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAgIlRoaXMgb2JqZWN0IGNvbnRhaW5zIHRoZSBuYW1l IG9mIGFuIG9iamVjdCBpbnN0YW5jZQ0KICAgICAgICAgICAgICB1bmlxdWVseSBpZGVudGlmeWlu ZyBhIGxvd2VyIGxheWVyIGVudGl0eSBhc3NvY2lhdGVkDQogICAgICAgICAgICAgIHdpdGggdGhp cyBzZXNzaW9uLiAgRm9yIGV4YW1wbGUsIGluIHRoZSBjYXNlIHdoZXJlDQogICAgICAgICAgICAg IHRoZSBzZXNzaW9uIGlzIGFzc29jaWF0ZWQgd2l0aCBhbiBBVE0gVkNDLCB0aGlzIG9iamVjdA0K ICAgICAgICAgICAgICBtaWdodCBiZSBzZXQgdG8gYW4gb2JqZWN0IGlkZW50aWZpZXIgdW5pcXVl bHkgaWRlbnRpZnlpbmcNCiAgICAgICAgICAgICAgdGhhdCBWQ0MgKGUuZy4sIGFuIG9iamVjdCBp bnN0YW5jZSBpbiBhdG1WY2xUYWJsZSkuDQogICAgICAgICAgICAgIElmIHVudXNlZCwgdGhpcyBv YmplY3QgTVVTVCBoYXZlIHRoZSB2YWx1ZSB6ZXJvRG90WmVyby4NCiAgICAgICAgICAgICAgVGhl IHZhbHVlIG9mIHRoaXMgb2JqZWN0IGlzIHBlcnNpc3RlbnQuIg0KICAgICAgIERFRlZBTCB7IHpl cm9Eb3RaZXJvIH0NCiAgICAgICA6Oj0geyBhbmNwQW5TZXNzaW9uQ29uZmlnRW50cnkgMTYgfQ0K DQpRdWVzdGlvbjoNCjEuICChsGEgbG93ZXIgbGF5ZXIgZW50aXR5IGFzc29jaWF0ZWQgd2l0aCB0 aGlzIHNlc3Npb26hsQ0KV2hhdCBpcyB0aGUgYXNzb2NpYXRpb24gYmV0d2VlbiBhIGxvd2VyIGxh eWVyIGVudGl0eSBhbmQgYW4gQU5DUCBzZXNzaW9uPyBJcyBpdCBhc3NvY2lhdGVkIHdpdGggcGFy dGl0aW9uIGlkPw0KV2hhdCBpcyB0aGUgYXBwbGljYXRpb24gc2NlbmFyaW8gZm9yIHRoaXM/DQoN CjIuICB3aGF0IGlzIHRoZSBmb3JtYXQgb2YgdGhlIG5hbWUvaWRlbnRpZmllcg0KIkFjY2Vzcy1O b2RlLUlkZW50aWZpZXIgYXRtIHNsb3QvcG9ydDp2cGkudmNpIiwgd2hpY2ggaXMgZGVmaW5lZCBp biBUUi0xMDEsIG9yIGFuIGluZGV4LCBpLmUuIGFuIGluZGV4IG9mIHRoZSBhdG1WY2xUYWJsZT8N Cg0KQmVzdCBSZWdhcmRzDQpKYW1lcw0K --_000_741F3E4A466A1D439C616902C7F8A8C6FD53535D2BILPTMAIL02eci_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi James,

 

See my embedded remarks.

 

Regards,

Moti Morgenstern

 

From: James Huang [mailto:James.huang@huawei.com]
Sent: Friday, November 13, 2009 4:48 AM
To: 'DE CNODDER Stefaan'; Moti Morgenstern
Cc: ancp@ietf.org; 'wangyiming'; 'Tina TSOU'
Subject: =B4=F0=B8=B4: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

Hi, = stefaan,

 

I = have read the discussion thread carefully.

In= my understanding, in the case of Ethernet, when configuring an ANCP session in= the AN, the steps should be followed:

1.      = specif= y which should be used by ancpAnSessionConfigRelatedInterface     &n= bsp;

[MM] If the session is not associated with an entity that is identified solely by an ifIndex the ancpAnSessionConfigRelatedEntity should= be used instead (or as well, depending on the specific case).

2.      = specif= y which VLAN should be used.

If the VLAN does not exist, it should be created; and a= n IP address should be assigned to this VLAN interface, which would be used as t= he

Source IP address in the ANCP packets; and also a routi= ng table should be added if necessary.

[MM] The management model only allows you to indicate that a session is associated with S-VLAN (or both S- and C-VLAN). It currently doe= s not refer to questions like =A1=B0What if the VLAN does not exist?=A1=B1, = =A1=B0How is the MSAN=A1=AFs IP address for each session specified?=A1=B1, etc.

 

Is= this correct?

 

Bu= t I still do not get the point why we should specify the layer2 interface, alth= ough it is also defined in the ANCP framework.

[MM] I=A1=AFm not sure I understand what you mean, so I=A1= =AFll try to repeat what I already wrote. The ANCP session may =A1=B0ride over=A1=B1 var= ious interfaces/entities. Sometimes such an interface has simply an ifIndex pattern but sometimes not= . One example is the ATM VCC but it=A1=AFs only an example.

 

Th= anks!

 

Be= st Regards

Ja= mes=

 

=B7=A2=BC=FE=C8=CB<= /span>: DE CNODDER Stefaan [mailto:stefaan.de_cnodder@alcatel-lucent.be]
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 17:10
=CA=D5=BC=FE=C8=CB: James Huang; Moti Morgenstern
=B3=AD=CB=CD: ancp@ietf.org
=D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

 


Hi James,

 

Some replies below

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ja= mes Huang
Sent: donderdag 12 november 2009 8:59
To: 'Moti Morgenstern'
Cc: ancp@ietf.org
Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

Hi, Moti,

 

Do you mean we should specify which lower-layer entity shoul= d be used to transmit ANCP message by using ancpAnSessionConfigRelatedEntity?

If yes, then what is the difference between ancpAnSessionConfigRelatedInterface    and ancpAnSessionConfigRelatedEntity, as shown below? I think they both specify= an interface in case of Ethernet, it is duplicated.

 

[Stefaan] Not only Ethernet is covered but also ATM

 

          =          =A1=AD=A1=AD            (= taken from draft-ietf-ancp-mib-an-04 )

                   ancpAnSessionConfigRelatedInterface      InterfaceIndex= ,

                   ancpAnSessionConfigRelatedEntity            RowPointer,

                 &nb= sp; ancpAnSessionConfigSvid        &nbs= p;                  &nb= sp;    VlanIdOrNone,

          =          =A1=AD=A1=AD

 

BTW, when creating an ANCP session, we need to specify the I= P addr of the ANCP server =A8C BRAS; that would be sufficient; what is the po= int to specify the lower-layer entity? The AN should choose the lower-layer entity itself.

 

[Stefaan] these MIB objects have been added since version 02 = of the draft based on a discussion in February last year.  In principle j= ust specifying the IP address of the NAS is sufficient but some people preferre= d to also explicitly configure the underlying interface (VLAN, PVC, ...).  = The discussion last year started with this message http://www.ietf.org/mail-archive/web/ancp/current/ms= g00484.html

 

regards,

Stefaan

 

 

Thanks!

 

Best Regards

James

 

=B7=A2=BC=FE=C8=CB<= /span>: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 14:55
=CA=D5=BC=FE=C8=CB: James Huang
=B3=AD=CB=CD: ancp@ietf.org
=D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

Hi James,

 

The ANCP session is always associated with some lower-layer entity, e.g., a virtual bridge port, an ATM VCC, Ethernet interface, etc.

Notice that each one of the =A1=B0lower-layer=A1=B1 entities= listed here has a different identifier-type. The bridge port has a port id, the VCC is identified by (ifIndex, VPI, VCI) and the Ethernet interface has a unique ifIndex value.

So, the value in ancpAnSessionConfigRelatedEntity is the SNM= P Object ID that uniquely identifies the associated lower-layer entity.<= /o:p>

The format is therefore, as you understand, an index into another SNMP table.

 

Regards,

Moti Morgenstern

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ja= mes Huang
Sent: Thursday, November 12, 2009 8:30 AM
To: ancp@ietf.org
Subject: [ANCP] Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity

 

Hi, all,

 = ;

I have som= e questions about the implementation of ANCP MIB item ancpAnSessionConfigRelatedEntity; can anybody give me some idea? Thanks in advance!

 = ;

http://too= ls.ietf.org/html/draft-ietf-ancp-mib-an-04

 = ;

 ancp= AnSessionConfigRelatedEntity OBJECT-TYPE

 &nbs= p;     SYNTAX      RowPointer

 &nbs= p;     MAX-ACCESS  read-create

 &nbs= p;     STATUS      current

 &nbs= p;     DESCRIPTION

 &nbs= p;           "This object contains the name of an object instance=

 &nbs= p;            uniquely identifying a lower layer entity associated

 &nbs= p;            with this session.  For example, in the case where

 &nbs= p;            the session is associated with an ATM VCC, this object

 &nbs= p;            might be set to an object identifier uniquely identifying=

 &nbs= p;            that VCC (e.g., an object instance in atmVclTable).

 &nbs= p;            If unused, this object MUST have the value zeroDotZero.

 &nbs= p;            The value of this object is persistent."

 &nbs= p;     DEFVAL { zeroDotZero }

       ::=3D { ancpAnSessionConf= igEntry 16 }

 

Question:

1.&n= bsp; =A1=B0a lower layer entity associated with this session=A1=B1<= o:p>

What is the association between a lower layer entity and an AN= CP session? Is it associated with partition id?

What is the application scenario for this?

 

2.&n= bsp; what is the format of the name/identifier

"Access-Node-Identifier atm slot/port:vpi.vci", whic= h is defined in TR-101, or an index, i.e. an index of the atmVclTable?

 = ;

Best Regar= ds

James=

--_000_741F3E4A466A1D439C616902C7F8A8C6FD53535D2BILPTMAIL02eci_-- From wdec@cisco.com Tue Nov 17 06:28:36 2009 Return-Path: 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 64B8A3A6AB8 for ; Tue, 17 Nov 2009 06:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 7mD43Zg0k7dK for ; Tue, 17 Nov 2009 06:28:34 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A4C3E3A6972 for ; Tue, 17 Nov 2009 06:28:34 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEADdCAkuQ/uCW/2dsb2JhbACCIyuCF7pqhwgIkRWDY1gEgW0 X-IronPort-AV: E=Sophos;i="4.44,758,1249257600"; d="scan'208,217";a="271929456" Received: from ams-core-1.cisco.com ([144.254.224.150]) by sj-iport-1.cisco.com with ESMTP; 17 Nov 2009 14:28:31 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAHESVwG002704; Tue, 17 Nov 2009 14:28:31 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 15:28:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6792.362E658A" Date: Tue, 17 Nov 2009 15:28:12 +0100 Message-ID: In-Reply-To: <007601ca640b$bb1e3f60$6228460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ??: Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity Thread-Index: AcpjYYkwaK2+4bxQRhKVfLrzrU94UgAANOzwAAJewnAAAre0IAAk5vEQAOG7KXA= References: <7A6D4815C5E8F74988784FEBD50F2F1E0438C58F@FRVELSMBS22.ad2.ad.alcatel.com> <007601ca640b$bb1e3f60$6228460a@china.huawei.com> From: "Wojciech Dec (wdec)" To: "James Huang" , "DE CNODDER Stefaan" , "Moti Morgenstern" X-OriginalArrivalTime: 17 Nov 2009 14:28:20.0741 (UTC) FILETIME=[364D6B50:01CA6792] Cc: ancp@ietf.org Subject: Re: [ANCP] ??: Questions regarding ANCP MIB ancpAnSessionConfigRelatedEntity 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: , X-List-Received-Date: Tue, 17 Nov 2009 14:28:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6792.362E658A Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Hi James, =20 your observation is correct and points to a topic that was discussed at = some stage, although unfortunately the framework was never corrected: As = ANCP is an IP protocol, designating a VLAN is rather pointless. The task = of configuring an IP interface, which could be used for ANCP traffic = along and a VLAN for that interface is not ANCP's role and IMO should = not be reflected in the MIBs by other means that having ANCP reference = an existing IP interface (which may in turn have a VLAN). =20 Given that the ANCP MIB document is sorely needing review (it cannot = progress further without a more complete WG review), we would welcome = your feedback and suggestions for improvement. =20 Thanks, Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = James Huang Sent: 13 November 2009 03:48 To: 'DE CNODDER Stefaan'; 'Moti Morgenstern' Cc: ancp@ietf.org Subject: [ANCP] ??: Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity =09 =09 Hi, stefaan, =20 I have read the discussion thread carefully. In my understanding, in the case of Ethernet, when configuring an ANCP = session in the AN, the steps should be followed: 1. specify which should be used by = ancpAnSessionConfigRelatedInterface =20 2. specify which VLAN should be used. If the VLAN does not exist, it should be created; and an IP address = should be assigned to this VLAN interface, which would be used as the=20 Source IP address in the ANCP packets; and also a routing table should = be added if necessary. =20 Is this correct? =20 But I still do not get the point why we should specify the layer2 = interface, although it is also defined in the ANCP framework. Thanks! =20 Best Regards James =20 =09 ________________________________ =B7=A2=BC=FE=C8=CB: DE CNODDER Stefaan = [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 17:10 =CA=D5=BC=FE=C8=CB: James Huang; Moti Morgenstern =B3=AD=CB=CD: ancp@ietf.org =D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity =20 =20 Hi James, =20 Some replies below =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = James Huang Sent: donderdag 12 november 2009 8:59 To: 'Moti Morgenstern' Cc: ancp@ietf.org Subject: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity =20 Hi, Moti, =20 Do you mean we should specify which lower-layer entity should be used = to transmit ANCP message by using ancpAnSessionConfigRelatedEntity? If yes, then what is the difference between = ancpAnSessionConfigRelatedInterface and = ancpAnSessionConfigRelatedEntity, as shown below? I think they both = specify an interface in case of Ethernet, it is duplicated. =20 [Stefaan] Not only Ethernet is covered but also ATM =20 =A1=AD=A1=AD (taken from = draft-ietf-ancp-mib-an-04 ) ancpAnSessionConfigRelatedInterface = InterfaceIndex, ancpAnSessionConfigRelatedEntity = RowPointer, ancpAnSessionConfigSvid = VlanIdOrNone, =A1=AD=A1=AD =20 BTW, when creating an ANCP session, we need to specify the IP addr of = the ANCP server =A8C BRAS; that would be sufficient; what is the point = to specify the lower-layer entity? The AN should choose the lower-layer = entity itself. =20 [Stefaan] these MIB objects have been added since version 02 of the = draft based on a discussion in February last year. In principle just = specifying the IP address of the NAS is sufficient but some people = preferred to also explicitly configure the underlying interface (VLAN, = PVC, ...). The discussion last year started with this message = http://www.ietf.org/mail-archive/web/ancp/current/msg00484.html = =20 =20 regards, Stefaan =20 =20 Thanks! =20 Best Regards James =20 =09 ________________________________ =B7=A2=BC=FE=C8=CB: Moti Morgenstern = [mailto:Moti.Morgenstern@ecitele.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 14:55 =CA=D5=BC=FE=C8=CB: James Huang =B3=AD=CB=CD: ancp@ietf.org =D6=F7=CC=E2: RE: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity =20 Hi James, =20 The ANCP session is always associated with some lower-layer entity, = e.g., a virtual bridge port, an ATM VCC, Ethernet interface, etc. Notice that each one of the =A1=B0lower-layer=A1=B1 entities listed = here has a different identifier-type. The bridge port has a port id, the = VCC is identified by (ifIndex, VPI, VCI) and the Ethernet interface has = a unique ifIndex value. So, the value in ancpAnSessionConfigRelatedEntity is the SNMP Object ID = that uniquely identifies the associated lower-layer entity. The format is therefore, as you understand, an index into another SNMP = table.=20 =20 Regards, Moti Morgenstern From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = James Huang Sent: Thursday, November 12, 2009 8:30 AM To: ancp@ietf.org Subject: [ANCP] Questions regarding ANCP MIB = ancpAnSessionConfigRelatedEntity =20 Hi, all, =20 I have some questions about the implementation of ANCP MIB item = ancpAnSessionConfigRelatedEntity; can anybody give me some idea? Thanks = in advance! =20 http://tools.ietf.org/html/draft-ietf-ancp-mib-an-04 =20 ancpAnSessionConfigRelatedEntity OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "This object contains the name of an object instance uniquely identifying a lower layer entity associated with this session. For example, in the case where the session is associated with an ATM VCC, this object might be set to an object identifier uniquely identifying that VCC (e.g., an object instance in atmVclTable). If unused, this object MUST have the value zeroDotZero. The value of this object is persistent." DEFVAL { zeroDotZero } ::=3D { ancpAnSessionConfigEntry 16 } =20 Question: 1. =A1=B0a lower layer entity associated with this session=A1=B1 What is the association between a lower layer entity and an ANCP = session? Is it associated with partition id? What is the application scenario for this? =20 2. what is the format of the name/identifier "Access-Node-Identifier atm slot/port:vpi.vci", which is defined in = TR-101, or an index, i.e. an index of the atmVclTable? =20 Best Regards James ------_=_NextPart_001_01CA6792.362E658A Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
Hi James,
 
your observation is correct and points to a topic that was = discussed at=20 some stage, although unfortunately the framework was never corrected: As = ANCP is=20 an IP protocol, designating a VLAN is rather pointless. The task of = configuring=20 an IP interface, which could be used for ANCP = traffic along and a VLAN=20 for that interface is not ANCP's role and IMO should not be reflected in = the=20 MIBs by other means that having ANCP reference an existing = IP interface=20 (which may in turn have a VLAN).
 
Given that the ANCP MIB document is sorely needing review (it = cannot=20 progress further without a more complete WG review), we would = welcome your=20 feedback and suggestions for improvement.
 
Thanks,
Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of James = Huang
Sent:=20 13 November 2009 03:48
To: 'DE CNODDER Stefaan'; 'Moti=20 Morgenstern'
Cc: ancp@ietf.org
Subject: [ANCP] ??: = Questions regarding ANCP MIB=20 ancpAnSessionConfigRelatedEntity

Hi,=20 stefaan,

 

I have read the = discussion thread=20 carefully.

In my = understanding, in the case of=20 Ethernet, when configuring an ANCP session in the AN, the steps should = be=20 followed:

1.    =20 specify which should be=20 used by ancpAnSessionConfigRelatedInterface    =20  

2.    =20 specify which VLAN should=20 be used.

If = the VLAN does not=20 exist, it should be created; and an IP address should be assigned to = this VLAN=20 interface, which would be used as the

Source IP address in the=20 ANCP packets; and also a routing table should be added if=20 necessary.

 

Is this=20 correct?

 

But I still do = not get the point why=20 we should specify the layer2 interface, although it is also defined in = the=20 ANCP framework.

Thanks!

 

Best=20 Regards

James

 

=B7=A2=BC=FE=C8=CB: DE CNODDER = Stefaan=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be] =
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C212=C8=D5 = 17:10
=CA=D5=BC=FE=C8=CB: James Huang; = Moti=20 Morgenstern
=B3=AD=CB=CD:=20 ancp@ietf.org
=D6=F7=CC=E2: RE: [ANCP] = Questions regarding ANCP=20 MIB ancpAnSessionConfigRelatedEntity

 

 

Hi=20 James,

 

Some = replies=20 below

 

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On = Behalf Of=20 James Huang
Sent:=20 donderdag 12 november 2009 8:59
To: 'Moti = Morgenstern'
Cc: ancp@ietf.org
Subject: [ANCP] Questions = regarding ANCP=20 MIB ancpAnSessionConfigRelatedEntity

 

Hi,=20 Moti,

 

Do you = mean we=20 should specify which lower-layer entity should be used to transmit = ANCP=20 message by using=20 ancpAnSessionConfigRelatedEntity?

If = yes, then=20 what is the difference between=20 ancpAnSessionConfigRelatedInterface    and=20 ancpAnSessionConfigRelatedEntity, as shown below? I think they both = specify an=20 interface in case of Ethernet, it is = duplicated.

 

[Stefaan] = Not only=20 Ethernet is covered but also ATM

 

          &nbs= p;       =20 =A1=AD=A1=AD =            (taken from = draft-ietf-ancp-mib-an-04 )

      =20            =20 ancpAnSessionConfigRelatedInterface    =20  InterfaceIndex,

      =20            =20 ancpAnSessionConfigRelatedEntity      =20      RowPointer,

    =20 =             &= nbsp;=20 = ancpAnSessionConfigSvid        &n= bsp;     =20 =             &= nbsp;  =20  VlanIdOrNone,

          &nbs= p;       =20 =A1=AD=A1=AD

 

BTW, = when=20 creating an ANCP session, we need to specify the IP addr of the ANCP = server =A8C=20 BRAS; that would be sufficient; what is the point to specify the = lower-layer=20 entity? The AN should choose the lower-layer entity=20 itself.

 

[Stefaan] = these MIB=20 objects have been added since version 02 of the draft based on a = discussion in=20 February last year.  In principle just specifying the IP address = of the=20 NAS is sufficient but some people preferred to also explicitly = configure the=20 underlying interface (VLAN, PVC, ...).  The discussion last year = started=20 with this message = http://www.ietf.org/mail-archive/web/ancp/current/msg00484.html=20

 

regards,

Stefaan

 

 

Thanks!

 

Best=20 Regards

James

 

=B7=A2=BC=FE=C8=CB: Moti=20 Morgenstern [mailto:Moti.Morgenstern@ecitele.com] =
=B7=A2=CB=CD=CA=B1=BC=E4:=20 2009=C4=EA11=D4=C212=C8=D5 = 14:55
=CA=D5=BC=FE=C8=CB:=20 James Huang
=B3=AD=CB=CD:=20 ancp@ietf.org
=D6=F7=CC=E2: RE:=20 [ANCP] Questions regarding ANCP MIB=20 ancpAnSessionConfigRelatedEntity

 

Hi=20 James,

 

The = ANCP session=20 is always associated with some lower-layer entity, e.g., a virtual = bridge=20 port, an ATM VCC, Ethernet interface, = etc.

Notice = that each=20 one of the =A1=B0lower-layer=A1=B1 entities listed here has a = different identifier-type.=20 The bridge port has a port id, the VCC is identified by (ifIndex, VPI, = VCI)=20 and the Ethernet interface has a unique ifIndex=20 value.

So, = the value in=20 ancpAnSessionConfigRelatedEntity is the SNMP Object ID that uniquely=20 identifies the associated lower-layer = entity.

The = format is=20 therefore, as you understand, an index into another SNMP table.=20

 

Regards,

Moti=20 Morgenstern

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On = Behalf Of=20 James Huang
Sent:=20 Thursday, November 12, 2009 8:30 AM
To: ancp@ietf.org
Subject: [ANCP] Questions = regarding ANCP=20 MIB = ancpAnSessionConfigRelatedEntity

=

 

Hi,=20 all,

 

I = have some=20 questions about the implementation of ANCP MIB item=20 ancpAnSessionConfigRelatedEntity; can anybody give me some idea? = Thanks in=20 advance!

 

http://tools.ietf.org/html/draft-ietf-ancp-mib-an-04

 

 ancpAnSessionConfigRelatedEntity=20 OBJECT-TYPE

      =20 SYNTAX      = RowPointer

      =20 MAX-ACCESS  read-create

      =20 STATUS      = current

      =20 DESCRIPTION

           &= nbsp;=20 "This object contains the name of an object=20 instance

           &= nbsp; =20 uniquely identifying a lower layer entity=20 associated

           &= nbsp; =20 with this session.  For example, in the case=20 where

           &= nbsp; =20 the session is associated with an ATM VCC, this=20 object

           &= nbsp; =20 might be set to an object identifier uniquely=20 identifying

           &= nbsp; =20 that VCC (e.g., an object instance in=20 atmVclTable).

           &= nbsp; =20 If unused, this object MUST have the value=20 zeroDotZero.

           &= nbsp; =20 The value of this object is persistent."

      =20 DEFVAL { zeroDotZero }

      =20 ::=3D { ancpAnSessionConfigEntry 16 }

 

Question:

1.   =20 =A1=B0a lower=20 layer entity associated with this = session=A1=B1

What is the=20 association between a lower layer entity and an ANCP session? Is it = associated=20 with partition id?

What is the=20 application scenario for this?

 

2.   =20 what is the=20 format of the name/identifier

"Access-Node-Identifier=20 atm slot/port:vpi.vci", which is defined in TR-101, or an index, i.e. = an index=20 of the atmVclTable?

 

Best=20 Regards

James

= ------_=_NextPart_001_01CA6792.362E658A--