Sanjay, What do you mean "why I reference an old draft" ???????????? I'm surprised you even ask... please take a look at YOUR own internet-draft that most of the ANCP working implementations are based on, in case you do noFrom ancp-bounces at ietf.org Wed Apr 30 16:20:17 2008 Return-Path: <ancp-bounces at ietf.org> X-Original-To: ancp-archive at optimus.ietf.org Delivered-To: ietfarch-ancp-archive at core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8661B28C319; Wed, 30 Apr 2008 16:20:17 -0700 (PDT) X-Original-To: ancp at core3.amsl.com Delivered-To: ancp at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6ABE3A677D for <ancp at core3.amsl.com>; Wed, 30 Apr 2008 16:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_83=0.6] 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 WvgIMSUkXXX4 for <ancp at core3.amsl.com>; Wed, 30 Apr 2008 16:20:08 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 2BFA828C368 for <ancp at ietf.org>; Wed, 30 Apr 2008 16:20:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8C63C938B60; Wed, 30 Apr 2008 16:20:10 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04747-01; Wed, 30 Apr 2008 16:20:09 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 6476F65E99F; Wed, 30 Apr 2008 16:20:05 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Wed, 30 Apr 2008 16:20:05 -0700 From: Peter Arberg <parberg at redback.com> To: Sanjay Wadhwa <swadhwa at juniper.net>, Tina TSOU <tena at huawei.com>, Maglione Roberta <roberta.maglione at telecomitalia.it>, "Wojciech Dec (wdec)" <wdec at cisco.com> Date: Wed, 30 Apr 2008 16:20:02 -0700 Thread-Topic: [ANCP] question regarding Labels in ANCP port up messages Thread-Index: Aciqkn5nSPBPuwuySsamcvxF1uU6kQAZ9dQQAAE415AABe3TAA=Message-ID: <48C276B536524E478C659685995F6AA539DBBBE577 at RBSJX.ad.redback.com> References: <48C276B536524E478C659685995F6AA539DBBBE370 at RBSJX.ad.redback.com> <9BD5D7887235424FA97DFC223CAE3C280AB43A10 at proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280AB43A10 at proton.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_48C276B536524E478C659685995F6AA539DBBBE577RBSJXadredbac_" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com Cc: "ancp at ietf.org" <ancp at ietf.org> Subject: Re: [ANCP] question regarding Labels in ANCP port up messages X-BeenThere: ancp at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request at ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ancp> List-Post: <mailto:ancp at ietf.org> List-Help: <mailto:ancp-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request at ietf.org?subject=subscribe> Sender: ancp-bounces at ietf.org Errors-To: ancp-bounces at ietf.org
From: Sanjay Wadhwa [mailto:swadhwa at juniper.net]
Sent: 30. april 2008 14:42
To: Peter Arberg; Tina TSOU; Maglione Roberta; Wojciech Dec (wdec)
Cc: ancp at ietf.org
Subject: RE: [ANCP] question regarding Labels in ANCP port up messagesPeter
The ANCP draft as it currently stands is based on RFC3292. It provides extensions and modifications to relevant constructs in RFC3292. There is no mention (implicit or explicit) of expired GSMP drafts in the ANCP draft. In order to implement the ANCP draft, I am not sure why one would look at the expired GSMP drafts. Do you see a reason to do this based on anything that you read in the ANCP draft? Bringing up reference to expired gsmp draft in this thread just adds to the confusion. For GSMPv3 objects in the messages (such as Label Type), one has to look at RFC3292 (this is clearly stated in the ANCP draft - section 2 and I am quoting it below) :ANCP uses a subset of GSMPv3 messages to implement currently defined use-cases. These relevant GSMPv3 messages are identified in section 5. GSMPv3 procedures with suitable extensions, as used by ANCP, are described in sections 5.1, 5.2 and 5.3. GSMPv3 general extensions and GSMPv3 message specific extensions required by ANCP are described in sub-sections of 5.4. In addition to specifying extensions and modifications to relevant GSMP messages applicable to ANCP, this draft also defines the usage of these messages by ANCP, and indicates the values that ANCP should set for relevant fields in these GSMP messages. However, to understand the basic semantics of various fields in GSMP messages, the reader is referred to [4]. => RFC 3292.
What existing implementations currently do is an important but separate issue. These implementations for most part precede the current ANCP draft. It is fine to poll where these implementations diverge from the current draft. It is then upto the implementations (including the one that I am somewhat familiar with) to work towards compliance with the draft.On the following points from Woj:
Woj>2) The current version of the spec is not accurate, and does not reflect the fact that the known implementations follow the label field definition from draft-gsmpv3-base-spec.
It is not for the protocol draft to point out what current implementations do. The best we can do is to further clarify in the draft that type and value fields of the Label object (defined in RFC3292) should be set to 0 in the port-up message (we already mention the lable object as a whole should be set to all 0s).
Woj> This would be a good thing for the WG to discuss. There most evidently is a fair amount of "dead wood" in the current spec, ie stuff tr=#0000ff size=2>Peter
From: Sanjay Wadhwa [mailto:swadhwa at juniper.net]
Sent: 30. april 2008 14:42
To: Peter Arberg; Tina TSOU; Maglione Roberta; Wojciech Dec (wdec)
Cc: ancp at ietf.org
Subject: RE: [ANCP] question regarding Labels in ANCP port up messagesPeter
The ANCP draft as it currently stands is based on RFC3292. It provides extensions and modifications to relevant constructs in RFC3292. There is no mention (implicit or explicit) of expired GSMP drafts in the ANCP draft. In order to implement the ANCP draft, I am not sure why one would look at the expired GSMP drafts. Do you see a reason to do this based on anything that you read in the ANCP draft? Bringing up reference to expired gsmp draft in this thread just adds to the confusion. For GSMPv3 objects in the messages (such as Label Type), one has to look at RFC3292 (this is clearly stated in the ANCP draft - section 2 and I am quoting it below) :ANCP uses a subset of GSMPv3 messages to implement currently defined use-cases. These relevant GSMPv3 messages are identified in section 5. GSMPv3 procedures with suitable extensions, as used by ANCP, are described in sections 5.1, 5.2 and 5.3. GSMPv3 general extensions and GSMPv3 message specific extensions required by ANCP are described in sub-sections of 5.4. In addition to specifying extensions and modifications to relevant GSMP messages applicable to ANCP, this draft also defines the usage of these messages by ANCP, and indicates the values that ANCP should set for relevant fields in these GSMP messages. However, to understand the basic semantics of various fields in GSMP messages, the reader is referred to [4]. => RFC 3292.
What existing implementations currently do is an important but separate issue. These implementations for most part precede the current ANCP draft. It is fine to poll where these implementations diverge from the current draft. It is then upto the implementations (including the one that I am somewhat familiar with) to work towards compliance with the draft.On the following points from Woj:
Woj>2) The current version of the spec is not accurate, and does not reflect the fact that the known implementations follow the label field definition from draft-gsmpv3-base-spec.
It is not for the protocol draft to point out what current implementations do. The best we can do is to further clarify in the draft that type and value fields of the Label object (defined in RFC3292) should be set to 0 in the port-up message (we already mention the lable object as a whole should be set to all 0s).
Woj> This would be a good thing for the WG to discuss. There most evidently is a fair amount of "dead wood" in the current spec, iehat nobody yet implements or cares about. In the former case, we could re-cast that material using the new notions/extensions, in the latter case simply chop it out.
I agree. We are based on GSMPv3 (RFC3292) messages, and obviously not everything in these messages is leveraged by ANCP. However, the sync rate and OAM uses-cases are implemented and in use (ideally we should leave these alone...i.e. no change beyond adding more clarity if needed). For anything new (such as multicast) we are defining new messages (no legacy).
-Sanjay
>-----Original Message-----
>From: Peter Arberg [mailto:parberg at redback.com]
>Sent: Wednesday, April 30, 2008 3:56 PM
>To: Tina TSOU; Maglione Roberta; Sanjay Wadhwa; Wojciech Dec (wdec)
>Cc: ancp at ietf.org
>Subject: RE: [ANCP] question regarding Labels in ANCP port up messages
>
>
>Hi,
>
>some times I think it is amazing we ever got interoperability
>of ANCP :-)
>because looking at the label discussion is a very good example that the
>whole GSMP - ANCP reference have not worked very well.
>
>In the ANCP draft, section 5.4.2 the event message is shown like this:
>
>0 1 2 3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Vers | Sub | Message Type | Result| Code |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Partition ID | Transaction Identifier |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|I| SubMessage Number | Length |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Port |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Port Session Number |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Event Sequence Number &nbs stuff that nobody yet implements or cares about. In the former case, we could re-cast that material using the new notions/extensions, in the latter case simply chop it out.I agree. We are based on GSMPv3 (RFC3292) messages, and obviously not everything in these messages is leveraged by ANCP. However, the sync rate and OAM uses-cases are implemented and in use (ideally we should leave these alone...i.e. no change beyond adding more clarity if needed). For anything new (such as multicast) we are defining new messages (no legacy).
-Sanjay
>-----Original Message-----
>From: Peter Arberg [mailto:parberg at redback.com]
>Sent: Wednesday, April 30, 2008 3:56 PM
>To: Tina TSOU; Maglione Roberta; Sanjay Wadhwa; Wojciech Dec (wdec)
>Cc: ancp at ietf.org
>Subject: RE: [ANCP] question regarding Labels in ANCP port up messages
>
>
>Hi,
>
>some times I think it is amazing we ever got interoperability
>of ANCP :-)
>because looking at the label discussion is a very good example that the
>whole GSMP - ANCP reference have not worked very well.
>
>In the ANCP draft, section 5.4.2 the event message is shown like this:
>
>0 1 2 3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Vers | Sub | Message Type | Result| Code |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Partition ID | Transaction Identifier |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|I| SubMessage Number | Length |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Port |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Port Session Number |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Event Sequence Number |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|x|S|x|x| |
>+-+-+-+-+ Label |
>~ ~
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| |
>~ Extension Value ~
>| |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>This is the exact same event message defined in
>draft-ietf-gsmp-v3-base-spec-08.txt section 11.
>
>And in this gsmp-draft, section 5.1.3 the label space is defined
>as minimum 8 bytes if the length=0 and as such no value, and this
>is because the gsmp-draft has a new "label adaptaion" field.
>
>
>
>BUT in RFC3292 the event message is show in section 9, like this:
>
>0 1 2 3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Version | Message Type | Result | Code |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Partition ID | Transaction Identifier |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|I| SubMessage Number | Length |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Port |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Port Session Number |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Event Sequence Number |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|x|S|x|x| |
>+-+-+-+-+ Label |
>~ ~
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>So a different Event Message picture/definition than what is shown
>in the ANCP draft, and in RFC3292 section 3.1.3 the label field
>is defined as 4 bytes if length=0 and as such no value.
>
>
>
>So I very much agree with Woj that we need this issue to be resolved,
>and proabably a show of hands what is actually done in different
>implementations, so we can nail down how the event message is
>suppose to look like in ANCP.
>
>
>I know at least 1 implementation which uses 8 bytes for the
>label field.
>
>
>cheers,
>Peter
>
>
>
>
>
>
>________________________________
>
> From: ancp-bounces at ietf.org
>[mailto:ancp-bounces at ietf.org] On Behalf Of Tina TSOU
> Sent: 30. april 2008 00:19
> To: Maglione Roberta; Sanjay Wadhwa; Wojciech Dec (wdec)
> Cc: ancp at ietf.org
> Subject: Re: [ANCP] question regarding Labels in ANCP
>port up messages
>
>
> Hi all,
> It is clear to me that if Label Length is filled as 0,
>there is nothing to be filled into Label Value. The whole
>Label part is 4 bytes, not 8 bytes.
>
> Cheers from the last working day before Labor's Day
>holidays in some countries:)
>
> Tina
>
> ----- Original Message -----
> From: Wojciech Dec (wdec) <mailto:wdec at cisco.com>
> To: Sanjay Wadhwa <mailto:swadhwa at juniper.net>
> ; Maglione Roberta <mailto:roberta.maglione at telecomitalia.it>
> Cc: ancp at ietf.org
> Sent: Wednesday, April 30, 2008 1:12 AM
> Subject: Re: [ANCP] question regarding Labels
>in ANCP port up messages
>
> Sanjay, All,
>
> What is stated below runs counter to at least
>a handful of ANCP
> implementations, all of which are known to be
>interoperable.
> There are really two options:
> 1) The current version of the spec is correct,
>and the known
> interoperable implementations do not follow it
> 2) The current version of the spec is not
>accurate, and does not reflect
> the fact that the known implementations follow
>the label field
> definition from draft-gsmpv3-base-spec.
>
> I would like to ask you, as the lead editor of
>the spec, to work with
> the WG in resolving what the problem is, and
>clearing up what the WG
> spec says about and if 1) holds to be true,
>then proposing an
> interoperability fix.
>
> In either case, the issue highlights the fact
>that there is still
> lingering confusion as to the dependencies
>ANCP has on rfc3292, or
> draft-gsmpv3-base-spec, or both. It seems to
>be in the best interest of
> all to address these.
>
> Regards,
> Woj.
>
> > -----Original Message-----
> > From: Sanjay Wadhwa [mailto:swadhwa at juniper.net]
> > Sent: 29 April 2008 17:29
> > To: Maglione Roberta
> > Cc: Wojciech Dec (wdec); ancp at ietf.org;
>Philippe Champagne (pchamp)
> > Subject: RE: question regarding Labels in
>ANCP port up messages
> >
> > Hi Maglione
> > Yes, the label format is as defined in RFC
>3292. The ANCP draft is
> > based on RFC 3292 and proposes
>extensions/modifications where
> > required.
> > This is clearly stated upfront both in the
>abstract and in
> > section 2. In
> > section 5.4.2, it clearly specifies the
>format of "port up" message
> > (based on RFC 3292), and explicitly states
>the label field
> > should be set
> > to 0. Following is what the draft currently states:
> >
> >
> > 5.4.2 Topology Discovery Extensions
> >
> > The GSMP Event message with PORT UP message
>type (80) is used for
> > conveying DSL line attributes to the NAS.
>The version field should be
> > set to 3, and the sub field should be set to
>1. The I and subMessage
> > fields SHOULD be set to 1 to signify no
>fragmentation. The Port and
> > Label fields should be set to 0.
> >
> > 0 1 2
> 3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
>8 9 0 1 2 3 4 5
> > 6 7 8 9 0 1
> >
> >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Vers | Sub | Message Type |
>Result| Code
> > |
> >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Partition ID |
>Transaction Identifier
> > |
> >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |I| SubMessage Number |
> Length
> > |
> >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Port
> > |
> >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Port Session Number
> > |
> >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Event Sequence Number
> > |
> >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |x|S|x|x|
> > |
> > +-+-+-+-+ Label
> > |
> > ~
> > ~
> >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |x|x|x|x|x|x|x|x| Message Type |
>Tech Type | Block Length
> > |
> >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |
> > |
> > ~ Extension Value
> > ~
> > |
> > |
> >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > When we say the label field should be set to
>0, the intention
> > is for the
> > type and length fields in the label TLV to
>be set to 0. We can
> > explicitly state this for clarity.
> >
> > -Sanjay
> >
> > >-----Original Message-----
> > >From: Maglione Roberta
>[mailto:roberta.maglione at telecomitalia.it]
> > >Sent: Tuesday, April 29, 2008 8:06 AM
> > >To: Sanjay Wadhwa
> > >Cc: Wojciech Dec (wdec); ancp at ietf.org;
>pchamp at cisco.com
> > >Subject: RE: question regarding Labels in
>ANCP port up messages
> > >
> > >
> > >Hi Sanjay and All,
> > > I was reading the current ancp
>protocol draft in order to
> > > understand which should be the correct
>format for the label
> > >field in the ancp port Up message.
> > >Actually as it was already pointed out in
>the alias the draft
> > >in section 5.4.2 says "GSMP Event message
>with PORT UP message
> > >type (80) is used" thus I am assuming that
>the label in the
> > >port UP message should follow the message
>format defined in
> > >RFC 3292, section 3.1.3:
> > >
> > > 0 1
>2 3
> > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
>0 1 2 3 4 5 6 7 8 9 0 1
> > >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |x|S|x|x| Label Type |
> Label Length |
> > >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |
> |
> > > ~ Label Value
> ~
> > > |
> |
> > >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >but from what I have seen different
>implementations use
> > >different format for label field: in
>particular several
> > >implementations use a label format that is
>similar to the one
> > >specified in the expired draft
>draft-ietf-gsmp-v3-base-spec:
> > >
> > > 0 1
> 2 3
> > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
>8 9 0 1 2 3 4 5 6
> > 7 8 9 0 1
> > >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
> Label
> > Type |
> > >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > | Label Adaptation |
> Label
> > Length |
> > >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |
> > |
> > > ~ Label Value
> > ~
> > > |
> > |
> > >
> >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >
> > >Even if ancp does not care about the label
>field, having this
> > >field somehow not clearly specified in the
>current ancp draft
> > >can easily lead to interoperability issues,
>thus I think it
> > >would be very helpful if you and/or the
>other editors can
> > >clarify what should be the correct format
>for the label field
> > >to be used in the ancp Port Up message.
> > >
> > >Thanks and best regards,
> > >Roberta
> > >
> > >________________________________________
> > >From: Philippe Champagne (pchamp) [pchamp at cisco.com]
> > >Sent: Thursday, April 24, 2008 7:14 PM
> > >To: Sanjay Wadhwa
> > >Cc: Maglione Roberta; Wojciech Dec (wdec);
>ancp at ietf.org
> > >Subject: question regarding Labels in ANCP
>port up messages
> > >
> > >Hi Sanjay
> > >
> > >In section 5.4.2 of the draft, we have:
> > >
> > >
> > > 0 1 2
> > 3
> > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>7 8 9 0 1 2 3 4 5 6
> > >7 8 9 0 1
> > >
> >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > | Vers | Sub | Message Type |
>Result| Code
> > > |
> > >
> >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > | Partition ID |
>Transaction Identifier
> > > |
> > >
> >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |I| SubMessage Number |
> Length
> > > |
> > >
> >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > | Port
> > > |
> > >
> >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > | Port Session Number
> > > |
> > >
> >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > | Event Sequence Number
> > > |
> > >
> >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |x|S|x|x|
> > > |
> > > +-+-+-+-+ Label
> > > |
> > > ~
> > > ~
> > >
> >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |x|x|x|x|x|x|x|x| Message Type |
>Tech Type |
> > >Block Length |
> > >
> >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |
> > > |
> > > ~ Extension Value
> > > ~
> > > |
> > > |
> > >
> >
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >Where Label I suppose is taken from the RFC
>3292, section
> > >3.1.3: (well, I'm guessing)
> > >
> > > A summary of TLV labels supported in
>this version of the
> > protocol is
> > > listed below:
> > >
> > > TLV Label Type Section Title
> > > --------- ---- -------------
> > > ATM Label 0x100 ATM TLV Labels
> > > FR Label 0x101 Frame Relay
>TLV Labels
> > > MPLS Gen Label 0x102 MPLS
>Generic TLV Labels
> > > FEC Label 0x103 FEC TLV Labels
> > >
> > > All Labels will be designated as follow:
> > >
> > > 0 1
>2 3
> > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
>0 1 2 3 4 5 6 7 8 9 0 1
> > >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |x|S|x|x| Label Type |
> Label Length |
> > >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |
> |
> > > ~ Label Value
> ~
> > > |
> |
> > >
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > > x: Reserved Flags.
> > > These are generally used by
>specific messages and will be
> > > defined in those messages.
> > >
> > > S: Stacked Label Indicator
> > > Label Stacking is discussed below
>in section 3.1.3.5
> > >
> > > Label Type
> > > A 12-bit field indicating the type
>of label.
> > >
> > > Label Length
> > > A 16-bit field indicating the
>length of the Label
> > Value field
> > > in bytes.
> > >
> > > Label Value
> > > A variable length field that is an
>integer number of 32 bit
> > > words long. The Label Value field
>is interpreted
> > according to
> > > the Label Type as described in the
>following sections.
> > >
> > >
> > >The draft is a bit obscure about this and
>since it doesn't
> > >specify much, it can lead to
>misinterpretation for the unused
> > >part. Moreover, it would appear that
>several implementations
> > >currently use another format for the label
>field. Can you
> > >explain? I mean, how come what's in the
>current draft doesn't
> > >match what's known to be implemented?
> > >
> > >I'm still wondering why we carried over
>pieces from GSMP that
> > >we do not intend to use.
> > >
> > >I would recommend that if we are to keep
>them but not use
> > >them, we should mention precisely how we
>intend not to use
> > >them: that is how many 0 filled bytes this
>is expected to use
> > >
> > >The rfc 3292 doesn't cover the case where
>this field is not used.
> > >
> > >Can you shed some ligths on this?
> > >
> > >Thanks
> > >Regards
> > >Phil
> > >
> > >
> > >
> >
>>--------------------------------------------------------------------
> > >
> > >CONFIDENTIALITY NOTICE
> > >
> > >This message and its attachments are
>addressed solely to the
> > >persons above and may contain confidential
>information. If you
> > >have received the message in error, be
>informed that any use
> > >of the content hereof is prohibited. Please
>return it
> > >immediately to the sender and delete the
>message. Should you
> > >have any questions, please contact us by replying to
> > >webmaster at telecomitalia.it.
> > >
> > > Thank you
> > >
> > >
>www.telecomitalia.it
> > >
> >
>>--------------------------------------------------------------------
> > >
> > >
> >
> _______________________________________________
> ANCP mailing list
> ANCP at ietf.org
> https://www.ietf.org/mailman/listinfo/ancp
>
>Working Group Name Sanjay Wadhwa Internet Draft Juniper Networks Expires: September 28, 2006 Jerome Moisand Juniper Networks Swami Subramanian Juniper Networks Thomas Haag T-Systems Norbert Voigt Siemens March 28, 2006 GSMP extensions for layer2 control (L2C) Topology Discovery and Line Configuration draft-wadhwa-gsmp-l2control-configuration-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with section 6 of 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 September 28, 2006. Wadhwa et.al Expires September 3, 2005 [Page 1] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-01 March 2006 Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document describes proposed extensions to the GSMP 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. BRAS). This document focuses on specific use cases, topology discovery and line configuration. It is intended to be complemented by other Internet-drafts focusing on additional use cases. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents Table of Contents 2 1 Specification Requirements 4 2 Introduction 4 3 Broadband Access Aggregation 4 3.1 ATM-based broadband aggregation..........................4 3.2 Ethernet-based broadband aggregation.....................6 4 Layer2 Control Protocol 7 4.1 Overview.................................................7 4.2 Layer2 control for Access Topology Discovery.............8 4.2.1 Goals..............................................8 4.2.2 Message Flow - GSMP mapping........................9 4.3 Layer2 control for Line Configuration...................10 4.3.1 Goals.............................................10 4.3.2 Message Flow - GSMP mapping.......................11 4.4 Layer2 Control for Transactional Multicast..............12 4.5 Layer2 OAM..............................................13 4.5.1 Message Flow - GSMP mapping.......................13 5 GSMP for Layer2 Control Protocol 14 5.1 GSMP/TCP connection establishment.......................14 5.2 GSMP connection keep-alive..............................15 Wadhwa et.al Expires September 28, 2006 [Page 2] Internet-Draft draft-wadhwa-gsmp-l2control-configuration-01 MarjgnÊgnÊgnÊgnÊgnÊgnÊgnÊ_______________________________________________ ANCP mailing list ANCP at ietf.org https://www.ietf.org/mailman/listinfo/ancp
- Follow-Ups:
- Re: [ANCP] question regarding Labels in ANCP port up messages
- From: Sanjay Wadhwa
- Re: [ANCP] question regarding Labels in ANCP port up messages
- From: Fortune HUANG
- References:
- Re: [ANCP] question regarding Labels in ANCP port up messages
- From: Peter Arberg
- Re: [ANCP] question regarding Labels in ANCP port up messages
- From: Sanjay Wadhwa
- Prev by Date: Re: [ANCP] question regarding Labels in ANCP port up messages
- Next by Date: Re: [ANCP] question regarding Labels in ANCP port up messages
- Previous by thread: Re: [ANCP] question regarding Labels in ANCP port up messages
- Next by thread: Re: [ANCP] question regarding Labels in ANCP port up messages
- Index(es):