Subject: Re: [ANCP] question regarding Labels in ANCP port up messages

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 4 Jun 2008 13:23:48 +0200

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:[email-masked]] 
> Sent: 09 May 2008 02:15
> To: Wojciech Dec (wdec); Ole Helleberg Andersen; Sanjay 
> Wadhwa; Tina TSOU; Maglione Roberta
> Cc: [email-masked]
> 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:[email-masked]]
>         Sent: 7. maj 2008 14:14
>         To: Ole Helleberg Andersen; Peter Arberg; Sanjay 
> Wadhwa; Tina TSOU; Maglione Roberta
>         Cc: [email-masked]
>         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:[email-masked]]
>                 Sent: 06 May 2008 14:04
>                 To: Peter Arberg; Sanjay Wadhwa; Tina TSOU; 
> Maglione Roberta; Wojciech Dec (wdec)
>                 Cc: [email-masked]
>                 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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Arberg
>                 Sent: 2. maj 2008 20:52
>                 To: Sanjay Wadhwa; Tina TSOU; Maglione 
> Roberta; Wojciech Dec (wdec)
>                 Cc: [email-masked]
>                 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:[email-masked]]
>                         Sent: 2. maj 2008 05:35
>                         To: Peter Arberg; Tina TSOU; Maglione 
> Roberta; Wojciech Dec (wdec)
>                         Cc: [email-masked]
>                         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:[email-masked]]
>                         Sent: Wednesday, April 30, 2008 7:20 PM
>                         To: Sanjay Wadhwa; Tina TSOU; 
> Maglione Roberta; Wojciech Dec (wdec)
>                         Cc: [email-masked]
>                         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:[email-masked]]
>                                 Sent: 30. april 2008 14:42
>                                 To: Peter Arberg; Tina TSOU; 
> Maglione Roberta; Wojciech Dec (wdec)
>                                 Cc: [email-masked]
>                                 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:[email-masked] <mailto:[email-masked]> ]
>                                 >Sent: Wednesday, April 30, 
> 2008 3:56 PM
>                                 >To: Tina TSOU; Maglione 
> Roberta; Sanjay Wadhwa; Wojciech Dec (wdec)
>                                 >Cc: [email-masked]
>                                 >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: [email-masked]
>                                 
> >[mailto:[email-masked] <mailto:[email-masked]> 
> ] On Behalf Of Tina TSOU
>                                 >        Sent: 30. april 2008 00:19
>                                 >        To: Maglione 
> Roberta; Sanjay Wadhwa; Wojciech Dec (wdec)
>                                 >        Cc: [email-masked]
>                                 >        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:[email-masked] <mailto:[email-masked]> >
>                                 >                To: Sanjay 
> Wadhwa <mailto:[email-masked] <mailto:[email-masked]> >
>                                 > ; Maglione Roberta 
> <mailto:[email-masked] 
> <mailto:[email-masked]> >
>                                 >                Cc: [email-masked]
>                                 >                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:[email-masked] 
> <mailto:[email-masked]> ]
>                                 >                > Sent: 29 
> April 2008 17:29
>                                 >                > To: 
> Maglione Roberta
>                                 >                > Cc: 
> Wojciech Dec (wdec); [email-masked];
>                                 >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:[email-masked] 
> <mailto:[email-masked]> ]
>                                 >                > >Sent: 
> Tuesday, April 29, 2008 8:06 AM
>                                 >                > >To: Sanjay Wadhwa
>                                 >                > >Cc: 
> Wojciech Dec (wdec); [email-masked];
>                                 >[email-masked]
>                                 >                > >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) [[email-masked]]
>                                 >                > >Sent: 
> Thursday, April 24, 2008 7:14 PM
>                                 >                > >To: Sanjay Wadhwa
>                                 >                > >Cc: 
> Maglione Roberta; Wojciech Dec (wdec);
>                                 >[email-masked]
>                                 >                > >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
>                                 >                > 
> >[email-masked].
>                                 >                > >
>                                 >                > >        Thank you
>                                 >                > >
>                                 >                > >
>                                 >www.telecomitalia.it
>                                 >                > >
>                                 >                >
>                                 
> >>--------------------------------------------------------------------
>                                 >                > >
>                                 >                > >
>                                 >                >
>                                 >                
> _______________________________________________
>                                 >                ANCP mailing list
>                                 >                [email-masked]
>                                 >                
> https://www.ietf.org/mailman/listinfo/ancp 
> <https://www.ietf.org/mailman/listinfo/ancp>
>                                 >
>                                 >
> 
> 
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp