Hi Suresh,
Will do. Would a simple statement e.g. that it is a null terminated text
string be sufficient or did you want more details?
There's no need for it to be NUL-terminated. In fact that's asking for trouble
because what do you do if the NUL and the field length don't match?
What
I support this I-D becoming an RFC. It's describing a solution that is needed
to deploy IPv6 in certain Broadband Access scenarios.
Regards
Olaf
On 11/3/2011 11:32 AM, Bob Hinden wrote:
All,
This message starts a two week 6MAN Working Group Last Call
on advancing:
Title
[This time it should make it to the list]
Original Message
Subject: Re: 6MAN WG Last Call: draft-ietf-6man-lineid-02.txt
Date: Tue, 08 Nov 2011 08:50:42 -0800
From: Erik Nordmark nordm...@sonic.net
To: Suresh Krishnan suresh.krish...@ericsson.com
CC: Erik Nordmark nordm
On 11/6/11 5:24 PM, Suresh Krishnan wrote:
Will do. Would a simple statement e.g. that it is a null terminated
text string be sufficient or did you want more details?
Or should we refer to the corresponding DHCPv4 relay option?
I think the simple case is when operators reuse the syntax
they
Hi Erik,
-Original Message-
From: Erik Nordmark [mailto:nordm...@acm.org]
Sent: Saturday, November 05, 2011 5:32 PM
To: Suresh Krishnan
Cc: Glen Turner; 6man Mailing List; Brian Haberman; Bob Hinden
Subject: Re: 6MAN WG Last Call: draft-ietf-6man-lineid-02.txt
On 11/5/11 6:36
Hi Glen,
Thanks for the comments. Please find responses inline.
On 11/03/2011 06:18 PM, Glen Turner wrote:
The contents of the Line Identification Destination Option are
essentially opaque.
Yes. They are.
Although this may allow a wide range of router implementations, in
practice it leads
On 11/5/11 6:36 AM, Suresh Krishnan wrote:
If the authors decide that opaque is desirable then they should define
the textual representation of the field. That way the contents of the
field are defined identically across different manufacturers' router
configuration languages, ISP provisioning
While I support this document generally, I am very sympathetic
to the specific operational issues raised by Glen Turner:
http://www.ietf.org/mail-archive/web/ipv6/current/msg14908.html
After approval, this IPv6 Line ID destination option will need
to be integrated with various provisioning
All,
This message starts a two week 6MAN Working Group Last Call on advancing:
Title : The Line Identification Destination Option
Author(s) : Suresh Krishnan
Alan Kavanagh
Balazs Varga
Support.
I have read this document. It provides a useful function in practical
fashion. It is ready for publication.
Yours,
Joel M. Halpern
On 11/3/2011 11:32 AM, Bob Hinden wrote:
All,
This message starts a two week 6MAN Working Group Last Call on advancing:
Title :
Support!
This document addresses an important issue in introducing IPv6 dual stack into
broadband access networks. N:1 VLAN as per TR-101 is a common deployment
model...
Dave
On 11/3/2011 11:32 AM, Bob Hinden wrote:
All,
This message starts a two week 6MAN Working Group Last Call on
The contents of the Line Identification Destination Option are
essentially opaque.
Although this may allow a wide range of router implementations, in
practice it leads to a situation where new implementers must
reverse-engineer the dominant implementation in order to be assured of
compatibility.
12 matches
Mail list logo