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:parberg at redback.com]
Sent: Wednesday, April 30, 2008
7:20 PM
To: Sanjay Wadhwa; Tina TSOU;
Maglione Roberta; Wojciech Dec (wdec)
Cc: ancp at ietf.org
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:swadhwa at juniper.net]
Sent: 30. april 2008 14:42
To: Peter Arberg; Tina TSOU;
Maglione Roberta; Wojciech Dec (wdec)
Cc: ancp at ietf.org
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:parberg at redback.com]
>Sent: Wednesday, April 30, 2008 3:56 PM
>To: Tina TSOU; Maglione Roberta; Sanjay Wadhwa; Wojciech Dec (wdec)
>Cc: ancp at ietf.org
>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: 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
>
>