If we simply call them "reserved" we always have the option to reuse
them
in alater contribution / new version if theer ever should be a need
to
use some bits in the event message header.
Also as another
comment, I still think it will be beneficial if we
describe that the
version number check should be per adjacency, so
we in the future can do a
version change easy and allow the ANCP
implementation to have multiple
adjacency with different versions of the
protocol, if we ever see a reason
to increase the version number it
will give a much easier upgrade
scenario.
cheers,
Peter
cheers,
Peter
________________________________
From: Wojciech Dec (wdec)
[mailto:wdec at cisco.com]
Sent: 7.
maj 2008 14:14
To: Ole Helleberg
Andersen; Peter Arberg; Sanjay Wadhwa; Tina TSOU; Maglione
Roberta
Cc:
ancp at ietf.org
Subject: RE: [ANCP] question regarding Labels in ANCP port up
messages
Hi
All,
it's with a certain
amount of incredulity that I view the proposals on this thread for changing
the version number of the protocol. Were such proposals to be accepted, by
definition it would make most likely the ANCP draft incompatible with *all*
current implementations, or at the very least introduce a compatibility mess
in existing deployments short of a flag day change over, not to mention the
issue of depreciating the old
version.
There really seems to
be no reason to go through with a version change due to what may be attributed
as a day 1 draft problem but *not* a day 1 implementation problem. Also, it is
not the first time that the protocol spec draft has had some inaccuracies, and
we've visited this aspect previously resulting in the following versioning
strategy being laid out:
http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html
. While the strategy states that an ANCP version change will not be considered
due to "incompatibilities arising from implementations of pre-RFC drafts",
neither does it state that the draft cannot change to reflect current
implementations while keeping the
version.
Now, given that
there seems to be some uneasiness (but thankfully not absolute) in the WG to
come forward publicly with details of what is currently implemented, I have
conducted a behind the scenes investigation of sorts, and present the
summarized findings below:
-
There are 10 distinct implementations of
ANCP
- Out of these 9 either
directly implement the label field format in as per section 5.3 of
draft-gsmpv3-base-spec-08, or each is known to be compatible with at least 2
implementations that do so. By association, it seems reasonable to claim that
all of these ANCP implementations use the draft-gsmpv3-base-spec-08 format.
Also, all use version 3.1 as the protocol version, and the base protocol
header also as per
draft-gsmpv3-base-spec-08
- One
implementation is known to use the draft-ietf-ancp-protocol-02 format of the
label field format, ie the rfc3292 format. This implementation is not known to
be compatible with any of the
others.
Based on this, but
not only, the obvious answer to the problem is *not* to do a version change,
but rather fix the draft. Granted, this is a far from ideal situation for the
one implementation affected, and it's a true shame that the problem wasn't
spotted earlier. Like Peter I also wonder how any interop was achieved, but
the fact that it is there is a significant one that should not be undone by
hasty version changes. As such option 2 below is not one we'll be taking
forward. Option 1 however also comes short as it does not quite follow the
logic of simply documenting what is known to be interoperable in the WG draft.
If specific implementations choose to realize knobs or other, fine, but this
is not part of the protocol spec, and there is no such thing as "old label
format". Please do consider the third option, ie fixing the draft to reflect
what is already done.
This
fact in general highlights the problems we're having in carrying with the
GSMPv3 (rfc3292) legacy, alongside adopted amendments from
draft-gsmpv3-base-spec (this Label issue not being the only adopted item),
alongside new protocol work. I trust that all of you agree that getting
maximum clarity on all the legacy issues and dependencies in the protocol spec
is in the WG's best interest, and that we are still some way off from that. As
such I also expect the WG to support moves/proposals aimed at getting that
clarity, with resolving this issue being not the first and not the last such
move.
Regards,
Woj.
________________________________
From: Ole Helleberg Andersen
[mailto:ole.helleberg.andersen at ericsson.com]
Sent: 06 May 2008
14:04
To: Peter Arberg; 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
Hi
All,
I think the main issue is to ensure interoperability with existing
implementations, and to allow for upgrading nodes that are already in service
to a WG-draft compliant version. To do that in a manageable way we must allow
for version negotiation per adjacency. We therefore need to change the
WG-draft as suggested by Sanjay in his option
2.
Concerning the encoding issue I prefer to make the WG-draft in line with
existing implementations. However, if the WG decides to change it, differences
in this encoding would also be solved by choosing Sanjay's option
2.
Cheers,
Ole
________________________________
From:
ancp-bounces at ietf.org
[mailto:ancp-bounces at ietf.org] On Behalf Of Peter
Arberg
Sent: 2. maj 2008
20:52
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
Hi
Sanjay,
yes apparently I missed your point in the last email, but I'm glad we agree
something is
needed
to make existing ANCP implementations and the current draft to
co-exist.
I do not like your option 1) as if you need a config knob for
interoperability, it is too easy
to
get into
trouble.
I think option 2) is the best way forward with the differences already
identified, or we
can
continue to get a show of hands of ANCP implementations, and see if anyone is
actually
deployed based on the
WG-draft.
There is no beneficial reasons to base the event-message of RFC3292, it could
as well be a
message
described bit by bit in the ANCP draft, and then we can keep the label space
at 8 as
many
implementations alreday
do.
cheers,
Peter
________________________________
From: Sanjay Wadhwa
[mailto:swadhwa at juniper.net]
Sent: 2. maj 2008
05:35
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
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 <
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 <
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 <
mailto:wdec at cisco.com>
>
>
To: Sanjay Wadhwa <
mailto:swadhwa at juniper.net <
mailto:swadhwa at juniper.net>
>
> ; Maglione Roberta <
mailto:roberta.maglione at telecomitalia.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 <
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 <
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.
&nbs