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

From: Fortune HUANG <[email-masked]>
Date: Thu, 01 May 2008 18:33:25 +0800

Peter,

I think ANCP and GSMP are independent with each other, and they can be developed parallelly.
RFC3292 is the only legal baseline version of GSMP which makes sense to ANCP, because ANCP
uses the contents of RFC3292 as a starting point.
However, after started, ANCP is developed independently with the development of GSMP. 
And the later versions of GSMP have nothing to do with ANCP.

Therefore, I think draft-ietf-gsmp-v3-base-spec-08 has nothing to do with ANCP because it
is not a legal starting point of ANCP.

Furthermore, I think it is the responsibility of the newer draft to keep compatible with the older one.
Since the draft-ietf-gsmp-v3-base-spec-08 is newer than RFC3292, I think we should make 
draft-ietf-gsmp-v3-base-spec-08 compatible with RFC3292, and accordingly the implementation
could be backward compatible.

cheers,
Fortune
  ----- Original Message ----- 
  From: Peter Arberg 
  To: Sanjay Wadhwa ; Tina TSOU ; Maglione Roberta ; Wojciech Dec (wdec) 
  Cc: [email-masked] 
  Sent: Thursday, May 01, 2008 7:20 AM
  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]]
    >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]] 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]>
    >                To: Sanjay Wadhwa <mailto:[email-masked]>
    > ; Maglione Roberta <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]]
    >                > 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]]
    >                > >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
    >
    > 

------------------------------------------------------------------------------

  _______________________________________________
  ANCP mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Peter Arberg <[email-masked]>
Date: Thu, 1 May 2008 08:56:52 -0700

Hi,

As pointed out by both Philipe & Maglione in earlier emails we have a situation where
some ANCP implementations running in production networks today, do not use the
event message = label field, as it is currently defined in the draft.

I simply gave some historic input to why this is, and I support Woj when he suggest
that the editors try and work a proposal how to solve this issue.

I think a good starting point is a show of hands to what is implemented, so we can see
if it is easier to change the specs or the running code.

But I do not think we can get away from having to look at changing the version number as
a minimum, no matter what direction we go.

As a show of hans, I have so far seen Tina say the label space is 4 bytes, and I said it
is 8 bytes in the implementation I know of..  So at the moment the score is 1 - 1 :-)

cheers,
Peter

________________________________
From: Fortune HUANG [mailto:[email-masked]]
Sent: 1. maj 2008 03:33
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

Peter,

cheers,
Fortune
----- Original Message -----
From: Peter Arberg<mailto:[email-masked]>
To: Sanjay Wadhwa<mailto:[email-masked]> ; Tina TSOU<mailto:[email-masked]> ; Maglione Roberta<mailto:[email-masked]> ; Wojciech Dec (wdec)<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Sent: Thursday, May 01, 2008 7:20 AM
Subject: Re: [ANCP] question regarding Labels in ANCP port up messages

Sanjay,

cheers,
Peter

Peter

-Sanjay

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Fri, 2 May 2008 08:35:22 -0400

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,

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

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

I think a very good question is brought up here, and that is what is
implemented and

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

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. 

	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
	
	>From: Peter Arberg [mailto:[email-masked]
<mailto:[email-masked]> ]

	
	
|
	
|
	
|
	
|
|
~

|
~
|

	

|
	
|
	
|
	
|
|
~
	
	>[mailto:[email-masked] <mailto:[email-masked]> ]
On Behalf Of Tina TSOU
	>                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]> >
	>                > From: Sanjay Wadhwa
[mailto:[email-masked] <mailto:[email-masked]> ]

	

	>                >         |                      Port Session
Number
	
	>                >         |                     Event Sequence
Number

	
	>                >         ~                         Extension
Value
	
	>[mailto:[email-masked]
<mailto:[email-masked]> ]

	

	
	
	>                > >In section 5.4.2 of the draft, we have:
2

	

	>                > >        |                      Port Session
Number
	
	>                > >        |                     Event Sequence
Number

	
	>                > >        ~                         Extension
Value

	

	
<https://www.ietf.org/mailman/listinfo/ancp>

---

From: Peter Arberg <[email-masked]>
Date: Fri, 2 May 2008 11:52:27 -0700

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

Sent: 2. maj 2008 05:35

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

Sanjay,

cheers,
Peter

Peter

-Sanjay

---

From: Peter Arberg <[email-masked]>
Date: Sat, 3 May 2008 12:38:43 -0700

Hi Fortune,

I don't think you get my point, that ANCP was started and implemented in live
networks before it turned into an ANCP WG draft.

My only point is we have to find a way to make sure these ANCP implementations
are compatible with new WG ANCP implementations, as it seems pretty stupid to
make a standards draft which is in conflict with running code, without specifying a
way to avoid interoperability problems in networks.

I really don't think there is a matter of right or wrong in this discussion, it is a matter
of problems arising when a draft is evolving without people paying attention to
backwards compatibility.

As a working group it is our responsibility to make sure what we define will live together
in networks with already implemented versions of the protocol, without causing major
headaches for carriers using the protocol.

cheers,
Peter

Sent: 3. maj 2008 05:34

Peter,

Since ANCP draft has already based the event-message of RFC3292, I don't think it appropriate
to define the message bit by bit again.

In some implementations the label space is 4 while in others it is 8.
However, it is obvious that 4 is correct according to the current ANCP draft.
8 is the result that does not obey the ANCP draft strictly because of maybe carelessness in implementation.
I don't know why we need a show of hands, because we can already tell right from wrong through simple analysis.

Furthermore, it is very strange to change the ANCP draft just because some implementations implemented it incorrectly.

Best Regards,
Fortune
----- Original Message -----
From: Peter Arberg<mailto:[email-masked]>
To: Sanjay Wadhwa<mailto:[email-masked]> ; Tina TSOU<mailto:[email-masked]> ; Maglione Roberta<mailto:[email-masked]> ; Wojciech Dec (wdec)<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Sent: Saturday, May 03, 2008 2:52 AM
Subject: Re: [ANCP] question regarding Labels in ANCP port up messages

Hi Sanjay,

cheers,
Peter

Peter

Cheers
-Sanjay

Sanjay,

cheers,
Peter

Peter

-Sanjay

---

From: "Ole Helleberg Andersen" <[email-masked]>
Date: Tue, 6 May 2008 14:03:53 +0200

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

	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). 

	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,

	of the ANCP working implementations are based on, in case you do
not have this old

	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

	I think a very good question is brought up here, and that is
what is implemented and

	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

	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

	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. 

		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.

		-Sanjay
		
3

	
	
|
	
|
	
|
	
|
|
~

|
~
|
	
3

	
	
|
	
|
	
|
	
|
|
~
	
		>[mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Tina TSOU
		>        Subject: Re: [ANCP] question regarding Labels
in ANCP
		>                To: Sanjay Wadhwa
<mailto:[email-masked] <mailto:[email-masked]> >
		> ; Maglione Roberta
<mailto:[email-masked]
<mailto:[email-masked]> >
2  

	
		>                >         |I|      SubMessage Number
|   
	
Port
	
Session Number
	
		>                >         |                     Event
Sequence Number
	
		>                >         +-+-+-+-+
Label

Extension Value

	

		>                > >   ~                          Label
Value  

	
	
		>                > >      |    Label Adaptation
|    
	
Label Value
	
2

	
		>                > >        |I|      SubMessage Number
|  
	
Port
	
Session Number
	
		>                > >        |                     Event
Sequence Number
	
		>                > >        +-+-+-+-+
Label

Extension Value

	

		>                > >   ~                          Label
Value

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 7 May 2008 14:13:57 +0200

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.html .
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 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

		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

		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

		I think a very good question is brought up here, and
that is what is implemented and

		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

		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

		implementation there is bound to be interoperability
issues with existing implementations

		runnig.

		cheers,

		Peter

			 

			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.

			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
			
3

	
Length              |
	
|
	
|
	
|
	
|
|
~

|
~
|
	
3

	
Length              |
	
|
	
|
	
|
	
|
|
~
	
2  

	
			>                >         |I|      SubMessage
Number      |   
	
Port
	
Port Session Number
	
Event Sequence Number
	
Label

Extension Value

2 3 4 5 6 7 8 9
	
			>                > >   |x|S|x|x|       Label
Type      |       

Label Value  

	
	
|    
	
Label Value
	
			>                > >         0
1                   2

	
			>                > >        |I|      SubMessage
Number      |  
	
Port
	
Port Session Number
	
Event Sequence Number
	
Label

Extension Value
	
			>                > >      MPLS Gen Label 0x102
MPLS

2 3 4 5 6 7 8 9
	
			>                > >   |x|S|x|x|       Label
Type      |       

Label Value

---

From: Peter Arberg <[email-masked]>
Date: Thu, 8 May 2008 17:15:23 -0700

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

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.html . 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,

                cheers,
                Peter

                        Peter

                        Cheers

                        -Sanjay

                        Sanjay,

                        runnig.

                        cheers,

                        Peter

                                Peter

                                -Sanjay

                                >From: Peter Arberg [mailto:[email-masked] <mailto:[email-masked]> ]
                                >[mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Tina TSOU
                                >                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]
                                >                > From: Sanjay Wadhwa [mailto:[email-masked] <mailto:[email-masked]> ]
                                >[mailto:[email-masked] <mailto:[email-masked]> ]
                                >                https://www.ietf.org/mailman/listinfo/ancp <https://www.ietf.org/mailman/listinfo/ancp>
                                >
                                >

---

From: "Maglione Roberta" <[email-masked]>
Date: Fri, 9 May 2008 12:38:17 +0200

Hi Tina,
   you said that you support Peter's proposal on changing the unused field  from "label" to "reserved" , but you did not comment on the length of this field.
If my understanding is correct, Peter is also proposing to have a "reserved" field of 8 bytes:
"Label field is 8 bytes, should be set to 0 on transmit and ignored on receive."

what's your opinion on that?

Regards,
Roberta
________________________________
From: Tina TSOU [mailto:[email-masked]]
Sent: Friday, May 09, 2008 4:02 AM
To: Maglione Roberta; Sanjay Wadhwa; Ole Helleberg Andersen; Wojciech Dec (wdec); Peter Arberg
Cc: [email-masked]
Subject: Re: [ANCP] question regarding Labels in ANCP port up messages

Dear Peter et al,
Comment in line.

B. R.
Tina
Messengers:
MSN: [email-masked]<mailto:[email-masked]>   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: [email-masked]<mailto:[email-masked]>    Google talk: [email-masked]<mailto:[email-masked]>
----- Original Message -----
From: Peter Arberg<mailto:[email-masked]>
To: Wojciech Dec (wdec)<mailto:[email-masked]> ; Ole Helleberg Andersen<mailto:[email-masked]> ; Sanjay Wadhwa<mailto:[email-masked]> ; Tina TSOU<mailto:[email-masked]> ; Maglione Roberta<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Sent: Friday, May 09, 2008 8:15 AM
Subject: RE: [ANCP] question regarding Labels in ANCP port up messages

Hi Woj,

0                   1                   2                   3

Result ...

Code ...

Partition ID ...

....

....

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.
[Tina: I really support Peter at this point.]

cheers,
Peter

cheers,
Peter

        Hi All,

        Regards,
        Woj.

                Hi All,

                Cheers,
                Ole

                From: [email-masked]<mailto:[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]<mailto:[email-masked]>
                Subject: Re: [ANCP] question regarding Labels in ANCP port up messages

                Hi Sanjay,

                cheers,
                Peter

                        Peter

                        Cheers

                        -Sanjay

                        Sanjay,

                        runnig.

                        cheers,

                        Peter

                                Peter

                                -Sanjay

                                >        From: [email-masked]<mailto:[email-masked]>
                                >                > Cc: Wojciech Dec (wdec); [email-masked]<mailto:[email-masked]>;
                                >                > >Cc: Wojciech Dec (wdec); [email-masked]<mailto:[email-masked]>;
                                >[email-masked]
                                >                [email-masked]<mailto:[email-masked]>

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

---

From: Tina TSOU <[email-masked]>
Date: Fri, 09 May 2008 10:01:32 +0800

Dear Peter et al,
Comment in line.

B. R.
Tina
Messengers: 
MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: [email-masked]    Google talk: [email-masked]
  ----- Original Message ----- 
  From: Peter Arberg 
  To: Wojciech Dec (wdec) ; Ole Helleberg Andersen ; Sanjay Wadhwa ; Tina TSOU ; Maglione Roberta 
  Cc: [email-masked] 
  Sent: Friday, May 09, 2008 8:15 AM
  Subject: RE: [ANCP] question regarding Labels in ANCP port up messages

  Hi Woj,

  0                   1                   2                   3

  Result ...

  Code ...

  Partition ID ...

  ....

  ....

  cheers,
  Peter

  cheers,
  Peter

          Hi All,

          Regards,
          Woj.

                  Hi All,

                  Cheers,
                  Ole

                  Hi Sanjay,

                  cheers,
                  Peter

                          Peter

                          Cheers

                          -Sanjay

                          Sanjay,

                          runnig.

                          cheers,

                          Peter

                                  Peter

                                  -Sanjay