Peter
The ANCP draft as it currently stands is
based o 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 n 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 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 | &nbthink 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 | Techsp; 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
|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| 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
|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| &n
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: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]
> &nbomitalia.it">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]
> sp;
> 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
> 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
Numbenbsp;
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
>r
>
>
|
>
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
|
Event Sequence
Number
>
>
|
>
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
|x|S|x|x|
>
>
|
>
>
+-+-+-+-+
Label
>
>
|
>
>
~
>
>
~
>
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |x|x|x|x|x|x|x|x|
Message Type |
>Tech Type | Block
Length
>
>
|
>
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
|
>
>
|
>
>
~
Extension
Value
>
>
~
>
>
|
>
>
|
> &;
>
|
>
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
|
Event Sequence
Number
>
>
|
>
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
|x|S|x|x|
>
>
|
>
>
+-+-+-+-+
Label
>
>
|
>
>
~
>
>
~
>
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |x|x|x|x|x|x|x|x|
Message Type |
>Tech Type | Block
Length
>
>
|
>
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
|
>
>
|
>
>
~
Extension
Value
>
>
~
>
>
|
>
>
|
> &nbnbsp;
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> 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 desp;
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> 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
fined
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 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
>
>
~
>
> >
|
>
>
|
> &
> >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
>
>
~
>
> >
|
>
>
|
> &nbnbsp;
>
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
>
>
>
> >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 sp;
>
>
>
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
>
>
>
> >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 &n
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
>
> >
|
>
>
>
>
>
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-bsp;
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
>
>