Re: [Casm] FW: notes from my side

[Rakesh Kumar <[e-mail]>]

I agree with your comments.

Regards 
Rakesh 

Sent from my iPhone

> On Mar 14, 2017, at 7:58 AM, Brian E Carpenter <[e-mail]> wrote:
> 
>> On 14/03/2017 17:50, Rakesh Kumar wrote:
>> Hi Brian,
>> 
>> The “address” record mean a fully qualified address or a network prefix, basically whatever the allocation unit is by address management functions.
> 
> OK, but that does need to be defined as part of the scoping of this work;
> you can't assume that it is understood the same way by everybody. However...
> 
>> Yes, we have to ensure data models are flexible but I think, this should be a common practice anyway. I believe RFC 7277 discuss this.
>> I hope, this is what you had asked about.
> 
> Not exactly. Yes, it is fairly simple to represent a single prefix or single address.
> But when you think about the basic purpose of this work, i.e., allocating prefixes
> out of prefixes and maintaining a record of what has been allocated, on a scale that
> might extend from say /20 out to /64 in the case of IPv6, I think that the question
> of data representation is quite complex and certainly not addressed by RFC 7277.
> IPAM systems have to solve this internally of course, but the question is how much
> of that complexity needs to be expressed in the API. For example, do we need the
> ability to attach a bitmap to a prefix, indicating which subprefixes are available
> or unavailable?
> 
> (I don't suggest that we need to decide this now, but I would be worried if we
> decided in advance that the simple model is sufficient. That's why I asked what
> "address records" means.)
> 
> Rgds
>   Brian
> 
>> 
>> Regards,
>> Rakesh
>> 
>> On 3/13/17, 5:01 PM, "Brian E Carpenter" <[e-mail]> wrote:
>> 
>> Hi,
>> 
>> Does "interface to get/update address records" really mean *address* records?
>> It seems to me that the elementary item should be a prefix (with IPv4/32
>> and IPv6/128 being used for individual addresses when appropriate) or a
>> choice between a prefix and an address if you prefer.
>> 
>> (draft-xie-ps-centralized-address-management mentions this aspect)
>> 
>> It seems to me one has to think very carefully about this, because for
>> IPv6 the number of prefixes (and of course of addresses) can be extremely
>> large. The data representation can be tricky.
>> 
>> Regards
>>   Brian Carpenter
>> 
>>> On 14/03/2017 04:34, Rakesh Kumar wrote:
>>> 
>>> 
>>> From: "Liushucheng (Will Liu)" <[e-mail]>
>>> Date: Monday, March 13, 2017 at 1:55 AM
>>> To: Rakesh Kumar <[e-mail]>
>>> Subject: RE: notes from my side
>>> 
>>> Dear Rakesh,
>>> 
>>> After a second read, I think this email is very clear and worth to post to list so that to answer Warrant’s question about scope.
>>> 
>>> Regards,
>>> Will LIU (Shucheng LIU)
>>> 
>>> From: Rakesh Kumar [mailto:[e-mail]]
>>> Sent: Thursday, March 09, 2017 4:32 PM
>>> To: Liushucheng (Will Liu) <[e-mail]>; [e-mail]; Marc Blanchet <[e-mail]>; Ralph Droms <[e-mail]>
>>> Cc: [e-mail]; 'Ying Cheng' <[e-mail]>; Pengtao (Tony) <[e-mail]>; Xie Chongfeng <[e-mail]>; [e-mail]; Rakesh Kumar <[e-mail]>
>>> Subject: Re: notes from my side
>>> 
>>> Hi Will,
>>> 
>>> My apologies for late response.
>>> 
>>> Like you mentioned there are two set of interfaces as shown in the draft:
>>> 
>>> 
>>> 1.       Client/Northbound interface to allow unified access to address management system (CASM). This should be RESTful interface with YANG data model.
>>> 
>>> 2.       Addressing function/Southbound interface to get/update address records. This could be protocol or RESTful interface but in my opinion, it is better to do RESTful interface so that existing system (standard-based or proprietary) could implement CASM defined interface on top of these functions to integrate with “CASM”.
>>> 
>>> I hope this gives us a very clear charter.
>>> 
>>> Thanks
>>> Rakesh
>>> 
>>> 
>>> From: "Liushucheng (Will Liu)" <[e-mail]<mailto:[e-mail]>>
>>> Date: Thursday, March 2, 2017 at 6:05 AM
>>> To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Marc Blanchet <[e-mail]<mailto:[e-mail]>>, Ralph Droms <[e-mail]<mailto:[e-mail]>>
>>> Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Ying Cheng' <[e-mail]<mailto:[e-mail]>>, "Pengtao (Tony)" <[e-mail]<mailto:[e-mail]>>, Xie Chongfeng <[e-mail]<mailto:[e-mail]>>, Rakesh Kumar <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
>>> Subject: notes from my side
>>> 
>>> Sorry that due to my pc, I missed some. Here is what I have, hope can help Adrian:
>>> 
>>> 
>>> Attendees: Adrian Farrel, Chen LI(China Telecom), Declan Ma(ZDNS), Ignas Bagdonas, Laurent Ciavaglia(AL/Nokia), Ralph Droms,  Ying CHNEG(China Unicom),Will LIU(Huawei), Tony Peng(Huawei)
>>> 
>>> Will: Unfortunately neither Rakesh from Juniper nor Chongfeng from CT can join us. However, we can use the framework draft to show their ideas, which is the interface or interfaces they want to standardize, and what are the scope. IMOH, in Rakesh draft there are two interfaces, NBI and SBI. Chen, please let them know how is your prototype working with these two interfaces.
>>> 
>>> Chen LI: SBI - netconf with YANG models, connecting three vendors develop;
>>> NBI - restful , connecting with APP, now only one APP, but the system can connect to multiple, such as OSS, orchestrator.
>>> 
>>> Regards,
>>> Will
>>> -----------------------------------------------------------------------------------
>>> Shucheng LIU (Will), Ph.D.
>>> Senior Researcher & Standard Representative, Project Manager
>>> Huawei Technologies Co.,Ltd
>>> Email: [e-mail]<mailto:[e-mail]>
>>> http://www.linkedin.com/in/shucheng
>>> -----------------------------------------------------------------------------------
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> CASM mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/casm
>>> 
>> 
>> 
>> 
>