Hi Thomas, On 12/02/2011 11:53 AM, Thomas Narten wrote: >> I assume that if the Line ID is going to be opaque we don't need to >> define how to encode strings in it. Suresh's email wasn't clear on >> that, if I understood it correctly. > > The problem with this is if the field actually holds a string, you > have to define a canonical representation for the string. It's just > not sufficient to say it is a "string" or a "UTF-8 string", etc. You > won't get interoperability with that.
I will try to describe the provisioning procedure a bit. When a subscriber line is provisioned, the operator will perform the following steps a) Configure the Access Node to insert a sequence of bytes into the line-id field. b) Configure the AAA server to hand out a given prefix when this exact sequence of bytes is received in an Access Request. The edge router will pass on, without inspecting, the line-id received from the RS and send it off to the AAA server to get the prefix to send out in the RA. > > This is something *ALL* IETF protocols are starting to grapple with, > if they allow protocol fields to hold strings, and one has to compare > those strings for equality. Right. I was proposing considering this field as an "Absolute Identifier" as defined in the IAB Identifier comparison draft and the match policy would be exact match. i.e. The match would fail if any of the bytes fail to match. > >> I still would like it to be an opaque field as that keeps it aligned >> with the DHCP option. > > The DHCP format was specified many years ago... the world is more > complex today... But the AAA systems that are used, will use the same kind of line-id (per operator) for both DHCP(v4/v6) and the RS. Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
