Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)
Hi, > Speaking personally, I have some concerns about this. > > I think my concerns can be lumped into two related categories. Bother are > about interoperability. > > Firstly, I find the registration of LCAFs without any explanation of how or > why they would be used to be awkward. I have implemented some Python code that tries to use LCAFs, and I can only say that it is very difficult as an implementer to deal with LCAFs. Often I have no idea where I can expect which LCAF type. The RFCs don't give enough guidance here in my opinion. The specs allow way too much. As an implementer I don't want to be surprised because some other implementation suddenly decides to use LCAF type 3 to add the ASN to the address. Not to mention that an LCAF address can contain another LCAF address. So should all implementations now support type-2 LCAF address within type-3 LCAF addresses in case some implementation decides to add both an instance-id and an ASN? And will that be encoded as type-2 in type-3 or as type-3 in type-2? What about when someone decides to add type-5 Geo information to the mix? Should all implementations support all possible combinations? This will make it much too hard to write a good implementation. Looking at the actual text there is something else that concerns me. LCAF type-1 (AFI List Type) is defined in a very confusing way. It is described in multiple use cases with different semantics, but I see no way for the receiver to know what is actually meant. Section 4.13.5. "Compatibility Mode Use Case" also confuses me: "A LISP system should use the AFI List Type format when sending to LISP systems that do not support a particular LCAF Type used to encode locators." How does the sender know what the receiver will support? And then there seems to be a contradiction: "The list of AFIs in an AFI List LCAF Type has no semantic ordering [...]" "[...] where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in the list is encoded with a valid AFI value to identify the locator address." So the ordering does seem to be important after all... Is it the intention to make this the default behaviour? That all such extra information should be encoded in a list with an AFI 0 address in the i.e. Geo LCAF address and the IP address that should be used in a AFI 1 or 2 address that follows next? Is this also meant to be supported in multiple layers, for example by sending a list with first a Geo LCAF, then an ASN LCAF and then a plain address? In that case it might be better to remove the addresses from all the 'annotation' types completely and define them to always be used in a list. Then the sender could always send it like that, and the receiver could skip over all annotations that it doesn't understand until it finds a non-LCAF AFI address. I understand that the authors want to define a very flexible address format, but without any rules or guidelines on how to encode address and in which circumstances it will be too hard for implementors to implement correctly in an interoperable way. There are now too many different ways to encode the same information, and that must be fixed. Either by changing the format (which I would strongly prefer) or by giving strict guidelines on how the current flexibility is to be used. Cheers, Sander ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)
>> On a related note, I find very general LCAFs a cause for concern. Particular
>> the JSON LCAF, which seems to allow the mapping system to reprogram the
>> packet processing hardware on the fly seems excessive. I understand it is
>> neat for experimentation. But how does something injecting a JSON LCAF have
>> a reasonable judgment about whether the ITR which will receive it will be
>> able to implement the processing required?
>
> Beyond the LCAF type, we can include a fixed size type that will tell the ITR
> if it is able to implement the processing required. From there we can define
> types that can be only used intra-domain or that are maningful inter-domain,
> again like XML applications.
It has been suggested before that we should define an LCAF type that identifies
the capabilities an xTR can support. It should be clear what an ETR supports by
what it registers, but one cannot tell if the ITR can use the information an
ETR has registered.
So I am not sure how this could be useful. I guess an ITR could register "I
support AFI=1 and Geo only" and if the ETR registered {AFI=1, AFI-2, Geo, and
ELP}, that it would only return in a Map-Reply to the ITR {AFI=1 and Geo}.
Just thinking out loud.
Dino
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt
Copying the LISP working group mailing list. >> This implies that both gpe LISP and legacy LISP may be used in the market. >> Is that true only IP-in-IP application need nonce feature? Mobility is >> important requirement for cloud applications, so gpe LISP needs to develop >> other solution for this feature? Sorry, this is a hard sale. > > If you use IP-in-IP you don't need to set the P-bit, making the nonce > available for use. Yes, there are applications where the nonce is useful. > [Lucy] Yes, I agree that the nonce is useful. But gpe LISP router will not > support that. Why do we want to remove this in the protocol evolution? Lucy, we are not removing anything. Like I said (and I don't want to continually repeat myself) that the features are tradeoffs. The motivation for the change was to get VXLAN to have protocol demuxing. And in the spirit of keeping the packet formats for VXLAN and LISP as identical as VXLAN will have it, the P-bit is being proposed for LISP. This is a proposal. The LISP working group must decide if the draft becomes a working group document. Dino > > Lucy > > Dino > >> >> Regards, >> Lucy >> >> >> >> -Original Message- >> From: Dino Farinacci [mailto:farina...@gmail.com] >> Sent: Tuesday, September 10, 2013 10:56 AM >> To: Lucy yong >> Cc: Paul Quinn (paulq); n...@ietf.org >> Subject: Re: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt >> >>> Regarding to the protocol evolution, does this mean that nonce/map-version >>> features in LISP will be deprecated? IMO: Having the same field overloaded >>> for many difference purposes is not good way for the protocol evolution, it >>> becomes messy. >> >> No it does not mean that. It means that the features need to be traded off. >> So the market/user-base will decide what it wants to use that field for. >> >> Dino >> >> ___ >> nvo3 mailing list >> n...@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 > > ___ > nvo3 mailing list > n...@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)
> If I were writing these things, I would put the registration for each of > those types in the companion document. That way, a reader could judge the > safety and utility of the proposed usage. Otherwise, the registration itself > is not understandable. I found putting them in one document, as an implementor, was extremely useful. Because if I do multiple LCAF features, I want to see how the designs can work either side-by-side or integrated with each other. Here is an example. There is no reason that one leg of an RLE could not be an Explicit Locator Path. > Asked backwards, why is there value in putting a bunch of IDs that are not > needed in base implementation into a spec that does not explain what they are > for? The LCAF, in a coarse matter, describes what an LCAF coding could be used for. And the companion document goes into way more detail and precisely specs the operation. Dino > > Yours, > Joel > > On 9/10/13 11:01 AM, Dino Farinacci wrote: >>> Speaking personally, I have some concerns about this. >>> >>> I think my concerns can be lumped into two related categories. Bother are >>> about interoperability. >>> >>> Firstly, I find the registration of LCAFs without any explanation of how or >>> why they would be used to be awkward. I know that some members of the WG >>> like to have everything in one document. But this is why we maintain >> >> We have companion documents (that are not working group chartered >> documents). Here are some examples: >> >> (1) The draft-ermagen-nat-travesal draft states how to use the NAT-Traversal >> LCAF type. >> (2) The draft-farinacci-lisp-te draft states how to use the Explicit Locator >> Path (ELP) LCAF type. >> (3) The draft-codas-lisp-re draft states how to use the Replication List >> Entry (RLE) LCAF type. >> (4) The draft-ietf-lisp-ddt draft stats how to use the Security LCAF type >> for LISP-DDT-sec. >> >>> registries. Once we have defined LCAFs, it is quite sensible for documents >>> which need LCAFs to add them to the registry, with the explanation of how >>> and why the particular LCAF is beign defined. >> >> So I would suspect that the JSON Data Model Type would have a companion >> document. >> >>> Note that unlike base protocol mechanisms, the set of LCAFs is not >>> something that all implementations need to understand. A LISP >>> implementation that is never going to do 5-tuple lookup does not need to >>> know about LCAFs >> >> Correct. >> >>> that are designed to handle that. And conversely defining new LCAFs ought >>> in my view create an obligation for new behavior in all LISP devices. (I >>> don't think the authors intend that kind of obligation.) >> >> This is generally true but I am finding more use-cases, where people just >> want to store data in the RLOC LCAF encoding for easier management and >> network-self-documentation. >> >>> On a related note, I find very general LCAFs a cause for concern. >>> Particular the JSON LCAF, which seems to allow the mapping system to >>> reprogram the packet processing hardware on the fly seems excessive. I >>> understand it is >> >> The LCAF document doesn't say how the JSON Data Model LCAF will be used so >> we can't assume it is for the case you state above. >> >>> neat for experimentation. But how does something injecting a JSON LCAF >>> have a reasonable judgment about whether the ITR which will receive it will >>> be able to implement the processing required? If we are assuming >>> particular deployment models, we need to describe that. (Which leads to >>> the question as to why it is in this document.) >> >> What we have done in two cases for similar compatibility issues is this: >> >> (1) For wanting to store Geo-Coordinates with RLOCs for ITRs that do not >> understand it, you encode the Geo-Coordinates LCAF type along with an AFI=1 >> or AFI=2 RLOC address in a AFI-List LCAF RLOC record. Then the ITR that >> doesn't understand the first AFI in the AFI-List (the Geo-Coordinate >> encoding), skips over it and goes to the next AFI in the AFI-List LCAF, >> where low and behold, there is an address it can encapsulate to. >> >> (2) The above is done for ELP encodings too. >> >> Dino >> >>> I may be in the rough on these concerns. >>> >>> Yours, >>> Joel >>> >>> On 9/10/13 12:35 AM, Dino Farinacci wrote: Folks, I compiled all the input I received for updates to the LCAF draft. Find enclosed the updated draft and a diff file. Deadline is tomorrow but we can have discussion before I post. So if there are any changes or comments, I can add them into the -03 draft. So I am not that worried about missing the deadline. Changes include: B.1. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affliations. o Added Instance-ID to the Multicast Info Type so there is relative
Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)
If I were writing these things, I would put the registration for each of those types in the companion document. That way, a reader could judge the safety and utility of the proposed usage. Otherwise, the registration itself is not understandable. Asked backwards, why is there value in putting a bunch of IDs that are not needed in base implementation into a spec that does not explain what they are for? Yours, Joel On 9/10/13 11:01 AM, Dino Farinacci wrote: Speaking personally, I have some concerns about this. I think my concerns can be lumped into two related categories. Bother are about interoperability. Firstly, I find the registration of LCAFs without any explanation of how or why they would be used to be awkward. I know that some members of the WG like to have everything in one document. But this is why we maintain We have companion documents (that are not working group chartered documents). Here are some examples: (1) The draft-ermagen-nat-travesal draft states how to use the NAT-Traversal LCAF type. (2) The draft-farinacci-lisp-te draft states how to use the Explicit Locator Path (ELP) LCAF type. (3) The draft-codas-lisp-re draft states how to use the Replication List Entry (RLE) LCAF type. (4) The draft-ietf-lisp-ddt draft stats how to use the Security LCAF type for LISP-DDT-sec. registries. Once we have defined LCAFs, it is quite sensible for documents which need LCAFs to add them to the registry, with the explanation of how and why the particular LCAF is beign defined. So I would suspect that the JSON Data Model Type would have a companion document. Note that unlike base protocol mechanisms, the set of LCAFs is not something that all implementations need to understand. A LISP implementation that is never going to do 5-tuple lookup does not need to know about LCAFs Correct. that are designed to handle that. And conversely defining new LCAFs ought in my view create an obligation for new behavior in all LISP devices. (I don't think the authors intend that kind of obligation.) This is generally true but I am finding more use-cases, where people just want to store data in the RLOC LCAF encoding for easier management and network-self-documentation. On a related note, I find very general LCAFs a cause for concern. Particular the JSON LCAF, which seems to allow the mapping system to reprogram the packet processing hardware on the fly seems excessive. I understand it is The LCAF document doesn't say how the JSON Data Model LCAF will be used so we can't assume it is for the case you state above. neat for experimentation. But how does something injecting a JSON LCAF have a reasonable judgment about whether the ITR which will receive it will be able to implement the processing required? If we are assuming particular deployment models, we need to describe that. (Which leads to the question as to why it is in this document.) What we have done in two cases for similar compatibility issues is this: (1) For wanting to store Geo-Coordinates with RLOCs for ITRs that do not understand it, you encode the Geo-Coordinates LCAF type along with an AFI=1 or AFI=2 RLOC address in a AFI-List LCAF RLOC record. Then the ITR that doesn't understand the first AFI in the AFI-List (the Geo-Coordinate encoding), skips over it and goes to the next AFI in the AFI-List LCAF, where low and behold, there is an address it can encapsulate to. (2) The above is done for ELP encodings too. Dino I may be in the rough on these concerns. Yours, Joel On 9/10/13 12:35 AM, Dino Farinacci wrote: Folks, I compiled all the input I received for updates to the LCAF draft. Find enclosed the updated draft and a diff file. Deadline is tomorrow but we can have discussion before I post. So if there are any changes or comments, I can add them into the -03 draft. So I am not that worried about missing the deadline. Changes include: B.1. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affliations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)
> Speaking personally, I have some concerns about this. > > I think my concerns can be lumped into two related categories. Bother are > about interoperability. > > Firstly, I find the registration of LCAFs without any explanation of how or > why they would be used to be awkward. I know that some members of the WG > like to have everything in one document. But this is why we maintain We have companion documents (that are not working group chartered documents). Here are some examples: (1) The draft-ermagen-nat-travesal draft states how to use the NAT-Traversal LCAF type. (2) The draft-farinacci-lisp-te draft states how to use the Explicit Locator Path (ELP) LCAF type. (3) The draft-codas-lisp-re draft states how to use the Replication List Entry (RLE) LCAF type. (4) The draft-ietf-lisp-ddt draft stats how to use the Security LCAF type for LISP-DDT-sec. > registries. Once we have defined LCAFs, it is quite sensible for documents > which need LCAFs to add them to the registry, with the explanation of how and > why the particular LCAF is beign defined. So I would suspect that the JSON Data Model Type would have a companion document. > Note that unlike base protocol mechanisms, the set of LCAFs is not something > that all implementations need to understand. A LISP implementation that is > never going to do 5-tuple lookup does not need to know about LCAFs Correct. > that are designed to handle that. And conversely defining new LCAFs ought in > my view create an obligation for new behavior in all LISP devices. (I don't > think the authors intend that kind of obligation.) This is generally true but I am finding more use-cases, where people just want to store data in the RLOC LCAF encoding for easier management and network-self-documentation. > On a related note, I find very general LCAFs a cause for concern. Particular > the JSON LCAF, which seems to allow the mapping system to reprogram the > packet processing hardware on the fly seems excessive. I understand it is The LCAF document doesn't say how the JSON Data Model LCAF will be used so we can't assume it is for the case you state above. > neat for experimentation. But how does something injecting a JSON LCAF have > a reasonable judgment about whether the ITR which will receive it will be > able to implement the processing required? If we are assuming particular > deployment models, we need to describe that. (Which leads to the question as > to why it is in this document.) What we have done in two cases for similar compatibility issues is this: (1) For wanting to store Geo-Coordinates with RLOCs for ITRs that do not understand it, you encode the Geo-Coordinates LCAF type along with an AFI=1 or AFI=2 RLOC address in a AFI-List LCAF RLOC record. Then the ITR that doesn't understand the first AFI in the AFI-List (the Geo-Coordinate encoding), skips over it and goes to the next AFI in the AFI-List LCAF, where low and behold, there is an address it can encapsulate to. (2) The above is done for ELP encodings too. Dino > I may be in the rough on these concerns. > > Yours, > Joel > > On 9/10/13 12:35 AM, Dino Farinacci wrote: >> Folks, I compiled all the input I received for updates to the LCAF draft. >> Find enclosed the updated draft and a diff file. >> >> Deadline is tomorrow but we can have discussion before I post. So if there >> are any changes or comments, I can add them into the -03 draft. So I am not >> that worried about missing the deadline. >> >> Changes include: >> >> B.1. Changes to draft-ietf-lisp-lcaf-03.txt >> >>o Submitted September 2013. >> >>o Updated references and author's affliations. >> >>o Added Instance-ID to the Multicast Info Type so there is relative >> ease in parsing (S,G) entries within a VPN. >> >>o Add port range encodings to the Application Data LCAF Type. >> >>o Add a new JSON LCAF Type. >> >>o Add Address Key/Value LCAF Type to allow attributes to be attached >> to an address. >> >> Dino >> >> >> >> >> >> >> >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
Hi Dino, You're right in the sense that the mapping system doesn't expose an "API" for doing reverse lookups. It would however be possible to do reverse lookups on the map servers (since we register EID->RLOC mappings), or based on aggregate EID->RLOC mapping data, such as from what lispmon.net provides - the latter basically does address-space scans as far as I know. I guess as long as you don't have access to the map-servers, it will become more and more difficult and to do this as LISP becomes more widely deployed. As it takes longer to compile this kind of a database, the time accuracy also decreases. All of this is probably a good thing indeed :-) > But not to take away from your point. But if those private addresses are not > injected into the underlying routing protocol and PE boxes run URPF, those > packets will be dropped. As long as you use private addresses from the IPv6 prefix(es) you're allowed to use I don't think uRPF will be an issue, but I suppose the benefit would also be marginal :( Best regards, Michiel On 9 Sep 2013, at 17:45, Dino Farinacci wrote: >> Even in the case where the ITR is on the CPE we might be able to do better. >> >> For IPv6 RLOCs, we could use temporary IPv6 addresses (IPv6 privacy >> extension, rfc4941 I think) as the RLOCs in outgoing packets. That way, >> you couldn't discover the EID by doing a "reverse lookup" on the RLOC in >> the mapping system. > > Well in today's deployments there are no RLOC records in the mapping > database. So finding an EID associated with an RLOC is a different thing to > do today. And this is goodness. > > But not to take away from your point. But if those private addresses are not > injected into the underlying routing protocol and PE boxes run URPF, those > packets will be dropped. > > Dino > >> This would be especially useful if the IPv6 prefix on your uplink is used >> on a multipoint link, if it's just used on a point-to-point link it's a >> bit pointless :) >> >> Best regards, >> >> Michiel >> >> On 09/09/2013 10:01, "Joel M. Halpern" wrote: >> >>> Doesn't this depend upon where the ITR is? >>> If, as is usually proposed, the ITR is a piece of CPE, then it will hide >>> the content of my message (good), and my individual EID (okay), but it >>> won't hide which site is sending the packet, which is an awful lot of >>> information. >>> >>> Also, moving the ITR to the PE router merely means that all the >>> information is collectible at that point. And we have observable data >>> that collectible => will be collected. >>> >>> Yours, >>> Joel >>> >>> On 9/8/13 10:15 PM, Dino Farinacci wrote: > Hello Noel, > >> Err, that would get the address and name of the ITR, not the actual >> source >> host. > > this thread started with a subject of how to save the Internet from the > all-powerful agencies. Lisp was not invented to hide your identity, > it's only separating it from the location - this doesn't mean the > location information cannot reveal your (real life) identity. At the > end the agencies want your name, not your (inner) IP address. Marc, you may have not followed Noel's point. Let me explain with more detail. (1) I sit at a LISP site, I have an EID assigned to me. I want to send packet and don't want anyone in the core to know I am sending. (2) My EID comes out of an EID-prefix that is assigned to the site I currently reside in. There are a pair of ITRs that encapsulate traffic for packets I source. (3) When I source packets, my EID is known by routers inside of the site, but when the packet hits the ITR, the ITR will encrypt the entire packet it is about to encapsulate. So the outer IP header, the UDP header, and the LISP header is sent in the clear. Everything after the LISP header is encrypted. (4) I propose that the ITR use a public-key stored in the mapping database. It does not need to be protected during transport. The only parties that have the private-key the ETRs at the destination site (and you can h a public/private pair per ETR). (5) Men in the middle cannot decrypt the encapsulated packet because they don't have the private key and it is never transmitted on the network. All they know is that a packet came from some site that is connected to ISP foobar. So what, that is coarse information. (6) The key is obtained by the ITR the same time it is getting the RLOC address for encapsulation. Both come together and if the EID or *key* changes, we treat it as a mobility event where a new registration is sent to the mapping database to advertise a new RLOC address and/or a new key. This is pretty simple. Yes it is slow. But so what. We can throw hardware technology at it or we can have th math guys come up with as good but less expensive algorithms.
Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)
El 10/09/2013 10:30, Joel M. Halpern escribió: Speaking personally, I have some concerns about this. I think my concerns can be lumped into two related categories. Bother are about interoperability. Firstly, I find the registration of LCAFs without any explanation of how or why they would be used to be awkward. I know that some members of the WG like to have everything in one document. But this is why we maintain registries. Once we have defined LCAFs, it is quite sensible for documents which need LCAFs to add them to the registry, with the explanation of how and why the particular LCAF is beign defined. Note that unlike base protocol mechanisms, the set of LCAFs is not something that all implementations need to understand. A LISP implementation that is never going to do 5-tuple lookup does not need to know about LCAFs that are designed to handle that. And conversely defining new LCAFs ought in my view create an obligation for new behavior in all LISP devices. (I don't think the authors intend that kind of obligation.) This is precisely the reason to standardize a flexible LCAF, there is no obligation to implement all the LCAFs defined, but just the ones that are used by a particular ITR. Pretty much like XML and the XML applications. On a related note, I find very general LCAFs a cause for concern. Particular the JSON LCAF, which seems to allow the mapping system to reprogram the packet processing hardware on the fly seems excessive. I understand it is neat for experimentation. But how does something injecting a JSON LCAF have a reasonable judgment about whether the ITR which will receive it will be able to implement the processing required? Beyond the LCAF type, we can include a fixed size type that will tell the ITR if it is able to implement the processing required. From there we can define types that can be only used intra-domain or that are maningful inter-domain, again like XML applications. If we are assuming particular deployment models, we need to describe that. (Which leads to the question as to why it is in this document.) Fully agree with this, two of the main reasons are flexiblity and to reduce the deployment cost of new applications of LISP. With the flexible LCAF we only need to update the ITR, not the mapping system. This is an important barrier for experimentation or new uses right now. Otherwise and as you mention, we will have to face and endless amount of LCAF types, one for each LISP use. Regards Albert I may be in the rough on these concerns. Yours, Joel On 9/10/13 12:35 AM, Dino Farinacci wrote: Folks, I compiled all the input I received for updates to the LCAF draft. Find enclosed the updated draft and a diff file. Deadline is tomorrow but we can have discussion before I post. So if there are any changes or comments, I can add them into the -03 draft. So I am not that worried about missing the deadline. Changes include: B.1. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affliations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)
Speaking personally, I have some concerns about this. I think my concerns can be lumped into two related categories. Bother are about interoperability. Firstly, I find the registration of LCAFs without any explanation of how or why they would be used to be awkward. I know that some members of the WG like to have everything in one document. But this is why we maintain registries. Once we have defined LCAFs, it is quite sensible for documents which need LCAFs to add them to the registry, with the explanation of how and why the particular LCAF is beign defined. Note that unlike base protocol mechanisms, the set of LCAFs is not something that all implementations need to understand. A LISP implementation that is never going to do 5-tuple lookup does not need to know about LCAFs that are designed to handle that. And conversely defining new LCAFs ought in my view create an obligation for new behavior in all LISP devices. (I don't think the authors intend that kind of obligation.) On a related note, I find very general LCAFs a cause for concern. Particular the JSON LCAF, which seems to allow the mapping system to reprogram the packet processing hardware on the fly seems excessive. I understand it is neat for experimentation. But how does something injecting a JSON LCAF have a reasonable judgment about whether the ITR which will receive it will be able to implement the processing required? If we are assuming particular deployment models, we need to describe that. (Which leads to the question as to why it is in this document.) I may be in the rough on these concerns. Yours, Joel On 9/10/13 12:35 AM, Dino Farinacci wrote: Folks, I compiled all the input I received for updates to the LCAF draft. Find enclosed the updated draft and a diff file. Deadline is tomorrow but we can have discussion before I post. So if there are any changes or comments, I can add them into the -03 draft. So I am not that worried about missing the deadline. Changes include: B.1. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affliations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
