[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] question regarding Labels in ANCP port up messages
Hi,
some times I think it is amazing we ever got interoperability of ANCP :-)
because looking at the label discussion is a very good example that the
whole GSMP - ANCP reference have not worked very well.
In the ANCP draft, section 5.4.2 the event message is shown like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extension Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the exact same event message defined in
draft-ietf-gsmp-v3-base-spec-08.txt section 11.
And in this gsmp-draft, section 5.1.3 the label space is defined
as minimum 8 bytes if the length=0 and as such no value, and this
is because the gsmp-draft has a new "label adaptaion" field.
BUT in RFC3292 the event message is show in section 9, like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
So a different Event Message picture/definition than what is shown
in the ANCP draft, and in RFC3292 section 3.1.3 the label field
is defined as 4 bytes if length=0 and as such no value.
So I very much agree with Woj that we need this issue to be resolved,
and proabably a show of hands what is actually done in different
implementations, so we can nail down how the event message is
suppose to look like in ANCP.
I know at least 1 implementation which uses 8 bytes for the label field.
cheers,
Peter
________________________________
From: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Tina TSOU
Sent: 30. april 2008 00:19
To: Maglione Roberta; Sanjay Wadhwa; Wojciech Dec (wdec)
Cc: ancp at ietf.org
Subject: Re: [ANCP] question regarding Labels in ANCP port up messages
Hi all,
It is clear to me that if Label Length is filled as 0, there is nothing to be filled into Label Value. The whole Label part is 4 bytes, not 8 bytes.
Cheers from the last working day before Labor's Day holidays in some countries:)
Tina
----- Original Message -----
From: Wojciech Dec (wdec) <mailto:wdec at cisco.com>
To: Sanjay Wadhwa <mailto:swadhwa at juniper.net> ; Maglione Roberta <mailto:roberta.maglione at telecomitalia.it>
Cc: ancp at ietf.org
Sent: Wednesday, April 30, 2008 1:12 AM
Subject: Re: [ANCP] question regarding Labels in ANCP port up messages
Sanjay, All,
What is stated below runs counter to at least a handful of ANCP
implementations, all of which are known to be interoperable.
There are really two options:
1) The current version of the spec is correct, and the known
interoperable implementations do not follow it
2) The current version of the spec is not accurate, and does not reflect
the fact that the known implementations follow the label field
definition from draft-gsmpv3-base-spec.
I would like to ask you, as the lead editor of the spec, to work with
the WG in resolving what the problem is, and clearing up what the WG
spec says about and if 1) holds to be true, then proposing an
interoperability fix.
In either case, the issue highlights the fact that there is still
lingering confusion as to the dependencies ANCP has on rfc3292, or
draft-gsmpv3-base-spec, or both. It seems to be in the best interest of
all to address these.
Regards,
Woj.
> -----Original Message-----
> From: Sanjay Wadhwa [mailto:swadhwa at juniper.net]
> Sent: 29 April 2008 17:29
> To: Maglione Roberta
> Cc: Wojciech Dec (wdec); ancp at ietf.org; Philippe Champagne (pchamp)
> Subject: RE: question regarding Labels in ANCP port up messages
>
> Hi Maglione
> Yes, the label format is as defined in RFC 3292. The ANCP draft is
> based on RFC 3292 and proposes extensions/modifications where
> required.
> This is clearly stated upfront both in the abstract and in
> section 2. In
> section 5.4.2, it clearly specifies the format of "port up" message
> (based on RFC 3292), and explicitly states the label field
> should be set
> to 0. Following is what the draft currently states:
>
>
> 5.4.2 Topology Discovery Extensions
>
> The GSMP Event message with PORT UP message type (80) is used for
> conveying DSL line attributes to the NAS. The version field should be
> set to 3, and the sub field should be set to 1. The I and subMessage
> fields SHOULD be set to 1 to signify no fragmentation. The Port and
> Label fields should be set to 0.
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> 6 7 8 9 0 1
>
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Vers | Sub | Message Type | Result| Code
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Partition ID | Transaction Identifier
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |I| SubMessage Number | Length
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Port
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Port Session Number
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Event Sequence Number
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |x|S|x|x|
> |
> +-+-+-+-+ Label
> |
> ~
> ~
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |
> |
> ~ Extension Value
> ~
> |
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> When we say the label field should be set to 0, the intention
> is for the
> type and length fields in the label TLV to be set to 0. We can
> explicitly state this for clarity.
>
> -Sanjay
>
> >-----Original Message-----
> >From: Maglione Roberta [mailto:roberta.maglione at telecomitalia.it]
> >Sent: Tuesday, April 29, 2008 8:06 AM
> >To: Sanjay Wadhwa
> >Cc: Wojciech Dec (wdec); ancp at ietf.org; pchamp at cisco.com
> >Subject: RE: question regarding Labels in ANCP port up messages
> >
> >
> >Hi Sanjay and All,
> > I was reading the current ancp protocol draft in order to
> > understand which should be the correct format for the label
> >field in the ancp port Up message.
> >Actually as it was already pointed out in the alias the draft
> >in section 5.4.2 says "GSMP Event message with PORT UP message
> >type (80) is used" thus I am assuming that the label in the
> >port UP message should follow the message format defined in
> >RFC 3292, section 3.1.3:
> >
> > 0 1 2 3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |x|S|x|x| Label Type | Label Length |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | |
> > ~ Label Value ~
> > | |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >but from what I have seen different implementations use
> >different format for label field: in particular several
> >implementations use a label format that is similar to the one
> >specified in the expired draft draft-ietf-gsmp-v3-base-spec:
> >
> > 0 1 2 3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
> 7 8 9 0 1
> >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |x|S|x|x|x|x|x|x|x|x|x|x|x|x|x|x| Label
> Type |
> >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Label Adaptation | Label
> Length |
> >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |
> |
> > ~ Label Value
> ~
> > |
> |
> >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >Even if ancp does not care about the label field, having this
> >field somehow not clearly specified in the current ancp draft
> >can easily lead to interoperability issues, thus I think it
> >would be very helpful if you and/or the other editors can
> >clarify what should be the correct format for the label field
> >to be used in the ancp Port Up message.
> >
> >Thanks and best regards,
> >Roberta
> >
> >________________________________________
> >From: Philippe Champagne (pchamp) [pchamp at cisco.com]
> >Sent: Thursday, April 24, 2008 7:14 PM
> >To: Sanjay Wadhwa
> >Cc: Maglione Roberta; Wojciech Dec (wdec); ancp at ietf.org
> >Subject: question regarding Labels in ANCP port up messages
> >
> >Hi Sanjay
> >
> >In section 5.4.2 of the draft, we have:
> >
> >
> > 0 1 2
> 3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
> >7 8 9 0 1
> >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Vers | Sub | Message Type | Result| Code
> > |
> >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Partition ID | Transaction Identifier
> > |
> >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |I| SubMessage Number | Length
> > |
> >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Port
> > |
> >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Port Session Number
> > |
> >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Event Sequence Number
> > |
> >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |x|S|x|x|
> > |
> > +-+-+-+-+ Label
> > |
> > ~
> > ~
> >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |x|x|x|x|x|x|x|x| Message Type | Tech Type |
> >Block Length |
> >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |
> > |
> > ~ Extension Value
> > ~
> > |
> > |
> >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >Where Label I suppose is taken from the RFC 3292, section
> >3.1.3: (well, I'm guessing)
> >
> > A summary of TLV labels supported in this version of the
> protocol is
> > listed below:
> >
> > TLV Label Type Section Title
> > --------- ---- -------------
> > ATM Label 0x100 ATM TLV Labels
> > FR Label 0x101 Frame Relay TLV Labels
> > MPLS Gen Label 0x102 MPLS Generic TLV Labels
> > FEC Label 0x103 FEC TLV Labels
> >
> > All Labels will be designated as follow:
> >
> > 0 1 2 3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |x|S|x|x| Label Type | Label Length |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | |
> > ~ Label Value ~
> > | |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > x: Reserved Flags.
> > These are generally used by specific messages and will be
> > defined in those messages.
> >
> > S: Stacked Label Indicator
> > Label Stacking is discussed below in section 3.1.3.5
> >
> > Label Type
> > A 12-bit field indicating the type of label.
> >
> > Label Length
> > A 16-bit field indicating the length of the Label
> Value field
> > in bytes.
> >
> > Label Value
> > A variable length field that is an integer number of 32 bit
> > words long. The Label Value field is interpreted
> according to
> > the Label Type as described in the following sections.
> >
> >
> >The draft is a bit obscure about this and since it doesn't
> >specify much, it can lead to misinterpretation for the unused
> >part. Moreover, it would appear that several implementations
> >currently use another format for the label field. Can you
> >explain? I mean, how come what's in the current draft doesn't
> >match what's known to be implemented?
> >
> >I'm still wondering why we carried over pieces from GSMP that
> >we do not intend to use.
> >
> >I would recommend that if we are to keep them but not use
> >them, we should mention precisely how we intend not to use
> >them: that is how many 0 filled bytes this is expected to use
> >
> >The rfc 3292 doesn't cover the case where this field is not used.
> >
> >Can you shed some ligths on this?
> >
> >Thanks
> >Regards
> >Phil
> >
> >
> >
> >--------------------------------------------------------------------
> >
> >CONFIDENTIALITY NOTICE
> >
> >This message and its attachments are addressed solely to the
> >persons above and may contain confidential information. If you
> >have received the message in error, be informed that any use
> >of the content hereof is prohibited. Please return it
> >immediately to the sender and delete the message. Should you
> >have any questions, please contact us by replying to
> >webmaster at telecomitalia.it.
> >
> > Thank you
> >
> > www.telecomitalia.it
> >
> >--------------------------------------------------------------------
> >
> >
>
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp