[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-bagnulo-pshim6-00.txt
El 28/02/2007, a las 15:14, Brian E Carpenter escribió:
I'm glad to see this written up, and I like
many aspects of it. I do have a couple of remarks
1. Exactly as with draft-farinacci-lisp, there is
a clear question whether it's wise to depend so
heavily on DNS for locator mapping. Or should we
invent a separate map distribution mechanism?
Let me see if i can detail exactly what the DNS is used for.
It really depends what features you want to achieve with the P-shim6
If you want to achieve Provider independence (i.e. have only PI
identifiers configured in the hosts and avoid renumbering costs) then
you need the new ULID RR and you will use the DNS to retrieve both ULID
and locator (exactly like HIP)
DNS is not used as a generic ULID to lookup mechanism (it could be used
but it is not really used AFICT)
If you don't want provider independence, the you don't need the new
ULID RR and regular PA addresses are stored in DNS just as regular
The reverse DNS is used to restore the ULID to locator mapping
information to the backup P-shim in case that the primary P-shim fails.
Please note that only the information that was originally in the
primary P-shim needs to be restored in the backup
The reverse DNs was used because is one mechanism that is already there
and it can be perfectly replaced with another mechanism. In particular
a primary Pshim - backup p-shim protocol could be used.
This is described in the draft in this way.
The DNS reverse tree is used to retireve locator information
associated with an unroutable ULID. In concrete, it is used in the
following situation: A shim6 context has been established between a
P-shim and a remote shim6 peer (either P-shim6 or a shim6 host). The
P-shim6 that has the shim6 context information fails and the backup
shim6 is used to continue with the communication. In order to do
that, the context information must be restored. In this case, the
backup P-shim6 needs to retrieve the locator information associated
to the ULID of the remote peer. It does so, by performing a DNS
reverse lookup for the CMULA used a ULID.
However, it should be noted that the locator information was already
available in the site, in particular, it was available in the primary
P-shim6. So it would be perfectly possible to create an inter-P-
shim6 protocol to exchange locator-ULID binding information between
the primary and the backup P-shim6 as soon as the the context is
created. This would distribute the locator to ULID binding
information and there would be no need to retrieve it from the DNS
reverse tree (and there would be no need to require the population of
the reverse DNS tree if such inter-P-shim6 protocol was available.
It must be noted that the reverse tree is never used to retrieve ULID
locator binding information for initial contact, but is only used to
restore information that was once available locally. this is why, it
is perfectly possible to design local mechanisms to substitute the
usage of the reverse DNS in the P-shim6 approach.
So i am perfectly open to define a new protocol for this and forget the
reverse DNS completely if people prefer this. This is not central to
the P-shim6 approach
2. I think we could probably use unregistered
ULAs and some fairly simple clash-detection mechanism.
Otherwise, we will be creating registration expense
for no very good reason.
This is perfectly possible.
as ULIDs, you can use PA addresses if you don't need provider
If you need provider independence, then some form of PI ULID is needed.
You can use CMULAs as described in the draft
You could use statiscally unique ULAs. One point here, is how to
publish them in the reverse DNS. In this case you would need as you
said a clash detection mechanism, like for instance trying to register
them in the reverse DNS tree. But i guess this would be possible also.
the other option is to simply use PI addresses as ULIDs get them
directly from the RIRs and not announced them in the BGP routing table