[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-bagnulo-pshim6-00.txt

Hi Brian,


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 shim6
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 independence 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 

Regards, marcelo




    Brian