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

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Thu, 24 Apr 2008 10:14:08 -0700

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

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

---

From: "Maglione Roberta" <[email-masked]>
Date: Tue, 29 Apr 2008 14:06:10 +0200

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

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

         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)

    0                   1                   2                   3

      x: Reserved Flags.

      Label Type

      Label Length

      Label Value

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

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

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

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 29 Apr 2008 11:28:48 -0400

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 

 

 

 

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
>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
>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
>
>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 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
>
>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: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 29 Apr 2008 19:12:19 +0200

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. 

> From: Sanjay Wadhwa [mailto:[email-masked]] 
> Sent: 29 April 2008 17:29
> To: Maglione Roberta
> Cc: Wojciech Dec (wdec); [email-masked]; Philippe Champagne (pchamp)
> >      ~                          Label Value                 
> >         0                   1                   2           
>         3

---

From: Tina TSOU <[email-masked]>
Date: Wed, 30 Apr 2008 15:18:35 +0800

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) 
  To: Sanjay Wadhwa ; Maglione Roberta 
  Cc: [email-masked] 
  Sent: Wednesday, April 30, 2008 1:12 AM
  Subject: Re: [ANCP] question regarding Labels in ANCP port up messages

  Sanjay, All,

  Regards,
  Woj.

---

From: Peter Arberg <[email-masked]>
Date: Wed, 30 Apr 2008 12:55:41 -0700

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

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
|    Version    | Message Type  |    Result     |     Code      |

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,

        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,

                Regards,
                Woj.

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Wed, 30 Apr 2008 17:42:01 -0400

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

>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,
>
>        From: [email-masked]
>[  <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of Tina TSOU
>        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.
>
>                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]]
>                > based on RFC 3292 and proposes
>extensions/modifications where
>                > required.
>                > This is clearly stated upfront both in the
>abstract and in
>                > section 2. In
>                > (based on RFC 3292), and explicitly states
>the label field
>                > should be set
>                >          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
>                >
>                >
>                >
>                > When we say the label field should be set to
>0, the intention
>                > is for the
>                > >From: Maglione Roberta
>[  <mailto:[email-masked]>
mailto:[email-masked]]
>                > >    0                   1                  
>2                   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|x|x|x|x|x|x|x|x|x|x|x|x|    
>       Label
>                > Type         |
>                > >
>                >
>                > >      |    Label Adaptation           |    
>     Label
>                > Length         |
>                > >         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|x|x|x|x|x|x|x| Message Type  |  
>Tech Type   |
>                > >Block Length  |
>                > >
>                >
>                > >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:
>                > >
>                > >    0                   1                  
>2                   3
>                > >         A 16-bit field indicating the
>length of the Label
>                > Value field
>                > >         in bytes.
>                > >
>                > >      Label Value
>                > >         words long.  The Label Value field
>is interpreted
>                > according to
>                > >I'm still wondering why we carried over
>pieces from GSMP that
>                > >we do not intend to use.
>                > >
>                 <https://www.ietf.org/mailman/listinfo/ancp>

---

From: Peter Arberg <[email-masked]>
Date: Wed, 30 Apr 2008 16:20:02 -0700

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.

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]] On Behalf Of Tina TSOU
>                To: Sanjay Wadhwa <mailto:[email-masked]>
> ; Maglione Roberta <mailto:[email-masked]>
>                Cc: [email-masked]
>Tech Type   | Block Length
>[mailto:[email-masked]]