|
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 -----
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
> TR>> 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|
> |
>
+-+-+-+-+ &nbo: 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|
> |
>
+-+-+-+-+ sp;
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 &nbs;
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 p;
~
> >
|
|
> >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> >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 interope
~
> >
|
|
> >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> >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 interoperabilityrability 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
> > |
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 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
> > |
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> =2
|
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
Type0
|
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 &n 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 fielbsp; 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
>d
>
> 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
|