[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] question regarding Labels in ANCP port up messages
Hi All,
Unless there are some last minute counter proposals, or comments,
Peter's proposal below regarding the Label field should be considered as
accepted by the WG.
Regards,
Woj.
> -----Original Message-----
> From: Peter Arberg [mailto:parberg at redback.com]
> Sent: 09 May 2008 02:15
> To: Wojciech Dec (wdec); Ole Helleberg Andersen; Sanjay
> Wadhwa; Tina TSOU; Maglione Roberta
> Cc: ancp at ietf.org
> Subject: RE: [ANCP] question regarding Labels in ANCP port up messages
>
> Hi Woj,
>
> I think your proposal goes hand in hand with my suggestion to
> document the
> event message bit by bit instead of reference the RFC3292 or
> an expired old
> gsmp-draft.
>
> I will suggest we in the ANCP draft do a description in section
> 5.4.2 something in these lines:
>
> The ANCP Event message with PORT UP message type (80) is used for
> conveying DSL line attributes to the NAS, and is defined as follows:
>
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Vers | Sub | Message Type | Result| Code |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Partition ID | Transaction Identifier |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |I| SubMessage Number | Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Port |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Port Session Number |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Event Sequence Number |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |x|S|x|x| |
> +-+-+-+-+ Label |
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> ~ Extension Value ~
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> Version field is 1 byte, 4 bits for the major version and 4
> bits for the sub-version, should be set to 3, and the sub field
> should be set to 1.
>
> Message Type is 1 byte, and can have the following values:
> ...
>
> Result ...
>
> Code ...
>
> Partition ID ...
>
> ....
>
>
> Label field is 8 bytes, should be set to 0 on transmit and
> ignored on receive.
>
> ....
>
> So the idea is to document every single field in the event message,
> and list what is the expected transmit value, and what should the
> receiver do with the field.
>
>
> I will actually suggest we remove the "label" name and just call the
> unused field "reserved" and must be set to 0 on transmit and
> ignored on
> receive.
>
> If we simply call them "reserved" we always have the option
> to reuse them
> in alater contribution / new version if theer ever should be a need to
> use some bits in the event message header.
>
>
> Also as another comment, I still think it will be beneficial if we
> describe that the version number check should be per adjacency, so
> we in the future can do a version change easy and allow the ANCP
> implementation to have multiple adjacency with different
> versions of the
> protocol, if we ever see a reason to increase the version number it
> will give a much easier upgrade scenario.
>
> cheers,
> Peter
>
>
> cheers,
> Peter
>
>
>
>
> ________________________________
>
> From: Wojciech Dec (wdec) [mailto:wdec at cisco.com]
> Sent: 7. maj 2008 14:14
> To: Ole Helleberg Andersen; Peter Arberg; Sanjay
> Wadhwa; Tina TSOU; Maglione Roberta
> Cc: ancp at ietf.org
> Subject: RE: [ANCP] question regarding Labels in ANCP
> port up messages
>
>
> Hi All,
>
> it's with a certain amount of incredulity that I view
> the proposals on this thread for changing the version number
> of the protocol. Were such proposals to be accepted, by
> definition it would make most likely the ANCP draft
> incompatible with *all* current implementations, or at the
> very least introduce a compatibility mess in existing
> deployments short of a flag day change over, not to mention
> the issue of depreciating the old version.
> There really seems to be no reason to go through with
> a version change due to what may be attributed as a day 1
> draft problem but *not* a day 1 implementation problem. Also,
> it is not the first time that the protocol spec draft has had
> some inaccuracies, and we've visited this aspect previously
> resulting in the following versioning strategy being laid
> out:
> http://www.ietf.org/mail-archive/web/ancp/current/msg00152.htm
l . While the strategy states that an ANCP version change will > not be
considered due to "incompatibilities arising from
> implementations of pre-RFC drafts", neither does it state
> that the draft cannot change to reflect current
> implementations while keeping the version.
>
> Now, given that there seems to be some uneasiness
> (but thankfully not absolute) in the WG to come forward
> publicly with details of what is currently implemented, I
> have conducted a behind the scenes investigation of sorts,
> and present the summarized findings below:
> - There are 10 distinct implementations of ANCP
> - Out of these 9 either directly implement the label
> field format in as per section 5.3 of
> draft-gsmpv3-base-spec-08, or each is known to be compatible
> with at least 2 implementations that do so. By association,
> it seems reasonable to claim that all of these ANCP
> implementations use the draft-gsmpv3-base-spec-08 format.
> Also, all use version 3.1 as the protocol version, and the
> base protocol header also as per draft-gsmpv3-base-spec-08
> - One implementation is known to use the
> draft-ietf-ancp-protocol-02 format of the label field format,
> ie the rfc3292 format. This implementation is not known to be
> compatible with any of the others.
>
> Based on this, but not only, the obvious answer to
> the problem is *not* to do a version change, but rather fix
> the draft. Granted, this is a far from ideal situation for
> the one implementation affected, and it's a true shame that
> the problem wasn't spotted earlier. Like Peter I also wonder
> how any interop was achieved, but the fact that it is there
> is a significant one that should not be undone by hasty
> version changes. As such option 2 below is not one we'll be
> taking forward. Option 1 however also comes short as it does
> not quite follow the logic of simply documenting what is
> known to be interoperable in the WG draft. If specific
> implementations choose to realize knobs or other, fine, but
> this is not part of the protocol spec, and there is no such
> thing as "old label format". Please do consider the third
> option, ie fixing the draft to reflect what is already done.
>
> This fact in general highlights the problems we're
> having in carrying with the GSMPv3 (rfc3292) legacy,
> alongside adopted amendments from draft-gsmpv3-base-spec
> (this Label issue not being the only adopted item), alongside
> new protocol work. I trust that all of you agree that getting
> maximum clarity on all the legacy issues and dependencies in
> the protocol spec is in the WG's best interest, and that we
> are still some way off from that. As such I also expect the
> WG to support moves/proposals aimed at getting that clarity,
> with resolving this issue being not the first and not the
> last such move.
>
> Regards,
> Woj.
>
>
>
>
>
> ________________________________
>
> From: Ole Helleberg Andersen
> [mailto:ole.helleberg.andersen at ericsson.com]
> Sent: 06 May 2008 14:04
> To: Peter Arberg; Sanjay Wadhwa; Tina TSOU;
> Maglione Roberta; Wojciech Dec (wdec)
> Cc: ancp at ietf.org
> Subject: RE: [ANCP] question regarding Labels
> in ANCP port up messages
>
>
> Hi All,
>
> I think the main issue is to
> ensure interoperability with existing implementations, and to
> allow for upgrading nodes that are already in service to a
> WG-draft compliant version. To do that in a manageable way we
> must allow for version negotiation per adjacency. We
> therefore need to change the WG-draft as suggested by Sanjay
> in his option 2.
>
> Concerning the encoding issue I prefer to
> make the WG-draft in line with existing implementations.
> However, if the WG decides to change it, differences in this
> encoding would also be solved by choosing Sanjay's option 2.
>
> Cheers,
> Ole
>
> ________________________________
>
> From: ancp-bounces at ietf.org
> [mailto:ancp-bounces at ietf.org] On Behalf Of Peter Arberg
> Sent: 2. maj 2008 20:52
> To: Sanjay Wadhwa; Tina TSOU; Maglione
> Roberta; Wojciech Dec (wdec)
> Cc: ancp at ietf.org
> Subject: Re: [ANCP] question regarding Labels
> in ANCP port up messages
>
>
> Hi Sanjay,
>
> yes apparently I missed your point in the
> last email, but I'm glad we agree something is needed
> to make existing ANCP implementations and the
> current draft to co-exist.
>
> I do not like your option 1) as if you need a
> config knob for interoperability, it is too easy to
> get into trouble.
>
> I think option 2) is the best way forward
> with the differences already identified, or we can
> continue to get a show of hands of ANCP
> implementations, and see if anyone is actually
> deployed based on the WG-draft.
>
> There is no beneficial reasons to base the
> event-message of RFC3292, it could as well be a message
> described bit by bit in the ANCP draft, and
> then we can keep the label space at 8 as many
> implementations alreday do.
>
> cheers,
> Peter
>
>
>
>
>
> ________________________________
>
> From: Sanjay Wadhwa
> [mailto:swadhwa at juniper.net]
> Sent: 2. maj 2008 05:35
> 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 messages
>
>
>
> Peter
>
> You missed my point below. The ANCP
> draft since becoming a WG draft does NOT refer to the old
> GSMP drafts. Any implementations based on this WG-draft are
> expected to be interoperable. You are pointing to
> pre-WG-draft versions of ANCP, and these were indeed based on
> expired GSMP drafts that evolved past RFC3292.
>
> There is incompatibility between the
> current ANCP WG-draft and previous non-WG versions (TLV
> clash, label format..). As mentioned earlier it is prudent
> for older implementations to start supporting the WG-draft
> version as soon as possible.
>
>
>
> For interoperability of WG-draft with
> the older pre-WG versions, I see the following options:
>
>
>
> 1. Versioning starts with the
> WG-draft i.e. WG-draft is version = 3, sub-version = 1. For
> any interop issues between older non-WG versions and the
> WG-draft, one needs to look at solving it within
> implementations (e.g. an AN that implements the WG-draft,
> could based on a configuration knob, generate a PORT-UP
> message with old label format the will be accepted by BNG
> implementing pre-WG versions of the draft).
>
>
>
> 2. Change the WG-draft (current
> draft) to use version = 3 and sub-version = 2. This is
> assuming there is no deployed implementation of current
> WG-draft that already uses 3.1 as the version, and also
> assuming the old pre-WG implementations use 3.1. There will
> be no backwards compatibility i.e. version 3.1 BNG will not
> work with version 3.2 AN (we will need to list this as caveat
> in the appendix section). AN and BNG will need to negotiate
> the same version in order for ANCP adjacency to come up. A
> BNG supporting both versions 3.1 and 3.2 could simultaneously
> become adjacent with one AN supporting 3.1 and another AN
> supporting 3.2. (i.e. version compatibility is per adjacency).
>
> Also, major version number change
> (e.g. from 3 to 4) should only correspond to a major change
> in the protocol (e.g. different mechanism, different transport etc).
>
>
>
> My vote would be to adopt option 2
> above only if further changes to WG-draft happen that render
> it incompatible with the current WG-draft. Any
> interoperability issues with pre-WG versions could be handled
> via option 1.
>
>
>
> Cheers
>
> -Sanjay
>
>
>
> ________________________________
>
> From: Peter
> Arberg [mailto:parberg at redback.com]
> Sent: Wednesday, April 30, 2008 7:20 PM
> To: Sanjay Wadhwa; Tina TSOU;
> Maglione Roberta; Wojciech Dec (wdec)
> Cc: ancp at ietf.org
> Subject: RE: [ANCP] question
> regarding Labels in ANCP port up messages
>
>
>
> Sanjay,
>
>
>
> What do you mean "why I reference an
> old draft" ????????????
>
>
>
> I'm surprised you even ask... please
> take a look at YOUR own internet-draft that most
>
> of the ANCP working implementations
> are based on, in case you do not have this old
>
> internet-draft, I have attached it to
> the document.
>
>
>
> If you look at the reference for this
> ancp-draft, you will see that in the reference section
>
> you point to this old gsmp-draft...
> Yes and I know this has been changed in the later
>
> versions of the ANCP draft, but that
> do not change the fact that many of the implementations
>
> today was developed when the attached
> draft was current.
>
>
>
> I think a very good question is
> brought up here, and that is what is implemented and
>
> running in networks today ?
>
>
>
> My take on this is that when the
> reference was change from the old gsmp-draft to the older
>
> RFC3292, apparently no one paid any
> attention to the fact the label definition in the event
>
> message was different and not compatible.
>
>
>
> What current implementations do today
> is an important factor in this discussion, and I think
>
> it is time to come to realization
> that we might need a new version number for ANCP since
>
> it continues to look like there is
> big holes open for interpretation. So if I did a ANCP
>
> implementation there is bound to be
> interoperability issues with existing implementations
>
> runnig.
>
>
>
> cheers,
>
> Peter
>
>
>
>
>
>
>
>
>
> ________________________________
>
>
> From: Sanjay Wadhwa [mailto:swadhwa 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 messages
>
> Peter
> The ANCP draft as it
> currently stands is based on RFC3292. It provides extensions
> and modifications to relevant constructs in RFC3292. There is
> no mention (implicit or explicit) of expired GSMP drafts in
> the ANCP draft. In order to implement the ANCP draft, I am
> not sure why one would look at the expired GSMP drafts. Do
> you see a reason to do this based on anything that you read
> in the ANCP draft? Bringing up reference to expired gsmp
> draft in this thread just adds to the confusion. For GSMPv3
> objects in the messages (such as Label Type), one has to look
> at RFC3292 (this is clearly stated in the ANCP draft -
> section 2 and I am quoting it below) :
>
> ANCP uses a subset of GSMPv3
> messages to implement currently defined use-cases. These
> relevant GSMPv3 messages are identified in section 5. GSMPv3
> procedures with suitable extensions, as used by ANCP, are
> described in sections 5.1, 5.2 and 5.3. GSMPv3 general
> extensions and GSMPv3 message specific extensions required by
> ANCP are described in sub-sections of 5.4. In addition to
> specifying extensions and modifications to relevant GSMP
> messages applicable to ANCP, this draft also defines the
> usage of these messages by ANCP, and indicates the values
> that ANCP should set for relevant fields in these GSMP
> messages. However, to understand the basic semantics of
> various fields in GSMP messages, the reader is referred to
> [4]. => RFC 3292.
>
> What existing implementations
> currently do is an important but separate issue. These
> implementations for most part precede the current ANCP draft.
> It is fine to poll where these implementations diverge from
> the current draft. It is then upto the implementations
> (including the one that I am somewhat familiar with) to work
> towards compliance with the draft.
>
> On the following points from Woj:
>
> Woj>2) The current version of
> the spec is not accurate, and does not reflect the fact that
> the known implementations follow the label field definition
> from draft-gsmpv3-base-spec.
>
> It is not for the protocol
> draft to point out what current implementations do. The best
> we can do is to further clarify in the draft that type and
> value fields of the Label object (defined in RFC3292) should
> be set to 0 in the port-up message (we already mention the
> lable object as a whole should be set to all 0s).
>
> Woj> This would be a good
> thing for the WG to discuss. There most evidently is a fair
> amount of "dead wood" in the current spec, ie stuff that
> nobody yet implements or cares about. In the former case, we
> could re-cast that material using the new notions/extensions,
> in the latter case simply chop it out.
>
> I agree. We are based on
> GSMPv3 (RFC3292) messages, and obviously not everything in
> these messages is leveraged by ANCP. However, the sync rate
> and OAM uses-cases are implemented and in use (ideally we
> should leave these alone...i.e. no change beyond adding more
> clarity if needed). For anything new (such as multicast) we
> are defining new messages (no legacy).
>
> -Sanjay
>
> >-----Original Message-----
> >From: Peter Arberg
> [mailto:parberg at redback.com <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 <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 <mailto:wdec at cisco.com> >
> > To: Sanjay
> Wadhwa <mailto:swadhwa at juniper.net <mailto:swadhwa at juniper.net> >
> > ; Maglione Roberta
> <mailto:roberta.maglione at telecomitalia.it
> <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
> <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
> <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
> <https://www.ietf.org/mailman/listinfo/ancp>
> >
> >
>
>
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp