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
>
>
_______________________________________________ ANCP mailing list ANCP at ietf.org https://www.ietf.org/mailman/listinfo/ancp