Re: [5gangip] blockchain mapping system

["FIGURELLE, TERRY F" <[e-mail]>]

I was responding to the estimate for the example given and comparing that to virtualized UPF/SPGW. Note that you can't partition prefix's without causing other issues. This was one of the challenges with learn with SDN.

> -----Original Message-----
> From: Dino Farinacci <[e-mail]>
> Sent: Thursday, May 31, 2018 7:47 AM
> To: Jordi Paillissé Vilanova <[e-mail]>
> Cc: FIGURELLE, TERRY F <[e-mail]>om>; Mikael Abrahamsson
> <[e-mail]>se>; [e-mail]
> Subject: Re: [5gangip] blockchain mapping system
> 
> Terry, let me expand what Jordi is trying to get across. The LISP-DDT structure
> is relatively static and the delegation of EID-prefixes is the hierarchical
> structure of the DDT-roots, the DDT-nodes that are children of the roots, and
> the map-servers that are DDT leaf nodes.
> 
> What authenticates which Map-Servers are allowed to accept Map-Registers
> for their delegated prefixes can be stored in the blockchain. This is a write to
> the blockchain which is unmuutablely verified at the time the DDT branch is
> provisioned.
> 
> When a Map-Resolver is processing a Map-Request from an ITR, and receives
> a Map-Referral from a Map-Server, it could look up the Map-Server in the
> blockchain to verify that the EID-prefix in the referral matches the EID-prefix
> in the transaction stored on the blockchain.
> 
> Also, the Map-Referral is signed by the Map-Server, so the Map-Resolver
> could verify the signature by obtaining the public-key from the blockchain or
> use the one the DDT parent of the Map-Server returned in the Map-Referral
> (as well as make some conclusions if they differ).
> 
> There is no push mechanism here and the Map-Resolver gets EID->Map-
> Server referral entries by using DDT on demand. Blockchain is used to
> validate the address allocations and delegations and not any map-cache
> entries, which would change much more frequently then these delegations.
> 
> Dino
> 
> > On May 31, 2018, at 3:36 AM, Jordi Paillissé Vilanova <[e-mail]>
> wrote:
> >
> > Hi Terry,
> >
> > I agree, but you can use it to store pointers to the servers storing the
> mappings (like a DNS for mappings). Then these servers can support fast and
> dynamic updates.
> >
> > Regards,
> >
> > Jordi
> >
> >
> > El 30/05/18 a les 22:21, FIGURELLE, TERRY F ha escrit:
> >> Plus how can it be fast enough and propagating mapping information to all
> servers that store mappings is a huge challenge on physically large networks.
> >>
> >>> -----Original Message-----
> >>> From: 5gangip <[e-mail]> On Behalf Of Mikael
> >>> Abrahamsson
> >>> Sent: Monday, March 26, 2018 11:50 PM
> >>> To: Jordi Paillissé Vilanova <[e-mail]>
> >>> Cc: [e-mail]
> >>> Subject: Re: [5gangip] blockchain mapping system
> >>>
> >>> On Mon, 26 Mar 2018, Jordi Paillissé Vilanova wrote:
> >>>
> >>>> That said, depending on the dynamics of the mappings the blockchain
> >>>> is suitable or not for a mapping system. If mappings change
> >>>> frequently, it's not useful, so  it does not make sense for the 5G use-
> case.
> >>>>
> >>>> However, a blockchain can be useful to authenticate the servers
> >>>> that store such mappings, because this information changes way more
> >>>> slowly than mappings. A similar scenario is described in this draft:
> >>>> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.
> >>>> org_doc_draft-2Dpaillisse-2Dsidrops-
> 2Dblockchain_&d=DwIDaQ&c=LFYZ-
> >>> o9_H
> >>>
> UMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=gFRQ2s_dLZtBZOQpFDDiG
> >>> YKH8WUKw
> >>>
> _ZhBg4_uUdEFzo&s=UNs9FqOBStXgWINVb_jrtsjbdjKFsgkJiZmkt1O2YmY&e=
> >>>
> >>> "The main outcomes of the
> >>>     analysis are that blockchain is suitable in environments with
> >>>     multiple distrusting parties and that Proof of Stake is a potential
> >>>     candidate for a consensus algorithm."
> >>>
> >>> In what scenario for 5G is this applicable?
> >>>
> >>> --
> >>> Mikael Abrahamsson    email: [e-mail]
> >> _______________________________________________
> >> 5gangip mailing list
> >> [e-mail]
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mai
> >> lman_listinfo_5gangip&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTx
> >>
> wl2paJIf4zw&m=7kFHRLEmRPFqBrQZoS0uskFEHRrJ6lOuxu4HoknmfEQ&s=Uo
> s3OVgr-
> >> -LjBXlv97ceLrZggf2lKyU_-TzwMCBZMY8&e=
> >
> > _______________________________________________
> > 5gangip mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_5gangip&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl
> >
> 2paJIf4zw&m=7kFHRLEmRPFqBrQZoS0uskFEHRrJ6lOuxu4HoknmfEQ&s=Uos3
> OVgr--Lj
> > BXlv97ceLrZggf2lKyU_-TzwMCBZMY8&e=