Rather, when the priority ties, the first client can keep the control. At t= his point, the first client means the firstly connected client for the cont= rolling data or firstly connected client to the agent with that data?=A0

Second, the statements of two documents, architecture (draft-ietf-i2rs-arch= itecture-00) and protocol requirement(draft-rfernando-i2rs-protocol-require= ments-00), seem to have somewhat different views about the communication ch= annel between client and agent. In the architecture document, Sec 6.2 state= s the communication channel between client and agent does not need to keep = continuous transport. But Sec 4.2 TR-12 of the protocol requirement documen= t states that keep-alives at transport level or I2RS protocol level could b= e provided for detecting the session failure. And simulataneous usage of se= ssion and communication channel of the architecture document is confusing f= or me.=A0

Finally, I have a question about the network application and client for cli= ent redundancy. I think client is not equal to network application. The arc= hitecture document states in Sec 6.5 for handling dead clients "the ne= twork applications or management systems will detect a dead network applica= tion and either restart that network application or clean up any state left= behind." In addition, for basic client redundancy, the architecture s= tates active and backup network application can be used. At this point, I w= ant to know both network applications are physically separated from the cli= ent?

Thank you for your comments, again :-)

best regards,

Kwang-koog Lee (KT)

On Fri, Jan 17, 2014 at 5:55 PM, Songhai= bin (A) <haibin.song@huawei.com> wrote:

Hi Sue,

Thank you very much for so detailed explanation. I understand your two prin= ciples very clearly now.

What comes into my mind is the following use case. Let's say it a bandw= idth on demand scenario. Two clients A and B have different priorities to c= hange user X's access bandwidth, and one client could be embedded in th= e user itself while another client is the system admin. Client A has higher= priority. Then user X's access bandwidth is the piece of data. At time= Y, Client A requests to change X's bandwidth to 20Mbps for two hours. = And after two hours, X's bandwidth is reset to its default value. And a= fter the time Y+2, either A or B should have the permission to change X'= ;s bandwidth data.

I guess you probably have already considered this.

Best Regards!
-Haibin

> -----Original Message-----
> From: Susan Hares [mailto:shares@nd= zh.com]
> Sent: Friday, January 17, 2014 7:47 AM
> To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee'=
> Cc: i2rs@ietf.org; Guanxiaoran
> Subject: RE: [i2rs] Mult= i-Headed Control
>
> Mach, Haibin, and KwanKooq:
>
> Joel gave you brief answers and then suggested reading the document. = =A0As
> one of the co-authors, I will attempt to give the "longer" a= nswers. I hope this
> will encourage discussion sections in the architecture document.
>
> This is not suggest current flaws in the architecture draft, but to el= ucidate
> (explain in depth) some of the drafts concepts. =A0You may be asking q= uestions
> that we hope will be discussed on the list, but I cannot tell yet.
> There are many sections in the architecture draft end with the phrase = "Editor's
> note: This topic (or These topics) need more discussion in the working= group."
> We encourage discussion of these drafts.
>
> If I am not answering the question, please just tell me. =A0The import= ant part of
> this work is to get an architecture and drafts that can be implemented= in
> routers and switches.
>
> Ok.. enough introduction. =A0On to a longer review that ends in a ques= tion:
>
> Review:
> ---------
>
> In section 1.2, page 6 (bottom) of the -00 version of the architecture= draft, I
> states:
>
> " =A0 As can be seen in Figure 1, an I2RS client can communicate = with
> =A0 =A0multiple I2RS agents. =A0An I2RS client may connect to one or m= ore I2RS
> =A0 =A0agents based upon its needs. =A0Similarly, an I2RS agent may > =A0 =A0communicate with multiple I2RS clients - whether to respond to = their
> =A0 =A0requests, to send notifications, etc. =A0Timely notifications a= re
> =A0 =A0critical so that several simultaneously operating applications = have
> =A0 =A0up-to-date information on the state of the network."
>
> Note here that the architecture states you may have one agent talking = to
> multiple I2RS clients. =A0Once you enter this zone, you can have colli= sions.
> In the beginning , we talk and talked about ways that you could handle=
> collisions - but we want to start simple.
>
> The phrase "protocol parsimony is clearly a goal" (section 3= .1, p. 9) suggest we
> are trying to implement just a few things in the first version of I2RS= Clients and
> I2RS Agents. =A0From there, the I2RS protocol will be extended later.<= br> >
> The simple rule for multi-headed control (section 6.8) is to consider = that two
> clients manipulating the same piece of data is an error. For example,<= br> > configuring an static route of prefix 192.1.1.0/24 should only be done by one
> client. =A0If two I2RS clients try to change the same piece of data in= the same
> I2RS Agent, it is an error.
>
> The architecture then requires that the I2RS clients and Agents have a=
> decidable way for the Agent to resolve the error. =A0 Section 6.8 stat= es our
> simple way:
> 1) assign each client a priority (either by policy or default policy)<= br> > 2) If the priorities tie, the first client "whose attribution is = associated with the
> data" keeps the control.
>
> That means - if you tie is First-come-keeps-control (FCKC)
>
> This is important to consider when you look at data models, scope (Sec= tion 2, p.
> 7-8), and identity. =A0You will note that the RIB manager is the easie= st thing to
> start with. =A0Only one person can change one prefix, but multiple I2R= S clients
> can add different prefixes to the list.
>
> Now, what if I2RS client A wants to add 10 prefixes to the RIB and thi= s includes
> 192.1.1.0/24 to = a single I2RS agent and I2RS client B wants to add
> 1 prefix 192.1.1.0/2= 4. =A0 Does it cause a problem with I2RS client A if I24S
> Client B gets there first (FCKC), and only 9 prefixes get added.
>
> That very issue is what section 6.9 deals with.
>
> Questions:
> -----------
> 1. Are you trying to determine what happens when the multi-headed cont= rol
> hits one of these errors? =A0[See Sections 6.5, 6.6, 6.8 and 6.9]
>
> 2. Are you trying to build redundant clients (I2RS client A and I2RS C= lient
> A') which are redundant clients? =A0[See section 6.4.1]
>
> 3. =A0Are you concerned about multi-headed control with multiple inter= faces per
> client?
> =A0 =A0(You could have 4 SCTP and 4 TCP session over which this protoc= ol runs)
> [Section 6.2]
>
> 4. How does a I2RS client A that reads the data know when I2RS Client = B
> modifies the Data?
> [Section 6.8]
>
> Sue Hares
>
>
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounc= es@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Tuesday, January 14, 2014 11:11 PM
> To: Songhaibin (A); KwangKoog Lee
> Cc: i2rs@ietf.org; Guanxiaoran > Subject: Re: [i2rs] Multi-Headed Control
>
> There are no locks.
> The changes made by the higher priority client remain in effect until = either they
> are removed by that client or an even higher priority client erroneous= ly
> over-writes them. =A0Changes do not have lifetimes.
>
> One of the points of this mechanism was to avoid needing to guess what= order
> things happened in if they are close in time and you want to know the = results.
>
> Please, read the draft.
>
> Yours,
> Joel
>
> On 1/14/14 10:50 PM, Songhaibin (A) wrote:
> > Hi Joel,
> >
> > It is a little confusing for me. See inline.
> >
> >> -----Original Message-----
> >> From: i2rs [mailto:i= 2rs-bounces@ietf.org] On Behalf Of Joel M.
> >> Halpern
> >> Sent: Tuesday, January 14, 2014 11:43 PM
> >> To: KwangKoog Lee
> >> Cc: i2rs@ietf.org; Guanx= iaoran
> >> Subject: Re: [i2rs] Multi-Headed Control
> >>
> >> While I will try to paraphrase things to answer your question= , I
> >> recommend you read the archtiecture draft to get more details= .
> >>
> >> The assumption is that normally different I2RS clients will b= e asking
> >> the agent to perform operations which change different pieces= of data.
> >> We discussed various models of conflict resolution for the ca= se when
> >> one client adjusts a piece of data, and then another client g= oes to
> >> change that data. =A0We decided that this was an error, and t= hat we
> >> wanted a simple mechanism to decide what to do, while the cli= ents
> >> sort
> out what was intended.
> >
> > Except for client priorities, there are other factors like timing= . I
> assume that a client with higher priority changes a piece of data, but= then a
> client with lower priority can make changes to the same piece of data.= It could
> possibly depend on the how long the client with higher priority wants = that
> change to take effect.
> >
> > But when two clients want to make changes to the same data at the= same
> time, then the client with higher priority will get the <lock>, = and the request
> from the client with lower priority will be denied. And we can leave t= he choice
> on whether to make another try to the client itself.
> >
> > Regards!
> > -Haibin
> >
> >> Rather than
> >> pure FCFS, we decided to have client priorities. =A0And that = clients
> >> could arrange
> >> (easily) to be notified of changes to data they are intereste= d in.
> >>
> >> The goal is to keep the mechanisms very lightweight, particul= arly in
> >> order to support very high rates of operations.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 1/14/14 10:29 AM, KwangKoog Lee wrote:
> >>> I do not fully understand the data model of i2rs. But in = case that
> >>> many clients interact forwarding devices with the i2rs-en= abled
> >>> control plane, various policies about routing, signaling,= qos and
> >>> etc. from multiple clients or multiple upper users (netwo= rk
> >>> applications) can be set to those devices and to prevent = or
> >>> negotiate some collision of multiple policies, such a mac= hanism
> >>> might be necessary regardless of
> >> netconf?
> >>> =A0 =A0Joel or anyone can explain more why it does not ne= ed? Thanks in
> advance.
> >>>
> >>> best regards,
> >>> Kwang-koog Lee
> >>> On Tue, Jan 14, 2014 at 11:19 PM, Joel M. Halpern
> >>> <jmh@joelhalper= n.com <mailto:jmh@joelhalpern= .com>> wrote:
> >>>
> >>> =A0 =A0 =A0As I read the documents, locking is specifical= ly not the approach
> >>> =A0 =A0 =A0I2RS is taking. =A0So I think that "<l= ock>" does not suffice to
> >>> =A0 =A0 =A0resolve the I2RS needs, and is in fact not par= t of the current I2RS
> >>> =A0 =A0 =A0arhtiecture at all.
> >>> =A0 =A0 =A0Yours,
> >>> =A0 =A0 =A0Joel
> >>> =A0 =A0 =A0On 1/14/14 4:17 AM, Guanxiaoran wrote:
> >>>
> >>> =A0 =A0 =A0 =A0 =A0Hi,
> >>> =A0 =A0 =A0 =A0 =A0I've a question about i2rs multi-h= eaded control and NETCONF.
> >>> =A0 =A0 =A0 =A0 =A0[draft-ietf-i2rs-problem-__statement-0= 0] describes:"Additional
> >>> =A0 =A0 =A0 =A0 =A0extensions to handle multi-headed cont= rol may need to be
> added
> >>> =A0 =A0 =A0 =A0 =A0to NetConf and/or appropriate data mod= els."
> >>> =A0 =A0 =A0 =A0 =A0[draft-ietf-i2rs-architecture-__00] de= scribes:"The current
> >>> =A0 =A0 =A0 =A0 =A0recommendation is to have a simple pri= ority associated with
> each
> >>> =A0 =A0 =A0 =A0 =A0I2RS clients, and the highest priority= change remains in
> effect."
> >>> =A0 =A0 =A0 =A0 =A0As NETCONF has <lock> mechanism:= "The <lock> operation
> allows
> >>> =A0 =A0 =A0 =A0 =A0the client to lock the entire configur= ation data-store
> >>> system
> of
> >>> =A0 =A0 =A0 =A0 =A0a device. Such locks are intended to b= e short-lived and allow a
> >>> =A0 =A0 =A0 =A0 =A0client to make a change without fear o= f interaction with other
> >>> =A0 =A0 =A0 =A0 =A0NETCONF clients, non-NETCONF clients (= e.g., SNMP and CLI),
> and
> >>> =A0 =A0 =A0 =A0 =A0human users."
> >>> =A0 =A0 =A0 =A0 =A0Do we still need to do the extensions,= i.e. additional
> >>> =A0 =A0 =A0 =A0 =A0extensions to handle multi-headed cont= rol added to NETCONF?
> >>> =A0 =A0 =A0 =A0 =A0Regards,
> >>> =A0 =A0 =A0 =A0 =A0Ran
> >>> =A0 =A0 =A0 =A0 =A0______________________________________= ___________
> >>> =A0 =A0 =A0 =A0 =A0i2rs mailing list
> >>> =A0 =A0 =A0 =A0 =A0i2rs@= ietf.org <mailto:i2rs@ietf.org&= gt;
> >>> =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/__listinf= o/i2rs
> >>> =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/listinf= o/i2rs>
> >>>
> >>> =A0 =A0 =A0______________________________________________= ___
> >>> =A0 =A0 =A0i2rs mailing list
> >>> =A0 =A0 =A0i2rs@ietf.org= <mailto:i2rs@ietf.org>
> >>> =A0 =A0 =A0https://www.ietf.org/mailman/__listinfo/i2rs
> >>> =A0 =A0 =A0<https://www.ietf.org/mailman/listinfo/i2rs>
> >>>
> >> _______________________________________________
> >> i2rs mailing list
> >> i2rs@ietf.org
> >> https://www.ietf.org/mailman/listinfo/i2rs
> > _______________________________________________
> > i2rs mailing list
> > i2rs@ietf.org
> > https://www.ietf.org/mailman/listinfo/i2rs
> >
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

--e89a8f3baad50b311a04f026fdff-- From jmh@joelhalpern.com Fri Jan 17 07:06:22 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0887F1AE0F3 for ; Fri, 17 Jan 2014 07:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXQBcRbBmtc7 for ; Fri, 17 Jan 2014 07:06:19 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id CFAF11ACCEF for ; Fri, 17 Jan 2014 07:06:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 93CA91C0529; Fri, 17 Jan 2014 07:06:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CD56C1D81D8; Fri, 17 Jan 2014 07:06:05 -0800 (PST) Message-ID: <52D946DD.8020405@joelhalpern.com> Date: Fri, 17 Jan 2014 10:06:05 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Songhaibin (A)" , Susan Hares , 'KwangKoog Lee' References: <2C5AD5728DB9B24189E3A93140E45786366363@szxeml522-mbx.china.huawei.com> <52D54787.3070601@joelhalpern.com> <52D55B0F.6050407@joelhalpern.com> <52D60A5F.1000702@joelhalpern.com> <009901cf1315$4cf80f80$e6e82e80$@ndzh.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Guanxiaoran Subject: Re: [i2rs] Multi-Headed Control X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 15:06:22 -0000 One thing to keep in mind. The WG has agreed to drop all time-based operations. Changes are applied when the order is given, and they remain until they are replaced / overw-written (or the box resets). Changes do not have expieration times. Yours, Joel On 1/17/14 3:55 AM, Songhaibin (A) wrote: > Hi Sue, > > Thank you very much for so detailed explanation. I understand your two principles very clearly now. > > What comes into my mind is the following use case. Let's say it a bandwidth on demand scenario. Two clients A and B have different priorities to change user X's access bandwidth, and one client could be embedded in the user itself while another client is the system admin. Client A has higher priority. Then user X's access bandwidth is the piece of data. At time Y, Client A requests to change X's bandwidth to 20Mbps for two hours. And after two hours, X's bandwidth is reset to its default value. And after the time Y+2, either A or B should have the permission to change X's bandwidth data. > > I guess you probably have already considered this. > > Best Regards! > -Haibin > >> -----Original Message----- >> From: Susan Hares [mailto:shares@ndzh.com] >> Sent: Friday, January 17, 2014 7:47 AM >> To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee' >> Cc: i2rs@ietf.org; Guanxiaoran >> Subject: RE: [i2rs] Multi-Headed Control >> >> Mach, Haibin, and KwanKooq: >> >> Joel gave you brief answers and then suggested reading the document. As >> one of the co-authors, I will attempt to give the "longer" answers. I hope this >> will encourage discussion sections in the architecture document. >> >> This is not suggest current flaws in the architecture draft, but to elucidate >> (explain in depth) some of the drafts concepts. You may be asking questions >> that we hope will be discussed on the list, but I cannot tell yet. >> There are many sections in the architecture draft end with the phrase "Editor's >> note: This topic (or These topics) need more discussion in the working group." >> We encourage discussion of these drafts. >> >> If I am not answering the question, please just tell me. The important part of >> this work is to get an architecture and drafts that can be implemented in >> routers and switches. >> >> Ok.. enough introduction. On to a longer review that ends in a question: >> >> Review: >> --------- >> >> In section 1.2, page 6 (bottom) of the -00 version of the architecture draft, I >> states: >> >> " As can be seen in Figure 1, an I2RS client can communicate with >> multiple I2RS agents. An I2RS client may connect to one or more I2RS >> agents based upon its needs. Similarly, an I2RS agent may >> communicate with multiple I2RS clients - whether to respond to their >> requests, to send notifications, etc. Timely notifications are >> critical so that several simultaneously operating applications have >> up-to-date information on the state of the network." >> >> Note here that the architecture states you may have one agent talking to >> multiple I2RS clients. Once you enter this zone, you can have collisions. >> In the beginning , we talk and talked about ways that you could handle >> collisions - but we want to start simple. >> >> The phrase "protocol parsimony is clearly a goal" (section 3.1, p. 9) suggest we >> are trying to implement just a few things in the first version of I2RS Clients and >> I2RS Agents. From there, the I2RS protocol will be extended later. >> >> The simple rule for multi-headed control (section 6.8) is to consider that two >> clients manipulating the same piece of data is an error. For example, >> configuring an static route of prefix 192.1.1.0/24 should only be done by one >> client. If two I2RS clients try to change the same piece of data in the same >> I2RS Agent, it is an error. >> >> The architecture then requires that the I2RS clients and Agents have a >> decidable way for the Agent to resolve the error. Section 6.8 states our >> simple way: >> 1) assign each client a priority (either by policy or default policy) >> 2) If the priorities tie, the first client "whose attribution is associated with the >> data" keeps the control. >> >> That means - if you tie is First-come-keeps-control (FCKC) >> >> This is important to consider when you look at data models, scope (Section 2, p. >> 7-8), and identity. You will note that the RIB manager is the easiest thing to >> start with. Only one person can change one prefix, but multiple I2RS clients >> can add different prefixes to the list. >> >> Now, what if I2RS client A wants to add 10 prefixes to the RIB and this includes >> 192.1.1.0/24 to a single I2RS agent and I2RS client B wants to add >> 1 prefix 192.1.1.0/24. Does it cause a problem with I2RS client A if I24S >> Client B gets there first (FCKC), and only 9 prefixes get added. >> >> That very issue is what section 6.9 deals with. >> >> Questions: >> ----------- >> 1. Are you trying to determine what happens when the multi-headed control >> hits one of these errors? [See Sections 6.5, 6.6, 6.8 and 6.9] >> >> 2. Are you trying to build redundant clients (I2RS client A and I2RS Client >> A') which are redundant clients? [See section 6.4.1] >> >> 3. Are you concerned about multi-headed control with multiple interfaces per >> client? >> (You could have 4 SCTP and 4 TCP session over which this protocol runs) >> [Section 6.2] >> >> 4. How does a I2RS client A that reads the data know when I2RS Client B >> modifies the Data? >> [Section 6.8] >> >> Sue Hares >> >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Tuesday, January 14, 2014 11:11 PM >> To: Songhaibin (A); KwangKoog Lee >> Cc: i2rs@ietf.org; Guanxiaoran >> Subject: Re: [i2rs] Multi-Headed Control >> >> There are no locks. >> The changes made by the higher priority client remain in effect until either they >> are removed by that client or an even higher priority client erroneously >> over-writes them. Changes do not have lifetimes. >> >> One of the points of this mechanism was to avoid needing to guess what order >> things happened in if they are close in time and you want to know the results. >> >> Please, read the draft. >> >> Yours, >> Joel >> >> On 1/14/14 10:50 PM, Songhaibin (A) wrote: >>> Hi Joel, >>> >>> It is a little confusing for me. See inline. >>> >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. >>>> Halpern >>>> Sent: Tuesday, January 14, 2014 11:43 PM >>>> To: KwangKoog Lee >>>> Cc: i2rs@ietf.org; Guanxiaoran >>>> Subject: Re: [i2rs] Multi-Headed Control >>>> >>>> While I will try to paraphrase things to answer your question, I >>>> recommend you read the archtiecture draft to get more details. >>>> >>>> The assumption is that normally different I2RS clients will be asking >>>> the agent to perform operations which change different pieces of data. >>>> We discussed various models of conflict resolution for the case when >>>> one client adjusts a piece of data, and then another client goes to >>>> change that data. We decided that this was an error, and that we >>>> wanted a simple mechanism to decide what to do, while the clients >>>> sort >> out what was intended. >>> >>> Except for client priorities, there are other factors like timing. I >> assume that a client with higher priority changes a piece of data, but then a >> client with lower priority can make changes to the same piece of data. It could >> possibly depend on the how long the client with higher priority wants that >> change to take effect. >>> >>> But when two clients want to make changes to the same data at the same >> time, then the client with higher priority will get the , and the request >> from the client with lower priority will be denied. And we can leave the choice >> on whether to make another try to the client itself. >>> >>> Regards! >>> -Haibin >>> >>>> Rather than >>>> pure FCFS, we decided to have client priorities. And that clients >>>> could arrange >>>> (easily) to be notified of changes to data they are interested in. >>>> >>>> The goal is to keep the mechanisms very lightweight, particularly in >>>> order to support very high rates of operations. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 1/14/14 10:29 AM, KwangKoog Lee wrote: >>>>> I do not fully understand the data model of i2rs. But in case that >>>>> many clients interact forwarding devices with the i2rs-enabled >>>>> control plane, various policies about routing, signaling, qos and >>>>> etc. from multiple clients or multiple upper users (network >>>>> applications) can be set to those devices and to prevent or >>>>> negotiate some collision of multiple policies, such a machanism >>>>> might be necessary regardless of >>>> netconf? >>>>> Joel or anyone can explain more why it does not need? Thanks in >> advance. >>>>> >>>>> best regards, >>>>> Kwang-koog Lee >>>>> On Tue, Jan 14, 2014 at 11:19 PM, Joel M. Halpern >>>>> > wrote: >>>>> >>>>> As I read the documents, locking is specifically not the approach >>>>> I2RS is taking. So I think that "" does not suffice to >>>>> resolve the I2RS needs, and is in fact not part of the current I2RS >>>>> arhtiecture at all. >>>>> Yours, >>>>> Joel >>>>> On 1/14/14 4:17 AM, Guanxiaoran wrote: >>>>> >>>>> Hi, >>>>> I've a question about i2rs multi-headed control and NETCONF. >>>>> [draft-ietf-i2rs-problem-__statement-00] describes:"Additional >>>>> extensions to handle multi-headed control may need to be >> added >>>>> to NetConf and/or appropriate data models." >>>>> [draft-ietf-i2rs-architecture-__00] describes:"The current >>>>> recommendation is to have a simple priority associated with >> each >>>>> I2RS clients, and the highest priority change remains in >> effect." >>>>> As NETCONF has mechanism: "The operation >> allows >>>>> the client to lock the entire configuration data-store >>>>> system >> of >>>>> a device. Such locks are intended to be short-lived and allow a >>>>> client to make a change without fear of interaction with other >>>>> NETCONF clients, non-NETCONF clients (e.g., SNMP and CLI), >> and >>>>> human users." >>>>> Do we still need to do the extensions, i.e. additional >>>>> extensions to handle multi-headed control added to NETCONF? >>>>> Regards, >>>>> Ran >>>>> _________________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/__listinfo/i2rs >>>>> >>>>> >>>>> _________________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/__listinfo/i2rs >>>>> >>>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From jmh@joelhalpern.com Fri Jan 17 07:10:19 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2361AE0F1 for ; Fri, 17 Jan 2014 07:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06Rdti6HsS4J for ; Fri, 17 Jan 2014 07:10:15 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id BFBAC1ACCEF for ; Fri, 17 Jan 2014 07:10:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9A5A22A14A5; Fri, 17 Jan 2014 07:10:03 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1F7E42A14A2; Fri, 17 Jan 2014 07:10:00 -0800 (PST) Message-ID: <52D947C9.7030605@joelhalpern.com> Date: Fri, 17 Jan 2014 10:10:01 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: KwangKoog Lee , "Songhaibin (A)" References: <2C5AD5728DB9B24189E3A93140E45786366363@szxeml522-mbx.china.huawei.com> <52D54787.3070601@joelhalpern.com> <52D55B0F.6050407@joelhalpern.com> <52D60A5F.1000702@joelhalpern.com> <009901cf1315$4cf80f80$e6e82e80$@ndzh.com>

In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Guanxiaoran , Susan Hares Subject: Re: [i2rs] Multi-Headed Control X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 15:10:20 -0000 As was discussed at the last meeting, The authors of the rfernando requirements draft will be making some changes to align with the working group agreed architecture. There are currently some minor (and I believe unintentional) discrepancies. And in the context of collision detection, "first" simply means the first client to change a piece of data. We hope folks do not rely on that mechanism, as it is unpredictable in outcome when changes are applied close together in time. That is why we have the priority scheme. Yours, Joel PS: Client archtiecture, application architecture, and client management are out of scope for this document. There are many ways they can be built, and we are not mandating an approach. On 1/17/14 4:15 AM, KwangKoog Lee wrote: > Dear Susan Hares, > > I deeply appreciate for your kind explanation about the multi-headed > control of I2RS so that I reviewed the architecture document again and > understood about the error-handling mechanism and the simplicity of I2RS > nature. Sorry for my poor understanding of I2RS. > > Regarding to your comments, I still have some questions to be more clear. > > First, as you explained and the architecture states, the manipulation of > the collision of multi-headed control can be processed by the assignment > of client priorities. > Rather, when the priority ties, the first client can keep the control. > At this point, the first client means the firstly connected client for > the controlling data or firstly connected client to the agent with that > data? > > Second, the statements of two documents, architecture > (draft-ietf-i2rs-architecture-00) and protocol > requirement(draft-rfernando-i2rs-protocol-requirements-00), seem to have > somewhat different views about the communication channel between client > and agent. In the architecture document, Sec 6.2 states the > communication channel between client and agent does not need to keep > continuous transport. But Sec 4.2 TR-12 of the protocol requirement > document states that keep-alives at transport level or I2RS protocol > level could be provided for detecting the session failure. And > simulataneous usage of session and communication channel of the > architecture document is confusing for me. > > Finally, I have a question about the network application and client for > client redundancy. I think client is not equal to network application. > The architecture document states in Sec 6.5 for handling dead clients > "the network applications or management systems will detect a dead > network application and either restart that network application or clean > up any state left behind." In addition, for basic client redundancy, the > architecture states active and backup network application can be used. > At this point, I want to know both network applications are physically > separated from the client? > > Thank you for your comments, again :-) > > best regards, > Kwang-koog Lee (KT) > > > > On Fri, Jan 17, 2014 at 5:55 PM, Songhaibin (A) > wrote: > > Hi Sue, > > Thank you very much for so detailed explanation. I understand your > two principles very clearly now. > > What comes into my mind is the following use case. Let's say it a > bandwidth on demand scenario. Two clients A and B have different > priorities to change user X's access bandwidth, and one client could > be embedded in the user itself while another client is the system > admin. Client A has higher priority. Then user X's access bandwidth > is the piece of data. At time Y, Client A requests to change X's > bandwidth to 20Mbps for two hours. And after two hours, X's > bandwidth is reset to its default value. And after the time Y+2, > either A or B should have the permission to change X's bandwidth data. > > I guess you probably have already considered this. > > Best Regards! > -Haibin > > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com ] > > Sent: Friday, January 17, 2014 7:47 AM > > To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee' > > Cc: i2rs@ietf.org ; Guanxiaoran > > Subject: RE: [i2rs] Multi-Headed Control > > > > Mach, Haibin, and KwanKooq: > > > > Joel gave you brief answers and then suggested reading the > document. As > > one of the co-authors, I will attempt to give the "longer" > answers. I hope this > > will encourage discussion sections in the architecture document. > > > > This is not suggest current flaws in the architecture draft, but > to elucidate > > (explain in depth) some of the drafts concepts. You may be > asking questions > > that we hope will be discussed on the list, but I cannot tell yet. > > There are many sections in the architecture draft end with the > phrase "Editor's > > note: This topic (or These topics) need more discussion in the > working group." > > We encourage discussion of these drafts. > > > > If I am not answering the question, please just tell me. The > important part of > > this work is to get an architecture and drafts that can be > implemented in > > routers and switches. > > > > Ok.. enough introduction. On to a longer review that ends in a > question: > > > > Review: > > --------- > > > > In section 1.2, page 6 (bottom) of the -00 version of the > architecture draft, I > > states: > > > > " As can be seen in Figure 1, an I2RS client can communicate with > > multiple I2RS agents. An I2RS client may connect to one or > more I2RS > > agents based upon its needs. Similarly, an I2RS agent may > > communicate with multiple I2RS clients - whether to respond to > their > > requests, to send notifications, etc. Timely notifications are > > critical so that several simultaneously operating applications > have > > up-to-date information on the state of the network." > > > > Note here that the architecture states you may have one agent > talking to > > multiple I2RS clients. Once you enter this zone, you can have > collisions. > > In the beginning , we talk and talked about ways that you could > handle > > collisions - but we want to start simple. > > > > The phrase "protocol parsimony is clearly a goal" (section 3.1, > p. 9) suggest we > > are trying to implement just a few things in the first version of > I2RS Clients and > > I2RS Agents. From there, the I2RS protocol will be extended later. > > > > The simple rule for multi-headed control (section 6.8) is to > consider that two > > clients manipulating the same piece of data is an error. For example, > > configuring an static route of prefix 192.1.1.0/24 > should only be done by one > > client. If two I2RS clients try to change the same piece of data > in the same > > I2RS Agent, it is an error. > > > > The architecture then requires that the I2RS clients and Agents > have a > > decidable way for the Agent to resolve the error. Section 6.8 > states our > > simple way: > > 1) assign each client a priority (either by policy or default policy) > > 2) If the priorities tie, the first client "whose attribution is > associated with the > > data" keeps the control. > > > > That means - if you tie is First-come-keeps-control (FCKC) > > > > This is important to consider when you look at data models, scope > (Section 2, p. > > 7-8), and identity. You will note that the RIB manager is the > easiest thing to > > start with. Only one person can change one prefix, but multiple > I2RS clients > > can add different prefixes to the list. > > > > Now, what if I2RS client A wants to add 10 prefixes to the RIB > and this includes > > 192.1.1.0/24 to a single I2RS agent and > I2RS client B wants to add > > 1 prefix 192.1.1.0/24 . Does it cause a > problem with I2RS client A if I24S > > Client B gets there first (FCKC), and only 9 prefixes get added. > > > > That very issue is what section 6.9 deals with. > > > > Questions: > > ----------- > > 1. Are you trying to determine what happens when the multi-headed > control > > hits one of these errors? [See Sections 6.5, 6.6, 6.8 and 6.9] > > > > 2. Are you trying to build redundant clients (I2RS client A and > I2RS Client > > A') which are redundant clients? [See section 6.4.1] > > > > 3. Are you concerned about multi-headed control with multiple > interfaces per > > client? > > (You could have 4 SCTP and 4 TCP session over which this > protocol runs) > > [Section 6.2] > > > > 4. How does a I2RS client A that reads the data know when I2RS > Client B > > modifies the Data? > > [Section 6.8] > > > > Sue Hares > > > > > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org > ] On Behalf Of Joel M. Halpern > > Sent: Tuesday, January 14, 2014 11:11 PM > > To: Songhaibin (A); KwangKoog Lee > > Cc: i2rs@ietf.org ; Guanxiaoran > > Subject: Re: [i2rs] Multi-Headed Control > > > > There are no locks. > > The changes made by the higher priority client remain in effect > until either they > > are removed by that client or an even higher priority client > erroneously > > over-writes them. Changes do not have lifetimes. > > > > One of the points of this mechanism was to avoid needing to guess > what order > > things happened in if they are close in time and you want to know > the results. > > > > Please, read the draft. > > > > Yours, > > Joel > > > > On 1/14/14 10:50 PM, Songhaibin (A) wrote: > > > Hi Joel, > > > > > > It is a little confusing for me. See inline. > > > > > >> -----Original Message----- > > >> From: i2rs [mailto:i2rs-bounces@ietf.org > ] On Behalf Of Joel M. > > >> Halpern > > >> Sent: Tuesday, January 14, 2014 11:43 PM > > >> To: KwangKoog Lee > > >> Cc: i2rs@ietf.org ; Guanxiaoran > > >> Subject: Re: [i2rs] Multi-Headed Control > > >> > > >> While I will try to paraphrase things to answer your question, I > > >> recommend you read the archtiecture draft to get more details. > > >> > > >> The assumption is that normally different I2RS clients will be > asking > > >> the agent to perform operations which change different pieces > of data. > > >> We discussed various models of conflict resolution for the > case when > > >> one client adjusts a piece of data, and then another client > goes to > > >> change that data. We decided that this was an error, and that we > > >> wanted a simple mechanism to decide what to do, while the clients > > >> sort > > out what was intended. > > > > > > Except for client priorities, there are other factors like > timing. I > > assume that a client with higher priority changes a piece of > data, but then a > > client with lower priority can make changes to the same piece of > data. It could > > possibly depend on the how long the client with higher priority > wants that > > change to take effect. > > > > > > But when two clients want to make changes to the same data at > the same > > time, then the client with higher priority will get the , > and the request > > from the client with lower priority will be denied. And we can > leave the choice > > on whether to make another try to the client itself. > > > > > > Regards! > > > -Haibin > > > > > >> Rather than > > >> pure FCFS, we decided to have client priorities. And that clients > > >> could arrange > > >> (easily) to be notified of changes to data they are interested in. > > >> > > >> The goal is to keep the mechanisms very lightweight, > particularly in > > >> order to support very high rates of operations. > > >> > > >> Yours, > > >> Joel > > >> > > >> On 1/14/14 10:29 AM, KwangKoog Lee wrote: > > >>> I do not fully understand the data model of i2rs. But in case > that > > >>> many clients interact forwarding devices with the i2rs-enabled > > >>> control plane, various policies about routing, signaling, qos and > > >>> etc. from multiple clients or multiple upper users (network > > >>> applications) can be set to those devices and to prevent or > > >>> negotiate some collision of multiple policies, such a machanism > > >>> might be necessary regardless of > > >> netconf? > > >>> Joel or anyone can explain more why it does not need? > Thanks in > > advance. > > >>> > > >>> best regards, > > >>> Kwang-koog Lee > > >>> On Tue, Jan 14, 2014 at 11:19 PM, Joel M. Halpern > > >>> > >> wrote: > > >>> > > >>> As I read the documents, locking is specifically not the > approach > > >>> I2RS is taking. So I think that "" does not > suffice to > > >>> resolve the I2RS needs, and is in fact not part of the > current I2RS > > >>> arhtiecture at all. > > >>> Yours, > > >>> Joel > > >>> On 1/14/14 4:17 AM, Guanxiaoran wrote: > > >>> > > >>> Hi, > > >>> I've a question about i2rs multi-headed control and > NETCONF. > > >>> [draft-ietf-i2rs-problem-__statement-00] > describes:"Additional > > >>> extensions to handle multi-headed control may need to be > > added > > >>> to NetConf and/or appropriate data models." > > >>> [draft-ietf-i2rs-architecture-__00] describes:"The > current > > >>> recommendation is to have a simple priority > associated with > > each > > >>> I2RS clients, and the highest priority change remains in > > effect." > > >>> As NETCONF has mechanism: "The operation > > allows > > >>> the client to lock the entire configuration data-store > > >>> system > > of > > >>> a device. Such locks are intended to be short-lived > and allow a > > >>> client to make a change without fear of interaction > with other > > >>> NETCONF clients, non-NETCONF clients (e.g., SNMP and > CLI), > > and > > >>> human users." > > >>> Do we still need to do the extensions, i.e. additional > > >>> extensions to handle multi-headed control added to > NETCONF? > > >>> Regards, > > >>> Ran > > >>> _________________________________________________ > > >>> i2rs mailing list > > >>> i2rs@ietf.org > > > >>> https://www.ietf.org/mailman/__listinfo/i2rs > > >>> > > >>> > > >>> _________________________________________________ > > >>> i2rs mailing list > > >>> i2rs@ietf.org > > > >>> https://www.ietf.org/mailman/__listinfo/i2rs > > >>> > > >>> > > >> _______________________________________________ > > >> i2rs mailing list > > >> i2rs@ietf.org > > >> https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > From shares@ndzh.com Fri Jan 17 15:45:57 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D261AD190 for ; Fri, 17 Jan 2014 15:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2qHWaDGntfc for ; Fri, 17 Jan 2014 15:45:54 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFEA1ACCF8 for ; Fri, 17 Jan 2014 15:45:54 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Songhaibin $A$'" , "'KwangKoog Lee'" References: <2C5AD5728DB9B24189E3A93140E45786366363@szxeml522-mbx.china.huawei.com> <52D54787.3070601@joelhalpern.com> <52D55B0F.6050407@joelhalpern.com> <52D60A5F.1000702@joelhalpern.com> <009901cf1315$4cf80f80$e6e82e80$@ndzh.com> <52D946DD.8020405@joelhalpern.com> In-Reply-To: <52D946DD.8020405@joelhalpern.com> Date: Fri, 17 Jan 2014 18:45:28 -0500 Message-ID: <01ad01cf13de$342aa070$9c7fe150$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG8g3xdmpHBvIQ6/gxMYigXG9S8DAKX9NfGAcsxnCQCWBnYpgGfwv0aAa8RgkECiaGu7AJL3jK6AVlauoSaLOblMA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: i2rs@ietf.org, 'Guanxiaoran' Subject: Re: [i2rs] Multi-Headed Control X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 23:45:58 -0000 Haibin: If Client A has the higher priority, does the reset to original value - mean that the I2rs client release the "write" permissions for user X's access bandwidth [no write permissions]? Or is it that Client "A" disconnects from the i2rs Agent? Answer to Joel's input: To expand on Joel's brief comment about WG agreement, Joel refers to the IETF '87 presentation with the WG (see below), email between August and November on list, and IETF '88 presentation. Alia (co-chair/author) and other co-authors are looking to put all these comments into the next draft. The draft probably be out before Chinese New Year - so I suspect you'll want to read sections 5 and 6 of the new draft carefully. ================= WG notes from IETF 87 http://tools.ietf.org/wg/i2rs/minutes Starts" draft-atlas-i2rs-architecture-01 (J. Halpern, 15') Joel H: I'm Joel Halpern. This is work a bunch of us did as a design team to propose an architecture for I2RS. -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Friday, January 17, 2014 10:06 AM To: Songhaibin (A); Susan Hares; 'KwangKoog Lee' Cc: i2rs@ietf.org; Guanxiaoran Subject: Re: [i2rs] Multi-Headed Control One thing to keep in mind. The WG has agreed to drop all time-based operations. Changes are applied when the order is given, and they remain until they are replaced / over-written (or the box resets). Changes do not have expieration times. Yours, Joel On 1/17/14 3:55 AM, Songhaibin (A) wrote: > Hi Sue, > > Thank you very much for so detailed explanation. I understand your two principles very clearly now. > > What comes into my mind is the following use case. Let's say it a bandwidth on demand scenario. Two clients A and B have different priorities to change user X's access bandwidth, and one client could be embedded in the user itself while another client is the system admin. Client A has higher priority. Then user X's access bandwidth is the piece of data. At time Y, Client A requests to change X's bandwidth to 20Mbps for two hours. And after two hours, X's bandwidth is reset to its default value. And after the time Y+2, either A or B should have the permission to change X's bandwidth data. > > I guess you probably have already considered this. > > Best Regards! > -Haibin > >> -----Original Message----- >> From: Susan Hares [mailto:shares@ndzh.com] >> Sent: Friday, January 17, 2014 7:47 AM >> To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee' >> Cc: i2rs@ietf.org; Guanxiaoran >> Subject: RE: [i2rs] Multi-Headed Control >> >> Mach, Haibin, and KwanKooq: >> >> Joel gave you brief answers and then suggested reading the document. >> As one of the co-authors, I will attempt to give the "longer" >> answers. I hope this will encourage discussion sections in the architecture document. >> >> This is not suggest current flaws in the architecture draft, but to >> elucidate (explain in depth) some of the drafts concepts. You may be >> asking questions that we hope will be discussed on the list, but I cannot tell yet. >> There are many sections in the architecture draft end with the phrase >> "Editor's >> note: This topic (or These topics) need more discussion in the working group." >> We encourage discussion of these drafts. >> >> If I am not answering the question, please just tell me. The >> important part of this work is to get an architecture and drafts that >> can be implemented in routers and switches. >> >> Ok.. enough introduction. On to a longer review that ends in a question: >> >> Review: >> --------- >> >> In section 1.2, page 6 (bottom) of the -00 version of the >> architecture draft, I >> states: >> >> " As can be seen in Figure 1, an I2RS client can communicate with >> multiple I2RS agents. An I2RS client may connect to one or more I2RS >> agents based upon its needs. Similarly, an I2RS agent may >> communicate with multiple I2RS clients - whether to respond to their >> requests, to send notifications, etc. Timely notifications are >> critical so that several simultaneously operating applications have >> up-to-date information on the state of the network." >> >> Note here that the architecture states you may have one agent talking >> to multiple I2RS clients. Once you enter this zone, you can have collisions. >> In the beginning , we talk and talked about ways that you could >> handle collisions - but we want to start simple. >> >> The phrase "protocol parsimony is clearly a goal" (section 3.1, p. 9) >> suggest we are trying to implement just a few things in the first >> version of I2RS Clients and I2RS Agents. From there, the I2RS protocol will be extended later. >> >> The simple rule for multi-headed control (section 6.8) is to consider >> that two clients manipulating the same piece of data is an error. For >> example, configuring an static route of prefix 192.1.1.0/24 should >> only be done by one client. If two I2RS clients try to change the >> same piece of data in the same I2RS Agent, it is an error. >> >> The architecture then requires that the I2RS clients and Agents have a >> decidable way for the Agent to resolve the error. Section 6.8 states our >> simple way: >> 1) assign each client a priority (either by policy or default policy) >> 2) If the priorities tie, the first client "whose attribution is >> associated with the data" keeps the control. >> >> That means - if you tie is First-come-keeps-control (FCKC) >> >> This is important to consider when you look at data models, scope (Section 2, p. >> 7-8), and identity. You will note that the RIB manager is the >> easiest thing to start with. Only one person can change one prefix, >> but multiple I2RS clients can add different prefixes to the list. >> >> Now, what if I2RS client A wants to add 10 prefixes to the RIB and >> this includes >> 192.1.1.0/24 to a single I2RS agent and I2RS client B wants to add >> 1 prefix 192.1.1.0/24. Does it cause a problem with I2RS client A if I24S >> Client B gets there first (FCKC), and only 9 prefixes get added. >> >> That very issue is what section 6.9 deals with. >> >> Questions: >> ----------- >> 1. Are you trying to determine what happens when the multi-headed >> control hits one of these errors? [See Sections 6.5, 6.6, 6.8 and >> 6.9] >> >> 2. Are you trying to build redundant clients (I2RS client A and I2RS >> Client >> A') which are redundant clients? [See section 6.4.1] >> >> 3. Are you concerned about multi-headed control with multiple >> interfaces per client? >> (You could have 4 SCTP and 4 TCP session over which this protocol >> runs) [Section 6.2] >> >> 4. How does a I2RS client A that reads the data know when I2RS Client >> B modifies the Data? >> [Section 6.8] >> >> Sue Hares >> >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. >> Halpern >> Sent: Tuesday, January 14, 2014 11:11 PM >> To: Songhaibin (A); KwangKoog Lee >> Cc: i2rs@ietf.org; Guanxiaoran >> Subject: Re: [i2rs] Multi-Headed Control >> >> There are no locks. >> The changes made by the higher priority client remain in effect until >> either they are removed by that client or an even higher priority >> client erroneously over-writes them. Changes do not have lifetimes. >> >> One of the points of this mechanism was to avoid needing to guess >> what order things happened in if they are close in time and you want to know the results. >> >> Please, read the draft. >> >> Yours, >> Joel >> >> On 1/14/14 10:50 PM, Songhaibin (A) wrote: >>> Hi Joel, >>> >>> It is a little confusing for me. See inline. >>> >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. >>>> Halpern >>>> Sent: Tuesday, January 14, 2014 11:43 PM >>>> To: KwangKoog Lee >>>> Cc: i2rs@ietf.org; Guanxiaoran >>>> Subject: Re: [i2rs] Multi-Headed Control >>>> >>>> While I will try to paraphrase things to answer your question, I >>>> recommend you read the archtiecture draft to get more details. >>>> >>>> The assumption is that normally different I2RS clients will be >>>> asking the agent to perform operations which change different pieces of data. >>>> We discussed various models of conflict resolution for the case >>>> when one client adjusts a piece of data, and then another client >>>> goes to change that data. We decided that this was an error, and >>>> that we wanted a simple mechanism to decide what to do, while the >>>> clients sort >> out what was intended. >>> >>> Except for client priorities, there are other factors like timing. I >> assume that a client with higher priority changes a piece of data, >> but then a client with lower priority can make changes to the same >> piece of data. It could possibly depend on the how long the client >> with higher priority wants that change to take effect. >>> >>> But when two clients want to make changes to the same data at the >>> same >> time, then the client with higher priority will get the , and >> the request from the client with lower priority will be denied. And >> we can leave the choice on whether to make another try to the client itself. >>> >>> Regards! >>> -Haibin >>> >>>> Rather than >>>> pure FCFS, we decided to have client priorities. And that clients >>>> could arrange >>>> (easily) to be notified of changes to data they are interested in. >>>> >>>> The goal is to keep the mechanisms very lightweight, particularly >>>> in order to support very high rates of operations. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 1/14/14 10:29 AM, KwangKoog Lee wrote: >>>>> I do not fully understand the data model of i2rs. But in case that >>>>> many clients interact forwarding devices with the i2rs-enabled >>>>> control plane, various policies about routing, signaling, qos and >>>>> etc. from multiple clients or multiple upper users (network >>>>> applications) can be set to those devices and to prevent or >>>>> negotiate some collision of multiple policies, such a machanism >>>>> might be necessary regardless of >>>> netconf? >>>>> Joel or anyone can explain more why it does not need? Thanks >>>>> in >> advance. >>>>> >>>>> best regards, >>>>> Kwang-koog Lee >>>>> On Tue, Jan 14, 2014 at 11:19 PM, Joel M. Halpern >>>>> > wrote: >>>>> >>>>> As I read the documents, locking is specifically not the approach >>>>> I2RS is taking. So I think that "" does not suffice to >>>>> resolve the I2RS needs, and is in fact not part of the current I2RS >>>>> arhtiecture at all. >>>>> Yours, >>>>> Joel >>>>> On 1/14/14 4:17 AM, Guanxiaoran wrote: >>>>> >>>>> Hi, >>>>> I've a question about i2rs multi-headed control and NETCONF. >>>>> [draft-ietf-i2rs-problem-__statement-00] describes:"Additional >>>>> extensions to handle multi-headed control may need to be >> added >>>>> to NetConf and/or appropriate data models." >>>>> [draft-ietf-i2rs-architecture-__00] describes:"The current >>>>> recommendation is to have a simple priority associated >>>>> with >> each >>>>> I2RS clients, and the highest priority change remains in >> effect." >>>>> As NETCONF has mechanism: "The operation >> allows >>>>> the client to lock the entire configuration data-store >>>>> system >> of >>>>> a device. Such locks are intended to be short-lived and allow a >>>>> client to make a change without fear of interaction with other >>>>> NETCONF clients, non-NETCONF clients (e.g., SNMP and >>>>> CLI), >> and >>>>> human users." >>>>> Do we still need to do the extensions, i.e. additional >>>>> extensions to handle multi-headed control added to NETCONF? >>>>> Regards, >>>>> Ran >>>>> _________________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/__listinfo/i2rs >>>>> >>>>> >>>>> _________________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/__listinfo/i2rs >>>>> >>>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From shares@ndzh.com Fri Jan 17 16:09:42 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34E1A8028 for ; Fri, 17 Jan 2014 16:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, NORMAL_HTTP_TO_IP=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSQufD_wr-mB for ; Fri, 17 Jan 2014 16:09:39 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CCDC91A1521 for ; Fri, 17 Jan 2014 16:09:38 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Joel M. Halpern'" , "'KwangKoog Lee'" , "'Songhaibin $A$'" References: <2C5AD5728DB9B24189E3A93140E45786366363@szxeml522-mbx.china.huawei.com> <52D54787.3070601@joelhalpern.com> <52D55B0F.6050407@joelhalpern.com> <52D60A5F.1000702@joelhalpern.com> <009901cf1315$4cf80f80$e6e82e80$@ndzh.com>

<52D947C9.7030605@joelhalpern.com> In-Reply-To: <52D947C9.7030605@joelhalpern.com> Date: Fri, 17 Jan 2014 19:09:15 -0500 Message-ID: <022701cf13e1$8657bce0$930736a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG8g3xdmpHBvIQ6/gxMYigXG9S8DAKX9NfGAcsxnCQCWBnYpgGfwv0aAa8RgkECiaGu7AJL3jK6Ajek1GACd2zdIZoSRGow Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: i2rs@ietf.org, 'Guanxiaoran' Subject: Re: [i2rs] Multi-Headed Control X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 00:09:42 -0000 KwangKoog: Joel did not answer: "In addition, for basic client redundancy, the architecture states active and backup network application can be used. At this point, I want to know both network applications are physically separated from the client?" The definitions in section 1.2 and 3.3 indicate that this is up to the implementation. Have we answered all your questions? Sue -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Friday, January 17, 2014 10:10 AM To: KwangKoog Lee; Songhaibin (A) Cc: Susan Hares; i2rs@ietf.org; Guanxiaoran Subject: Re: [i2rs] Multi-Headed Control As was discussed at the last meeting, The authors of the rfernando requirements draft will be making some changes to align with the working group agreed architecture. There are currently some minor (and I believe unintentional) discrepancies. And in the context of collision detection, "first" simply means the first client to change a piece of data. We hope folks do not rely on that mechanism, as it is unpredictable in outcome when changes are applied close together in time. That is why we have the priority scheme. Yours, Joel PS: Client archtiecture, application architecture, and client management are out of scope for this document. There are many ways they can be built, and we are not mandating an approach. On 1/17/14 4:15 AM, KwangKoog Lee wrote: > Dear Susan Hares, > > I deeply appreciate for your kind explanation about the multi-headed > control of I2RS so that I reviewed the architecture document again and > understood about the error-handling mechanism and the simplicity of I2RS > nature. Sorry for my poor understanding of I2RS. > > Regarding to your comments, I still have some questions to be more clear. > > First, as you explained and the architecture states, the manipulation of > the collision of multi-headed control can be processed by the assignment > of client priorities. > Rather, when the priority ties, the first client can keep the control. > At this point, the first client means the firstly connected client for > the controlling data or firstly connected client to the agent with that > data? > > Second, the statements of two documents, architecture > (draft-ietf-i2rs-architecture-00) and protocol > requirement(draft-rfernando-i2rs-protocol-requirements-00), seem to have > somewhat different views about the communication channel between client > and agent. In the architecture document, Sec 6.2 states the > communication channel between client and agent does not need to keep > continuous transport. But Sec 4.2 TR-12 of the protocol requirement > document states that keep-alives at transport level or I2RS protocol > level could be provided for detecting the session failure. And > simulataneous usage of session and communication channel of the > architecture document is confusing for me. > > Finally, I have a question about the network application and client for > client redundancy. I think client is not equal to network application. > The architecture document states in Sec 6.5 for handling dead clients > "the network applications or management systems will detect a dead > network application and either restart that network application or clean > up any state left behind." In addition, for basic client redundancy, the > architecture states active and backup network application can be used. > At this point, I want to know both network applications are physically > separated from the client? > > Thank you for your comments, again :-) > > best regards, > Kwang-koog Lee (KT) > > > > On Fri, Jan 17, 2014 at 5:55 PM, Songhaibin (A) > wrote: > > Hi Sue, > > Thank you very much for so detailed explanation. I understand your > two principles very clearly now. > > What comes into my mind is the following use case. Let's say it a > bandwidth on demand scenario. Two clients A and B have different > priorities to change user X's access bandwidth, and one client could > be embedded in the user itself while another client is the system > admin. Client A has higher priority. Then user X's access bandwidth > is the piece of data. At time Y, Client A requests to change X's > bandwidth to 20Mbps for two hours. And after two hours, X's > bandwidth is reset to its default value. And after the time Y+2, > either A or B should have the permission to change X's bandwidth data. > > I guess you probably have already considered this. > > Best Regards! > -Haibin > > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com ] > > Sent: Friday, January 17, 2014 7:47 AM > > To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee' > > Cc: i2rs@ietf.org ; Guanxiaoran > > Subject: RE: [i2rs] Multi-Headed Control > > > > Mach, Haibin, and KwanKooq: > > > > Joel gave you brief answers and then suggested reading the > document. As > > one of the co-authors, I will attempt to give the "longer" > answers. I hope this > > will encourage discussion sections in the architecture document. > > > > This is not suggest current flaws in the architecture draft, but > to elucidate > > (explain in depth) some of the drafts concepts. You may be > asking questions > > that we hope will be discussed on the list, but I cannot tell yet. > > There are many sections in the architecture draft end with the > phrase "Editor's > > note: This topic (or These topics) need more discussion in the > working group." > > We encourage discussion of these drafts. > > > > If I am not answering the question, please just tell me. The > important part of > > this work is to get an architecture and drafts that can be > implemented in > > routers and switches. > > > > Ok.. enough introduction. On to a longer review that ends in a > question: > > > > Review: > > --------- > > > > In section 1.2, page 6 (bottom) of the -00 version of the > architecture draft, I > > states: > > > > " As can be seen in Figure 1, an I2RS client can communicate with > > multiple I2RS agents. An I2RS client may connect to one or > more I2RS > > agents based upon its needs. Similarly, an I2RS agent may > > communicate with multiple I2RS clients - whether to respond to > their > > requests, to send notifications, etc. Timely notifications are > > critical so that several simultaneously operating applications > have > > up-to-date information on the state of the network." > > > > Note here that the architecture states you may have one agent > talking to > > multiple I2RS clients. Once you enter this zone, you can have > collisions. > > In the beginning , we talk and talked about ways that you could > handle > > collisions - but we want to start simple. > > > > The phrase "protocol parsimony is clearly a goal" (section 3.1, > p. 9) suggest we > > are trying to implement just a few things in the first version of > I2RS Clients and > > I2RS Agents. From there, the I2RS protocol will be extended later. > > > > The simple rule for multi-headed control (section 6.8) is to > consider that two > > clients manipulating the same piece of data is an error. For example, > > configuring an static route of prefix 192.1.1.0/24 > should only be done by one > > client. If two I2RS clients try to change the same piece of data > in the same > > I2RS Agent, it is an error. > > > > The architecture then requires that the I2RS clients and Agents > have a > > decidable way for the Agent to resolve the error. Section 6.8 > states our > > simple way: > > 1) assign each client a priority (either by policy or default policy) > > 2) If the priorities tie, the first client "whose attribution is > associated with the > > data" keeps the control. > > > > That means - if you tie is First-come-keeps-control (FCKC) > > > > This is important to consider when you look at data models, scope > (Section 2, p. > > 7-8), and identity. You will note that the RIB manager is the > easiest thing to > > start with. Only one person can change one prefix, but multiple > I2RS clients > > can add different prefixes to the list. > > > > Now, what if I2RS client A wants to add 10 prefixes to the RIB > and this includes > > 192.1.1.0/24 to a single I2RS agent and > I2RS client B wants to add > > 1 prefix 192.1.1.0/24 . Does it cause a > problem with I2RS client A if I24S > > Client B gets there first (FCKC), and only 9 prefixes get added. > > > > That very issue is what section 6.9 deals with. > > > > Questions: > > ----------- > > 1. Are you trying to determine what happens when the multi-headed > control > > hits one of these errors? [See Sections 6.5, 6.6, 6.8 and 6.9] > > > > 2. Are you trying to build redundant clients (I2RS client A and > I2RS Client > > A') which are redundant clients? [See section 6.4.1] > > > > 3. Are you concerned about multi-headed control with multiple > interfaces per > > client? > > (You could have 4 SCTP and 4 TCP session over which this > protocol runs) > > [Section 6.2] > > > > 4. How does a I2RS client A that reads the data know when I2RS > Client B > > modifies the Data? > > [Section 6.8] > > > > Sue Hares > > > > > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org > ] On Behalf Of Joel M. Halpern > > Sent: Tuesday, January 14, 2014 11:11 PM > > To: Songhaibin (A); KwangKoog Lee > > Cc: i2rs@ietf.org ; Guanxiaoran > > Subject: Re: [i2rs] Multi-Headed Control > > > > There are no locks. > > The changes made by the higher priority client remain in effect > until either they > > are removed by that client or an even higher priority client > erroneously > > over-writes them. Changes do not have lifetimes. > > > > One of the points of this mechanism was to avoid needing to guess > what order > > things happened in if they are close in time and you want to know > the results. > > > > Please, read the draft. > > > > Yours, > > Joel > > > > On 1/14/14 10:50 PM, Songhaibin (A) wrote: > > > Hi Joel, > > > > > > It is a little confusing for me. See inline. > > > > > >> -----Original Message----- > > >> From: i2rs [mailto:i2rs-bounces@ietf.org > ] On Behalf Of Joel M. > > >> Halpern > > >> Sent: Tuesday, January 14, 2014 11:43 PM > > >> To: KwangKoog Lee > > >> Cc: i2rs@ietf.org ; Guanxiaoran > > >> Subject: Re: [i2rs] Multi-Headed Control > > >> > > >> While I will try to paraphrase things to answer your question, I > > >> recommend you read the archtiecture draft to get more details. > > >> > > >> The assumption is that normally different I2RS clients will be > asking > > >> the agent to perform operations which change different pieces > of data. > > >> We discussed various models of conflict resolution for the > case when > > >> one client adjusts a piece of data, and then another client > goes to > > >> change that data. We decided that this was an error, and that we > > >> wanted a simple mechanism to decide what to do, while the clients > > >> sort > > out what was intended. > > > > > > Except for client priorities, there are other factors like > timing. I > > assume that a client with higher priority changes a piece of > data, but then a > > client with lower priority can make changes to the same piece of > data. It could > > possibly depend on the how long the client with higher priority > wants that > > change to take effect. > > > > > > But when two clients want to make changes to the same data at > the same > > time, then the client with higher priority will get the , > and the request > > from the client with lower priority will be denied. And we can > leave the choice > > on whether to make another try to the client itself. > > > > > > Regards! > > > -Haibin > > > > > >> Rather than > > >> pure FCFS, we decided to have client priorities. And that clients > > >> could arrange > > >> (easily) to be notified of changes to data they are interested in. > > >> > > >> The goal is to keep the mechanisms very lightweight, > particularly in > > >> order to support very high rates of operations. > > >> > > >> Yours, > > >> Joel > > >> > > >> On 1/14/14 10:29 AM, KwangKoog Lee wrote: > > >>> I do not fully understand the data model of i2rs. But in case > that > > >>> many clients interact forwarding devices with the i2rs-enabled > > >>> control plane, various policies about routing, signaling, qos and > > >>> etc. from multiple clients or multiple upper users (network > > >>> applications) can be set to those devices and to prevent or > > >>> negotiate some collision of multiple policies, such a machanism > > >>> might be necessary regardless of > > >> netconf? > > >>> Joel or anyone can explain more why it does not need? > Thanks in > > advance. > > >>> > > >>> best regards, > > >>> Kwang-koog Lee > > >>> On Tue, Jan 14, 2014 at 11:19 PM, Joel M. Halpern > > >>> > >> wrote: > > >>> > > >>> As I read the documents, locking is specifically not the > approach > > >>> I2RS is taking. So I think that "" does not > suffice to > > >>> resolve the I2RS needs, and is in fact not part of the > current I2RS > > >>> arhtiecture at all. > > >>> Yours, > > >>> Joel > > >>> On 1/14/14 4:17 AM, Guanxiaoran wrote: > > >>> > > >>> Hi, > > >>> I've a question about i2rs multi-headed control and > NETCONF. > > >>> [draft-ietf-i2rs-problem-__statement-00] > describes:"Additional > > >>> extensions to handle multi-headed control may need to be > > added > > >>> to NetConf and/or appropriate data models." > > >>> [draft-ietf-i2rs-architecture-__00] describes:"The > current > > >>> recommendation is to have a simple priority > associated with > > each > > >>> I2RS clients, and the highest priority change remains in > > effect." > > >>> As NETCONF has mechanism: "The operation > > allows > > >>> the client to lock the entire configuration data-store > > >>> system > > of > > >>> a device. Such locks are intended to be short-lived > and allow a > > >>> client to make a change without fear of interaction > with other > > >>> NETCONF clients, non-NETCONF clients (e.g., SNMP and > CLI), > > and > > >>> human users." > > >>> Do we still need to do the extensions, i.e. additional > > >>> extensions to handle multi-headed control added to > NETCONF? > > >>> Regards, > > >>> Ran > > >>> _________________________________________________ > > >>> i2rs mailing list > > >>> i2rs@ietf.org > > > >>> https://www.ietf.org/mailman/__listinfo/i2rs > > >>> > > >>> > > >>> _________________________________________________ > > >>> i2rs mailing list > > >>> i2rs@ietf.org > > > >>> https://www.ietf.org/mailman/__listinfo/i2rs > > >>> > > >>> > > >> _______________________________________________ > > >> i2rs mailing list > > >> i2rs@ietf.org > > >> https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > From ramk@Brocade.com Mon Jan 20 21:43:29 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BAC1A0296 for ; Mon, 20 Jan 2014 21:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8WfpK4_ZeXf for ; Mon, 20 Jan 2014 21:43:27 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 846FB1A0290 for ; Mon, 20 Jan 2014 21:43:27 -0800 (PST) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s0L5hRHJ015964; Mon, 20 Jan 2014 21:43:27 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1hgbdh0pv7-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jan 2014 21:43:27 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 20 Jan 2014 21:43:26 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Mon, 20 Jan 2014 21:43:25 -0800 From: ramki Krishnan To: "i2rs@ietf.org" Date: Mon, 20 Jan 2014 21:43:24 -0800 Thread-Topic: New Version Notification for draft-krishnan-i2rs-large-flow-use-case-01.txt Thread-Index: Ac8WSH9b9r8VY28MStSA+ftrHMjeWAAIpZPA Message-ID: References: <20140121013118.3737.29737.idtracker@ietfa.amsl.com> In-Reply-To: <20140121013118.3737.29737.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-20_03:2014-01-21,2014-01-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401200253 Cc: "draft-krishnan-i2rs-large-flow-use-case@tools.ietf.org" Subject: [i2rs] FW: New Version Notification for draft-krishnan-i2rs-large-flow-use-case-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 05:43:29 -0000 RGVhciBBbGwsDQoNCkJlc2lkZXMgbG9hZCBiYWxhbmNpbmcsIHdlIGhhdmUgYWRkZWQgYW4gYWRk aXRpb25hbCB1c2Ugb2YgY2FzZSBmb3IgRERvUyBhdHRhY2sgbWl0aWdhdGlvbiBpbiB0aGUgbGF0 ZXN0IGRyYWZ0LiBMb29raW5nIGZvcndhcmQgdG8geW91ciBjb21tZW50cy4NCg0KVGhhbmtzLA0K UmFta2kgb24gYmVoYWxmIG9mIHRoZSBjby1hdXRob3JzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDIwLCAyMDE0IDU6MzEgUE0N ClRvOiByYW1raSBLcmlzaG5hbjsgRGF2ZSBNY2R5c2FuOyBTcmlnYW5lc2ggS2luaTsgRGllZ28g Ui4gTG9wZXo7IFNyaWdhbmVzaCBLaW5pOyBEaWVnbyBMb3BlejsgQW5vb3AgR2hhbndhbmk7IHJh bWtpIEtyaXNobmFuOyBBbm9vcCBHaGFud2FuaTsgRGF2ZSBNY0R5c2FuDQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWtyaXNobmFuLWkycnMtbGFyZ2UtZmxvdy11 c2UtY2FzZS0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta3Jpc2huYW4t aTJycy1sYXJnZS1mbG93LXVzZS1jYXNlLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSByYW0gKHJhbWtpKSBrcmlzaG5hbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1rcmlzaG5hbi1pMnJzLWxhcmdlLWZsb3ctdXNlLWNh c2UNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlMYXJnZSBGbG93IFVzZSBDYXNlcyBmb3IgSTJSUyBQ QlIgYW5kIFFvUw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wMS0yMA0KR3JvdXA6CQlJbmRpdmlkdWFs IFN1Ym1pc3Npb24NClBhZ2VzOgkJMTINClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rcmlzaG5hbi1pMnJzLWxhcmdlLWZsb3ctdXNlLWNh c2UtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQta3Jpc2huYW4taTJycy1sYXJnZS1mbG93LXVzZS1jYXNlLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtyaXNobmFuLWkycnMtbGFyZ2Ut Zmxvdy11c2UtY2FzZS0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWtyaXNobmFuLWkycnMtbGFyZ2UtZmxvdy11c2UtY2FzZS0wMQ0KDQpB YnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgZGlzY3Vzc2VzIHR3byB1c2UgY2FzZXMgdG8gaGVscCBp ZGVudGlmeSB0aGUgcmVxdWlyZW1lbnRzDQogICBmb3IgcG9saWN5LWJhc2VkIHJvdXRpbmcgaW4g STJSUy4gIEJvdGggb2YgdGhlIHVzZSBjYXNlcyBpbnZvbHZlDQogICBpZGVudGlmaWNhdGlvbiBv ZiBjZXJ0YWluIGZsb3dzIGFuZCB0aGVuIHVzaW5nIEkyUlMgdG8gcHJvZ3JhbQ0KICAgc3BlY2lh bCBoYW5kbGluZyBmb3IgdGhvc2UgZmxvd3MuDQoNCiAgIFRoZSBmaXJzdCB1c2UgY2FzZSBkZWFs cyB3aXRoIGltcHJvdmluZyBiYW5kd2lkdGggZWZmaWNpZW5jeS4NCiAgIERlbWFuZHMgb24gbmV0 d29ya2luZyBiYW5kd2lkdGggYXJlIGdyb3dpbmcgZXhwb25lbnRpYWxseSBkdWUgdG8NCiAgIGFw cGxpY2F0aW9ucyBzdWNoIGFzIGxhcmdlIGZpbGUgdHJhbnNmZXJzIGFuZCB0aG9zZSB3aXRoIHJp Y2ggbWVkaWEuDQogICBMaW5rIEFnZ3JlZ2F0aW9uIEdyb3VwIChMQUcpIGFuZCBFcXVhbCBDb3N0 IE11bHRpcGF0aCAoRUNNUCkgYXJlDQogICBleHRlbnNpdmVseSBkZXBsb3llZCBpbiBuZXR3b3Jr cyB0byBzY2FsZSB0aGUgYmFuZHdpZHRoLiBIb3dldmVyLA0KICAgdGhlIGZsb3ctYmFzZWQgbG9h ZCBiYWxhbmNpbmcgdGVjaG5pcXVlcyB1c2VkIHRvZGF5IG1ha2UgaW5lZmZpY2llbnQNCiAgIHVz ZSBvZiB0aGUgYmFuZHdpZHRoIGluIHRoZSBwcmVzZW5jZSBvZiBsb25nLWxpdmVkIGxhcmdlIGZs b3dzLiBXZQ0KICAgZGlzY3VzcyBob3cgSTJSUyBjYW4gYmUgdXNlZCBmb3IgYWNoaWV2aW5nIGJl dHRlciBsb2FkIGJhbGFuY2luZy4NCg0KICAgVGhlIHNlY29uZCB1c2UgY2FzZSBpcyBmb3IgcmVj b2duaXppbmcgYW5kIG1pdGlnYXRpbmcgTGF5ZXIgMy00DQogICBiYXNlZCBERG9TIGF0dGFja3Mu IEJlaGF2aW9yYWwgc2VjdXJpdHkgdGhyZWF0cyBzdWNoIGFzIERpc3RyaWJ1dGVkDQogICBEZW5p YWwgb2YgU2VydmljZSAoRERvUykgYXR0YWNrcyBhcmUgYW4gb25nb2luZyBwcm9ibGVtIGluIHRv ZGF5J3MNCiAgIG5ldHdvcmtzLiBERG9TIGF0dGFja3MgY2FuIGJlIExheWVyIDMtNCBiYXNlZCBv ciBMYXllciA3IGJhc2VkLiBXZQ0KICAgZGlzY3VzcyBob3cgc3VjaCBhdHRhY2tzIGNhbiBiZSBy ZWNvZ25pemVkIGFuZCBob3cgSTJSUyBjYW4gYmUgdXNlZA0KICAgZm9yIG1pdGlnYXRpbmcgdGhl aXIgZWZmZWN0cy4NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From don.fedyk@hp.com Tue Jan 21 13:33:51 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3DD1A0391 for ; Tue, 21 Jan 2014 13:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.734 X-Spam-Level: X-Spam-Status: No, score=-4.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdC25Y-mvHH4 for ; Tue, 21 Jan 2014 13:33:47 -0800 (PST) Received: from g6t0185.atlanta.hp.com (g6t0185.atlanta.hp.com [15.193.32.62]) by ietfa.amsl.com (Postfix) with ESMTP id E6D191A0381 for ; Tue, 21 Jan 2014 13:33:46 -0800 (PST) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0185.atlanta.hp.com (Postfix) with ESMTPS id 8C0BA24008; Tue, 21 Jan 2014 21:33:46 +0000 (UTC) Received: from G6W3996.americas.hpqcorp.net (16.205.80.211) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 21 Jan 2014 21:32:09 +0000 Received: from G6W2492.americas.hpqcorp.net ([169.254.8.52]) by G6W3996.americas.hpqcorp.net ([16.205.80.211]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 21:32:10 +0000 From: "Fedyk, Don" To: Alia Atlas , Greg Mirsky Thread-Topic: [i2rs] TED extension in topology info model Thread-Index: AQHPDRvrPxWgkhuYaUWbpitEEv2JQJp8J8AAgAAE+4CAANVqAIAAAM0AgBK9/zA= Date: Tue, 21 Jan 2014 21:32:09 +0000 Message-ID: References: <527BBCAE.5050102@joelhalpern.com> <2C5AD5728DB9B24189E3A93140E45786365D49@szxeml522-mbx.china.huawei.com> <8596232233184709310@unknownmsgid> <23CE718903A838468A8B325B80962F9B52146A7E@szxeml556-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.193.49.27] Content-Type: multipart/alternative; boundary="_000_A46D9C092EA46F489F135060986AD9FFCB45D2G6W2492americashp_" MIME-Version: 1.0 Cc: "i2rs@ietf.org" , Guanxiaoran , Dhruv Dhody , Russell Harrison Subject: Re: [i2rs] TED extension in topology info model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:33:52 -0000 --_000_A46D9C092EA46F489F135060986AD9FFCB45D2G6W2492americashp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alia When I read through this thread I question data Model that is being descri= bed. If the model reports the TE parameters themselves then you have summaries o= f BW etc. And you know little about the true resource profile. But if the Model supports something like (forgive the pseudo syntax.) Object[RSVP-TE Session ID] Ingress Link[i/f ID], Label, egress Link[i/f ID= ], Label, BW 2 Mb Object[RSVP-TE Session ID] Ingress Link[i/f ID], Label, egress Link[i/f ID= ], Label, BW 5 Mb ... Then one could construct a much better model of TE parameters. The reason= we never did that for TE parameters was because Routing had to summarize i= n order to scale. Are we planning to limit the I2RS model this way too? O= r would this TE information be augmented with more detail by some other mea= ns? Thanks, Don From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas Sent: Thursday, January 09, 2014 6:00 PM To: Greg Mirsky Cc: i2rs@ietf.org; Russell Harrison; Dhruv Dhody; Guanxiaoran Subject: Re: [i2rs] TED extension in topology info model (WG chair hat off) For those not familiar, the proposed additional attributes are coming from draft-ietf-ospf-te-metric-extensions-05. It makes sense to me that the top= ology sub-models would include this type of information. Alia On Thu, Jan 9, 2014 at 5:57 PM, Greg Mirsky > wrote: Hi Dhruv, et al., I think that your explanation of Residiual BW and BW Utilization fields cle= arly indicates that these, as well as related to timing, are rather part of= Performance Measurement info and as such depends upon measuring instrument= s. For example, measuring Link Delay use active or passive method? If activ= e, what could be size of test packet? Variable or not? Though PM is very interesting subject, I believe that inclusion of dynamica= lly measured in-service performance parameters would only destabilize the t= opology while adding little value. I think that PM is more useful on Servic= e rather than Link level. Regards, Greg On Thu, Jan 9, 2014 at 2:13 AM, Dhruv Dhody > wrote: From: i2rs [mailto:i2rs-bounces@ietf.org] On = Behalf Of Russell Harrison Sent: 09 January 2014 15:26 To: Guanxiaoran Cc: i2rs@ietf.org Subject: Re: [i2rs] TED extension in topology info model Looks ok in concept, but there's a great deal of redundancy in the performa= nce info you describe. It seems that only one of the residual/available/uti= lized fields would be needed. [DD] Hmmm I disagree. All 3 fields maybe used as they have subtle differences. Residual BW =3D Maximum Bandwidth minus the bandwidth currently *allocated= * to RSVP-TE LSPs. Available BW =3D Residual bandwidth minus the measured bandwidth *used* for= the actual forwarding of non-RSVP-TE LSP packets. BW Utilization =3D the actual utilization of the link (i.e.: as measured in= the router including both RSVP and non-RSVP) The other two could be calculated (not to mention, in this context residual= and available probably mean he same thing. [DD] "residual and available" are different, as above! THe delay and loss fields are also interesting, assuming good methods to me= asure same are in place... -rh Sent from my iPhone On Jan 9, 2014, at 3:19 AM, Guanxiaoran > wrote: Hi , [draft-medved-i2rs-topology-im-01] defines a TED (Traffic Engineering Data)= component ([RFC5305], [RFC3630]): ::=3D (...) [] Besides the factors proposed in that document, other factors such as latenc= y, limited bandwidth, packet loss, and jitter ([draft-ietf-isis-te-metric-e= xtensions-01], [draft-ietf-ospf-te-metric-extensions-05], [draft-wu-idr-te-= pm-bgp-03]), are all important that need to be taken into account in the to= pology info model. For example, shall we extend the TED component (i.e. including network perf= ormance information ) as follows: ::=3D (...) [] ::=3D What do you think? [DD] Maybe we should have - [] making it optional? Regards, Dhruv Regards, Ran _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_A46D9C092EA46F489F135060986AD9FFCB45D2G6W2492americashp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alia=

<= /p>

When I read through = this thread I question data Model that is being described.

<= /p>

If the model reports the = TE parameters themselves then you have summaries of BW etc. And you k= now little about the true resource profile.

<= /p>

But if the Model supports= something like (forgive the pseudo syntax.)

Object[RSVP-TE Session ID= ] Ingress Link[i/f ID], Label, egress Link[i/f ID], Label, BW 2 Mb

Object[RSVP-TE Session ID= ] Ingress Link[i/f ID], Label, egress Link[i/f ID], Label, BW 5 Mb

…=

<= /p>

Then one could construct = a much better model of TE parameters. The reason we never did t= hat for TE parameters was because Routing had to summarize in order to scale. Are we planning to limit the I2RS model this way too= ? Or would this TE information be augmented with more detail by some other = means?

<= /p>

Thanks,
Don

<= /p>

From: i2rs [ma= ilto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, January 09, 2014 6:00 PM
To: Greg Mirsky
Cc: i2rs@ietf.org; Russell Harrison; Dhruv Dhody; Guanxiaoran
Subject: Re: [i2rs] TED extension in topology info model<= /span>

(WG chair hat off)

For those not familiar, the proposed additional attr= ibutes are coming from

draft-ietf-ospf-te-metric-extensions-05. It ma= kes sense to me that the topology sub-models would include this type of inf= ormation.

Alia

On Thu, Jan 9, 2014 at 5:57 PM, Greg Mirsky <gregimirsky@gmail.co= m> wrote:

Hi Dhruv, et al.,

I think that your exp= lanation of Residiual BW and BW Utilization fields clearly indicates that t= hese, as well as related to timing, are rather part of Performance Measurem= ent info and as such depends upon measuring instruments. For example, measuring Link Delay use active or passive metho= d? If active, what could be size of test packet? Variable or not?

Though PM is very interesting subject, I believe tha= t inclusion of dynamically measured in-service performance parameters would= only destabilize the topology while adding little value. I think that PM i= s more useful on Service rather than Link level.

Regards,

Greg

On Thu, Jan 9, 2014 at 2:13 AM, Dhruv Dhody <dhruv.dhody@huawei.= com> wrote:

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russell Harrison
Sent: 09 January 2014 15:26
To: Guanxiaoran
Cc: i2rs@ietf.org=
Subject: Re: [i2rs] TED extension in topology info model=

Looks ok in concept, but there's a great deal of redundancy in the= performance info you describe. It seems that only one of the residual/avai= lable/utilized fields would be needed.

[DD] Hmmm I disagree.

All 3 fields maybe used as they h= ave subtle differences.

<= /p>

Residual BW =3D Maximum Ban= dwidth minus the bandwidth currently *allocated* to RSVP-TE LSPs.

Available BW =3D Residual bandwid= th minus the measured bandwidth *used* for the actual forwarding of non-RSVP-TE LSP packets.

BW Utilization =3D the actual uti= lization of the link (i.e.: as measured in the router including both RSVP and non-RSVP)

<= /p>
The other two could be calculated (not to mention, in this context= residual and available probably mean he same thing.

[DD] “residu= al and available” are different, as above!

THe delay and loss fields are also interesting, assuming good meth= ods to measure same are in place...

-rh

Sent from my iPhone

On Jan 9, 2014, at 3:19 AM, Guanxiaoran <guanxiaoran@huawei.com> wrote:<= /o:p>

Hi ,

[draft-medved-i2rs-topology-im-01] defines a TED= (Traffic Engineering Data) component ([RFC5305], [RFC3630]):

<ted-link> ::=3D <COLOR>=

        =              &l= t;MAX_LINK_BANDWIDTH>

        =              &l= t;MAX_RESV_LINK_BANDWIDTH>

        =              (&= lt;UNRESERVED_BANDWIDTH>...)

        =              &l= t;TE_DEFAULT_METRIC>

        =              [&= lt;srlg-attributes>]

Besides the factors proposed in that document, o= ther factors such as latency, limited bandwidth, packet loss, and jitter ([= draft-ietf-isis-te-metric-extensions-01], [draft-ietf-ospf-te-metric-extens= ions-05], [draft-wu-idr-te-pm-bgp-03]), are all important that need to be taken into= account in the topology info model.

For example, shall we extend the TED component (= i.e. including network performance information ) as follows:

<ted-link> ::=3D <COLOR>=

        =              &l= t;MAX_LINK_BANDWIDTH>

        =              &l= t;MAX_RESV_LINK_BANDWIDTH>

        =              (&= lt;UNRESERVED_BANDWIDTH>...)

        =              &l= t;TE_DEFAULT_METRIC>

<TE_Performance_Info>

         = ;            [&= lt;srlg-attributes>]

<TE_Performance_Info> ::=3D <Unidirectional= Link Delay>

        &nbs= p;            &= nbsp;            &nb= sp;            =     <Min/Max Unidirectional Link Delay>

        &nbs= p;            &= nbsp;            &nb= sp;            =     <Unidirectional Delay Variation><= /o:p>

        &nbs= p;            &= nbsp;            &nb= sp;            =     <Unidirectional Packet Loss>

        &nbs= p;            &= nbsp;            &nb= sp;            =     <Unidirectional Residual Bandwidth>

        &nbs= p;            &= nbsp;            &nb= sp;            =     <Unidirectional Available Bandwidth>

<Unidirectional Utilized Bandwidth>

What do you think?

[DD] Maybe we should have - = ;[<TE_Performance_Info>] making it optional?

<= /p>
Regards,

Dhruv
<= /p>

Regards,

Ran

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--_000_A46D9C092EA46F489F135060986AD9FFCB45D2G6W2492americashp_-- From akatlas@gmail.com Tue Jan 21 13:43:46 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E261A01CA for ; Tue, 21 Jan 2014 13:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M4zZOXBRwMi for ; Tue, 21 Jan 2014 13:43:43 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8847B1A01D3 for ; Tue, 21 Jan 2014 13:43:43 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id ar20so5925453iec.34 for ; Tue, 21 Jan 2014 13:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aQ61PwcVPQitWFZ43/88JV5ShwWGml2U9X0NkxoUjHY=; b=VWnlwIdcq85tytGrZ38d0/VtePahhsx6fLQgfP5hmurjNE6imEKGj7zSSS8vEmk8PP uyRTPRnDeNjmTdwwiLlYz3uBFRUzjCCT73nwgJzSeg7mguqLKpvw3x28C3hIbNEGsms5 f+R+D9oMWwzME2EhCrUHojBf023uMYhhigXKZCyT0vn1z6ycOLQEc90GKN/QJdLAq30s FqqaiFk2+trzwHIw2+o3aPp2nz3eE8r+I7tK4TTbu1muuQ/furJE2l14sr/x4japby9h ceHDqGDgjR9xFz1Iurrdir+Ujr0//gBFLF1N/bRiTCN0eMc9UUcrcBSOiyndRc7fy7qe P7GQ== MIME-Version: 1.0 X-Received: by 10.43.57.146 with SMTP id wg18mr11819882icb.42.1390340623196; Tue, 21 Jan 2014 13:43:43 -0800 (PST) Received: by 10.64.72.132 with HTTP; Tue, 21 Jan 2014 13:43:43 -0800 (PST) In-Reply-To: References: <527BBCAE.5050102@joelhalpern.com> <2C5AD5728DB9B24189E3A93140E45786365D49@szxeml522-mbx.china.huawei.com> <8596232233184709310@unknownmsgid> <23CE718903A838468A8B325B80962F9B52146A7E@szxeml556-mbs.china.huawei.com> Date: Tue, 21 Jan 2014 16:43:43 -0500 Message-ID: From: Alia Atlas To: "Fedyk, Don" Content-Type: multipart/alternative; boundary=bcaec51a8b04f6660b04f081e6ba Cc: Greg Mirsky , Guanxiaoran , Russell Harrison , Dhruv Dhody , "i2rs@ietf.org" Subject: Re: [i2rs] TED extension in topology info model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:43:46 -0000 --bcaec51a8b04f6660b04f081e6ba Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Don, On Tue, Jan 21, 2014 at 4:32 PM, Fedyk, Don wrote: > Hi Alia > > > > When I read through this thread I question data Model that is being > described. > > > > If the model reports the TE parameters themselves then you have summaries > of BW etc. And you know little about the true resource profile. > > > > But if the Model supports something like (forgive the pseudo syntax.) > > Object[RSVP-TE Session ID] Ingress Link[i/f ID], Label, egress Link[i/f > ID], Label, BW 2 Mb > > Object[RSVP-TE Session ID] Ingress Link[i/f ID], Label, egress Link[i/f > ID], Label, BW 5 Mb > > =85 > > > > Then one could construct a much better model of TE parameters. The > reason we never did that for TE parameters was because Routing had to > summarize in order to scale. Are we planning to limit the I2RS model th= is > way too? Or would this TE information be augmented with more detail by so= me > other means? > > Good question! In the context of the information model for topology produced via ISIS, OSPF, or BGP-LS, I2RS can't really provide more information than the underlying protocol has. In general, in the architecture (new draft version in progress), the idea of a "service" and associated information model for RSVP-TE is there. In that context, I can certainly see the above being useful to provide. We don't have anyone volunteering yet (that I know of) to write down some ideas for the RSVP-TE information model... Regards, Alia > > > Thanks, > Don > > > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Alia Atlas > *Sent:* Thursday, January 09, 2014 6:00 PM > *To:* Greg Mirsky > *Cc:* i2rs@ietf.org; Russell Harrison; Dhruv Dhody; Guanxiaoran > > *Subject:* Re: [i2rs] TED extension in topology info model > > > > (WG chair hat off) > > > > For those not familiar, the proposed additional attributes are coming fro= m > > draft-ietf-ospf-te-metric-extensions-05. It makes sense to me that the > topology sub-models would include this type of information. > > > > Alia > > > > On Thu, Jan 9, 2014 at 5:57 PM, Greg Mirsky wrote= : > > Hi Dhruv, et al., > > I think that your explanation of Residiual BW and BW Utilization fields > clearly indicates that these, as well as related to timing, are rather pa= rt > of Performance Measurement info and as such depends upon measuring > instruments. For example, measuring Link Delay use active or passive > method? If active, what could be size of test packet? Variable or not? > > Though PM is very interesting subject, I believe that inclusion of > dynamically measured in-service performance parameters would only > destabilize the topology while adding little value. I think that PM is mo= re > useful on Service rather than Link level. > > > > Regards, > > Greg > > > > On Thu, Jan 9, 2014 at 2:13 AM, Dhruv Dhody > wrote: > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Russell > Harrison > *Sent:* 09 January 2014 15:26 > *To:* Guanxiaoran > *Cc:* i2rs@ietf.org > *Subject:* Re: [i2rs] TED extension in topology info model > > > > Looks ok in concept, but there's a great deal of redundancy in the > performance info you describe. It seems that only one of the > residual/available/utilized fields would be needed. > > *[DD] Hmmm I disagree. * > > *All 3 fields maybe used as they have subtle differences. * > > > > *Residual BW =3D Maximum Bandwidth minus the bandwidth currently > *allocated* to RSVP-TE LSPs.* > > *Available BW =3D Residual bandwidth minus the measured bandwidth *used* = for > the actual forwarding of non-RSVP-TE LSP packets. * > > *BW Utilization =3D the actual utilization of the link (i.e.: as measured= in > the router including both RSVP and non-RSVP)* > > > > The other two could be calculated (not to mention, in this context > residual and available probably mean he same thing. > > *[DD] =93*residual and available*=94 are different, as above! * > > > > THe delay and loss fields are also interesting, assuming good methods to > measure same are in place... > > > > -rh > > > Sent from my iPhone > > On Jan 9, 2014, at 3:19 AM, Guanxiaoran wrote: > > Hi , > > > > [draft-medved-i2rs-topology-im-01] defines a TED (Traffic Engineering > Data) component ([RFC5305], [RFC3630]): > > ::=3D > > > > > > (...) > > > > [] > > > > Besides the factors proposed in that document, other factors such as > latency, limited bandwidth, packet loss, and jitter > ([draft-ietf-isis-te-metric-extensions-01], > [draft-ietf-ospf-te-metric-extensions-05], [draft-wu-idr-te-pm-bgp-03]), > are all important that need to be taken into account in the topology info > model. > > > > For example, shall we extend the TED component (i.e. including network > performance information ) as follows: > > ::=3D > > > > > > (...) > > > > > > [] > > > > ::=3D > > Link Delay> > > Variation> > > Loss> > > Residual Bandwidth> > > Available Bandwidth> > > > > > > What do you think? > > *[DD] Maybe we should have - [] making it optional?= * > > > > *Regards,* > > *Dhruv* > > > > > > Regards, > > Ran > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > --bcaec51a8b04f6660b04f081e6ba Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Don,

On Tue, Jan 21, 2014 at 4:32 PM, Fedyk, Don <don.fedyk@hp.com>= ; wrote:

Hi Alia

=A0<= /p>
When I read through=A0 th= is thread I question data Model that is being described.

=A0<= /p>
If the model reports the = TE parameters themselves then you have summaries of BW etc. =A0And you know= little about the true resource profile. =A0

=A0<= /p>
But if the Model supports= =A0something like (forgive the pseudo syntax.)

Object[RSVP-TE Session ID= ] Ingress Link[i/f ID], Label, =A0egress Link[i/f ID], Label, BW 2 Mb

Object[RSVP-TE Session ID= ] Ingress Link[i/f ID], Label, =A0egress Link[i/f ID], Label, BW 5 Mb

=85<= /p>
=A0<= /p>
Then one could construct = a much better model of TE parameters.=A0=A0 The reason we never did that fo= r TE parameters was because Routing had to summarize in order to scale.=A0=A0 Are we planning to limit the I2RS model this way too? Or w= ould this TE information be augmented with more detail by some other means?

<= /div>

Good question! =A0In the context of t= he information model for topology produced via ISIS, OSPF, or BGP-LS, I2RS = can't really provide more information than the underlying protocol has.=

In general, in the architecture (new draft version in p= rogress), the idea of a "service" and associated information mode= l for RSVP-TE is there. =A0In that context, I can certainly see the above b= eing useful to provide. =A0We don't have anyone volunteering yet (that = I know of) to write down some ideas for the RSVP-TE information model...

Regards,
Alia

=A0

=A0
Thanks,
Don

=A0<= /p>
=A0<= /p>
From: i2rs [ma= ilto:i2rs-bounce= s@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, January 09, 2014 6:00 PM
To: Greg Mirsky
Cc: i2rs@ietf.org= ; Russell Harrison; Dhruv Dhody; Guanxiaoran

Subject: Re: [i2rs] TED extension in topology info model

=A0

(WG chair hat off)

=A0

For those not familiar, the proposed additional attr= ibutes are coming from

draft-ietf-ospf-te-metric-extensions-05. =A0It makes= sense to me that the topology sub-models would include this type of inform= ation.

=A0

Alia

=A0

On Thu, Jan 9, 2014 at 5:57 PM, Greg Mirsky <gregimirsky@gmail.co= m> wrote:

Hi Dhruv, et al.,

I think that your exp= lanation of Residiual BW and BW Utilization fields clearly indicates that t= hese, as well as related to timing, are rather part of Performance Measurem= ent info and as such depends upon measuring instruments. For example, measuring Link Delay use active or passive metho= d? If active, what could be size of test packet? Variable or not?=

Though PM is very interesting subject, I believe tha= t inclusion of dynamically measured in-service performance parameters would= only destabilize the topology while adding little value. I think that PM i= s more useful on Service rather than Link level.

=A0

Regards,

Greg

=A0

On Thu, Jan 9, 2014 at 2:13 AM, Dhruv Dhody <dhruv.dhody@huawei.= com> wrote:

From: i2rs [ma= ilto:i2rs-bounce= s@ietf.org] On Behalf Of Russell Harrison
Sent: 09 January 2014 15:26
To: Guanxiaoran
Cc: i2rs@ietf.org=
Subject: Re: [i2rs] TED extension in topology info model

=A0

Looks ok in concept, but there's a great deal of= redundancy in the performance info you describe. It seems that only one of= the residual/available/utilized fields would be needed.

[DD] Hmmm I disagre= e.

All 3 fields maybe = used as they have subtle differences.

=A0<= u>

Residual BW =3D =A0= Maximum Bandwidth minus the bandwidth currently *allocated* to RSVP-TE LSPs= .

Available BW =3D Re= sidual bandwidth minus the measured bandwidth *used* for the actual forward= ing of non-RSVP-TE LSP packets.

BW Utilization =3D = the actual utilization of the link (i.e.: as measured in the router includi= ng both RSVP and non-RSVP)

=A0<= u>

The other two could be calculated (not to mention, i= n this context residual and available probably mean he same thing.

[DD] =93= residual and available=94 are different, as above!

=A0

THe delay and loss fields are also interesting, assu= ming good methods to measure same are in place...

=A0

-rh

Sent from my iPhone

On Jan 9, 2014, at 3:= 19 AM, Guanxiaoran <guanxiaoran@huawei.com> wrote:

Hi ,

=A0

[draft-medved-i2rs-topology-im-01] defines a TED= (Traffic Engineering Data) component ([RFC5305], [RFC3630]):

<ted-link> ::=3D <COLOR>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 <MAX_LINK_BANDWIDTH>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 <MAX_RESV_LINK_BANDWIDTH>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 (<UNRESERVED_BANDWIDTH>...)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 <TE_DEFAULT_METRIC>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0= =A0=A0=A0=A0=A0[<srlg-attributes>]

=A0

Besides the factors proposed in that document, o= ther factors such as latency, limited bandwidth, packet loss, and jitter ([= draft-ietf-isis-te-metric-extensions-01], [draft-ietf-ospf-te-metric-extens= ions-05], [draft-wu-idr-te-pm-bgp-03]), are all important that need to be taken into= account in the topology info model.

=A0

For example, shall we extend the TED component (= i.e. including network performance information ) as follows:<= u>

<ted-link> ::=3D <COLOR>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 <MAX_LINK_BANDWIDTH>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 <MAX_RESV_LINK_BANDWIDTH>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 (<UNRESERVED_BANDWIDTH>...)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 <TE_DEFAULT_METRIC>

<TE_Performance_Info>

=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0[<srlg-attributes>]

=A0

<TE_Performance_Info> ::=3D <Unidirectional= Link Delay>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0<Min/Max Unidirectional Link Delay>=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0<Unidirectional Delay Variation>=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0<Unidirectional Packet Loss>=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0<Unidirectional Residual Bandwidth>=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0<Unidirectional Available Bandwidth>

<Unidirectional Utilized Bandwidth><= /u>

=A0<= /p>
What do you think?=

[DD] Maybe we shoul= d have - =A0[<TE_Performance_Info>] making it optional?
=A0<= u>

Regards,=

Dhruv
=A0<= u>

=A0<= /p>
Regards,=

Ran<= /p>

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

=A0

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

=A0

--bcaec51a8b04f6660b04f081e6ba-- From akatlas@gmail.com Tue Jan 28 14:58:08 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06BE1A02DC for ; Tue, 28 Jan 2014 14:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgjWTYU3QCFj for ; Tue, 28 Jan 2014 14:58:07 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EAE6D1A026E for ; Tue, 28 Jan 2014 14:58:06 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id e14so1293603iej.4 for ; Tue, 28 Jan 2014 14:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NLENpdYK0hMPWchhhrIxHxn6NsTYobA+BHwxsV0v6zU=; b=F0qR9gUe6HbsQElh5f/x87x/fUzR2mlDo8Z8oAbByXHPtZDjx7RTg8+UWGDKfBfRbY nHHpPATDhKFu0ILDQU+XoumUhq0MmFEYelhBVo8zg0arq1jqCjYKqpRrQdhE38lOPe06 JhU/vbTzWcoxeMXlFSdzD9O1rMU1bH67JXmehOP3L7AcouY+MSa/KncoPvjI5wbS0ohr a1eTbjyWPHRJy2WcvteFeUsSgZVb4dJ3bJkVYRpSoW6fqQbb5TLsvMOe2n8Ove/xKdfo SExBQgVUe3cwgBU2+3EdrXOjMwgZbSlqoM9RPd9R0d8QkQgNnLlax/DoWnzIZy1L+oz9 BjvQ== MIME-Version: 1.0 X-Received: by 10.50.225.67 with SMTP id ri3mr25789709igc.16.1390949884257; Tue, 28 Jan 2014 14:58:04 -0800 (PST) Received: by 10.65.14.198 with HTTP; Tue, 28 Jan 2014 14:58:04 -0800 (PST) Date: Tue, 28 Jan 2014 17:58:04 -0500 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=001a1132edfec0e31904f10fc18b Subject: [i2rs] use-cases - discussion please X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 22:58:08 -0000 --001a1132edfec0e31904f10fc18b Content-Type: text/plain; charset=ISO-8859-1 If you were to look at our charter, unsurprisingly we have use-cases to be completed before information models. I would strongly encourage discussion of the use-case drafts and serious work on turning them into something that the working group could accept. I've certainly heard the concerns that we haven't picked a data-modeling language or protocol yet - and that I2RS may be going too slowly for various open-source projects. The speed the working group goes is up to each of you! We can't really ask for a recharter to include data models or anything else until we get the basics off our plate. Just a reminder of our original Goals and Milestones below: Goals and Milestones: Jul 2013 - Request publication of an Informational document defining the problem statement Jul 2013 - Request publication of an Informational document defining the high-level architecture Aug 2013 - Request publication of Informational documents describing use cases Sep 2013 - Request publication of an Informational document defining the protocol requirements Sep 2013 - Request publication of an Informational document defining encoding language requirements Feb 2014 - Request publication of Standards Track documents specifying information models Feb 2014 - Request publication of an Informational document providing an analysis of existing IETF and other protocols and encoding languages against the requirements Feb 2014 - Consider re-chartering Regards, Alia --001a1132edfec0e31904f10fc18b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If you were to look at our charter, unsurprisingly we have= use-cases to be completed before information models. =A0I would strongly e= ncourage discussion of the use-case drafts and serious work on turning them= into something that the working group could accept.

I've certainly heard the concerns that we haven't pi= cked a data-modeling language or protocol yet - and that I2RS may be going = too slowly for various open-source projects.

The s= peed the working group goes is up to each of you! =A0 We can't really a= sk for a recharter to include data models or anything else until we get the= basics off our plate.

Just a reminder of our original Goals and Milestones be= low:

Goals and Milestones:
=A0 Jul 2013 - Request publ= ication of an Informational document defining the problem statement
=A0 = Jul 2013 - Request publication of an Informational document defining the hi= gh-level architecture
=A0 Aug 2013 - Request publication of Informational documents describing us= e cases
=A0 Sep 2013 - Request publication of an Informational document = defining the protocol requirements
=A0 Sep 2013 - Request publication of= an Informational document defining encoding language requirements
=A0 Feb 2014 - Request publication of Standards Track documents specifying = information models
=A0 Feb 2014 - Request publication of an Informationa= l document providing an analysis of existing IETF and other protocols and e= ncoding languages against the requirements
=A0 Feb 2014 - Consider re-chartering

Regards,
Alia
--001a1132edfec0e31904f10fc18b-- From kwangkooglee@gmail.com Wed Jan 29 05:13:27 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CC41A0246 for ; Wed, 29 Jan 2014 05:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWS13gCJfNyP for ; Wed, 29 Jan 2014 05:13:22 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCA01A020C for ; Wed, 29 Jan 2014 05:13:21 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id l18so3409062wgh.23 for ; Wed, 29 Jan 2014 05:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qlL5aqyQg7mF0byDFFuwQUH4SKWywZdgxV0XM97wYWc=; b=VJg3jchqox1/SLR+b+F+a71e09oZcCZfJDZYlJToBjfgoNcY/p820e4ThhrgPEClPJ ijf/RfBdqQmA4qb8RJbPdZdJeUUSainb987HLEZqZk/rzgs0K+QQdARvqxpR0Dka07Yr ZZtCcJhRNFhQhGwkUZ7sK9+GHr2Vi7QvbeuNWNua7hprHMClwO7RjqrGFewMCoD/w7fA kBpBgg/ZS3f0hpPmQwFDqZW7jfDHaweze9cL1VKZJR0mXchgIylkgPHrwU8KrF/niIQk fDM5/weJ+BTvc3XQYp++zvuaNI4VFW1Ilf5tQYuXYILrQG+U1iT0qt5A53AGP8COsa8z DI2Q== MIME-Version: 1.0 X-Received: by 10.194.71.116 with SMTP id t20mr1423053wju.51.1391001198289; Wed, 29 Jan 2014 05:13:18 -0800 (PST) Received: by 10.194.94.169 with HTTP; Wed, 29 Jan 2014 05:13:18 -0800 (PST) In-Reply-To: <022701cf13e1$8657bce0$930736a0$@ndzh.com> References: <2C5AD5728DB9B24189E3A93140E45786366363@szxeml522-mbx.china.huawei.com> <52D54787.3070601@joelhalpern.com> <52D55B0F.6050407@joelhalpern.com> <52D60A5F.1000702@joelhalpern.com> <009901cf1315$4cf80f80$e6e82e80$@ndzh.com> <52D947C9.7030605@joelhalpern.com> <022701cf13e1$8657bce0$930736a0$@ndzh.com> Date: Wed, 29 Jan 2014 22:13:18 +0900 Message-ID: From: KwangKoog Lee To: Susan Hares Content-Type: multipart/alternative; boundary=047d7bfcec644e68be04f11bb42f Cc: "i2rs@ietf.org" , "Songhaibin $A$" , "Joel M. Halpern" , Guanxiaoran Subject: Re: [i2rs] Multi-Headed Control X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 13:13:27 -0000 --047d7bfcec644e68be04f11bb42f Content-Type: text/plain; charset=ISO-8859-1 Sorry for my late response. I've understood the detailed mechanisms about the multi-headed control of I2RS through review of architecture document and authors' detailed comments. Thank you, again. Many curiocities are solved but I have more questions about the congestion control. As stated in Sec. 6.1 of the architecture document, I think a congestion control mechanism of the I2RS transport is also related to the multi-headed control. As Joel explained, the priority information each client has can simply solve a congestion situation in an agent. Sec. 6.1 covers a congestion in a client as well as an agent. The probability of the congestion in a client is generally higher than the agent case. Like the client case, each agent can have any priority? Or, I2RS messages from agents can additionally have priority? I think as the architecture distinguishes "notifications (in Sec. 6.6)" and "information collection (in Sec. 6.7)" the notification message's priority is generally higher than the priority of information collection message because the former has important and urgent information like interface failure that may affect the next control of the underlying networks. If does, more detailed matters are needed to mention in the architecture document. I think it can help alleviate concerning of scalability and reliabilty for service providers considering SDN(I2RS)-enabled routing networks. best regards, Kwang-koog Lee (KT) On Sat, Jan 18, 2014 at 9:09 AM, Susan Hares wrote: > KwangKoog: > > Joel did not answer: "In addition, for basic client redundancy, the > architecture states active and backup network application can be used. At > this point, I want to know both network applications are physically > separated from the client?" > > The definitions in section 1.2 and 3.3 indicate that this is up to the > implementation. > > Have we answered all your questions? > > Sue > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Friday, January 17, 2014 10:10 AM > To: KwangKoog Lee; Songhaibin (A) > Cc: Susan Hares; i2rs@ietf.org; Guanxiaoran > Subject: Re: [i2rs] Multi-Headed Control > > As was discussed at the last meeting, The authors of the rfernando > requirements draft will be making some changes to align with the working > group agreed architecture. There are currently some minor (and I > believe unintentional) discrepancies. > > And in the context of collision detection, "first" simply means the > first client to change a piece of data. We hope folks do not rely on > that mechanism, as it is unpredictable in outcome when changes are > applied close together in time. That is why we have the priority scheme. > > Yours, > Joel > > PS: Client archtiecture, application architecture, and client management > are out of scope for this document. There are many ways they can be > built, and we are not mandating an approach. > > > On 1/17/14 4:15 AM, KwangKoog Lee wrote: > > Dear Susan Hares, > > > > I deeply appreciate for your kind explanation about the multi-headed > > control of I2RS so that I reviewed the architecture document again and > > understood about the error-handling mechanism and the simplicity of I2RS > > nature. Sorry for my poor understanding of I2RS. > > > > Regarding to your comments, I still have some questions to be more clear. > > > > First, as you explained and the architecture states, the manipulation of > > the collision of multi-headed control can be processed by the assignment > > of client priorities. > > Rather, when the priority ties, the first client can keep the control. > > At this point, the first client means the firstly connected client for > > the controlling data or firstly connected client to the agent with that > > data? > > > > Second, the statements of two documents, architecture > > (draft-ietf-i2rs-architecture-00) and protocol > > requirement(draft-rfernando-i2rs-protocol-requirements-00), seem to have > > somewhat different views about the communication channel between client > > and agent. In the architecture document, Sec 6.2 states the > > communication channel between client and agent does not need to keep > > continuous transport. But Sec 4.2 TR-12 of the protocol requirement > > document states that keep-alives at transport level or I2RS protocol > > level could be provided for detecting the session failure. And > > simulataneous usage of session and communication channel of the > > architecture document is confusing for me. > > > > Finally, I have a question about the network application and client for > > client redundancy. I think client is not equal to network application. > > The architecture document states in Sec 6.5 for handling dead clients > > "the network applications or management systems will detect a dead > > network application and either restart that network application or clean > > up any state left behind." In addition, for basic client redundancy, the > > architecture states active and backup network application can be used. > > At this point, I want to know both network applications are physically > > separated from the client? > > > > Thank you for your comments, again :-) > > > > best regards, > > Kwang-koog Lee (KT) > > > > > > > > On Fri, Jan 17, 2014 at 5:55 PM, Songhaibin (A) > > wrote: > > > > Hi Sue, > > > > Thank you very much for so detailed explanation. I understand your > > two principles very clearly now. > > > > What comes into my mind is the following use case. Let's say it a > > bandwidth on demand scenario. Two clients A and B have different > > priorities to change user X's access bandwidth, and one client could > > be embedded in the user itself while another client is the system > > admin. Client A has higher priority. Then user X's access bandwidth > > is the piece of data. At time Y, Client A requests to change X's > > bandwidth to 20Mbps for two hours. And after two hours, X's > > bandwidth is reset to its default value. And after the time Y+2, > > either A or B should have the permission to change X's bandwidth > data. > > > > I guess you probably have already considered this. > > > > Best Regards! > > -Haibin > > > > > -----Original Message----- > > > From: Susan Hares [mailto:shares@ndzh.com >] > > > Sent: Friday, January 17, 2014 7:47 AM > > > To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee' > > > Cc: i2rs@ietf.org ; Guanxiaoran > > > Subject: RE: [i2rs] Multi-Headed Control > > > > > > Mach, Haibin, and KwanKooq: > > > > > > Joel gave you brief answers and then suggested reading the > > document. As > > > one of the co-authors, I will attempt to give the "longer" > > answers. I hope this > > > will encourage discussion sections in the architecture document. > > > > > > This is not suggest current flaws in the architecture draft, but > > to elucidate > > > (explain in depth) some of the drafts concepts. You may be > > asking questions > > > that we hope will be discussed on the list, but I cannot tell yet. > > > There are many sections in the architecture draft end with the > > phrase "Editor's > > > note: This topic (or These topics) need more discussion in the > > working group." > > > We encourage discussion of these drafts. > > > > > > If I am not answering the question, please just tell me. The > > important part of > > > this work is to get an architecture and drafts that can be > > implemented in > > > routers and switches. > > > > > > Ok.. enough introduction. On to a longer review that ends in a > > question: > > > > > > Review: > > > --------- > > > > > > In section 1.2, page 6 (bottom) of the -00 version of the > > architecture draft, I > > > states: > > > > > > " As can be seen in Figure 1, an I2RS client can communicate > with > > > multiple I2RS agents. An I2RS client may connect to one or > > more I2RS > > > agents based upon its needs. Similarly, an I2RS agent may > > > communicate with multiple I2RS clients - whether to respond to > > their > > > requests, to send notifications, etc. Timely notifications are > > > critical so that several simultaneously operating applications > > have > > > up-to-date information on the state of the network." > > > > > > Note here that the architecture states you may have one agent > > talking to > > > multiple I2RS clients. Once you enter this zone, you can have > > collisions. > > > In the beginning , we talk and talked about ways that you could > > handle > > > collisions - but we want to start simple. > > > > > > The phrase "protocol parsimony is clearly a goal" (section 3.1, > > p. 9) suggest we > > > are trying to implement just a few things in the first version of > > I2RS Clients and > > > I2RS Agents. From there, the I2RS protocol will be extended > later. > > > > > > The simple rule for multi-headed control (section 6.8) is to > > consider that two > > > clients manipulating the same piece of data is an error. For > example, > > > configuring an static route of prefix 192.1.1.0/24 > > should only be done by one > > > client. If two I2RS clients try to change the same piece of data > > in the same > > > I2RS Agent, it is an error. > > > > > > The architecture then requires that the I2RS clients and Agents > > have a > > > decidable way for the Agent to resolve the error. Section 6.8 > > states our > > > simple way: > > > 1) assign each client a priority (either by policy or default > policy) > > > 2) If the priorities tie, the first client "whose attribution is > > associated with the > > > data" keeps the control. > > > > > > That means - if you tie is First-come-keeps-control (FCKC) > > > > > > This is important to consider when you look at data models, scope > > (Section 2, p. > > > 7-8), and identity. You will note that the RIB manager is the > > easiest thing to > > > start with. Only one person can change one prefix, but multiple > > I2RS clients > > > can add different prefixes to the list. > > > > > > Now, what if I2RS client A wants to add 10 prefixes to the RIB > > and this includes > > > 192.1.1.0/24 to a single I2RS agent and > > I2RS client B wants to add > > > 1 prefix 192.1.1.0/24 . Does it cause a > > problem with I2RS client A if I24S > > > Client B gets there first (FCKC), and only 9 prefixes get added. > > > > > > That very issue is what section 6.9 deals with. > > > > > > Questions: > > > ----------- > > > 1. Are you trying to determine what happens when the multi-headed > > control > > > hits one of these errors? [See Sections 6.5, 6.6, 6.8 and 6.9] > > > > > > 2. Are you trying to build redundant clients (I2RS client A and > > I2RS Client > > > A') which are redundant clients? [See section 6.4.1] > > > > > > 3. Are you concerned about multi-headed control with multiple > > interfaces per > > > client? > > > (You could have 4 SCTP and 4 TCP session over which this > > protocol runs) > > > [Section 6.2] > > > > > > 4. How does a I2RS client A that reads the data know when I2RS > > Client B > > > modifies the Data? > > > [Section 6.8] > > > > > > Sue Hares > > > > > > > > > > > > -----Original Message----- > > > From: i2rs [mailto:i2rs-bounces@ietf.org > > ] On Behalf Of Joel M. Halpern > > > Sent: Tuesday, January 14, 2014 11:11 PM > > > To: Songhaibin (A); KwangKoog Lee > > > Cc: i2rs@ietf.org ; Guanxiaoran > > > Subject: Re: [i2rs] Multi-Headed Control > > > > > > There are no locks. > > > The changes made by the higher priority client remain in effect > > until either they > > > are removed by that client or an even higher priority client > > erroneously > > > over-writes them. Changes do not have lifetimes. > > > > > > One of the points of this mechanism was to avoid needing to guess > > what order > > > things happened in if they are close in time and you want to know > > the results. > > > > > > Please, read the draft. > > > > > > Yours, > > > Joel > > > > > > On 1/14/14 10:50 PM, Songhaibin (A) wrote: > > > > Hi Joel, > > > > > > > > It is a little confusing for me. See inline. > > > > > > > >> -----Original Message----- > > > >> From: i2rs [mailto:i2rs-bounces@ietf.org > > ] On Behalf Of Joel M. > > > >> Halpern > > > >> Sent: Tuesday, January 14, 2014 11:43 PM > > > >> To: KwangKoog Lee > > > >> Cc: i2rs@ietf.org ; Guanxiaoran > > > >> Subject: Re: [i2rs] Multi-Headed Control > > > >> > > > >> While I will try to paraphrase things to answer your question, > I > > > >> recommend you read the archtiecture draft to get more details. > > > >> > > > >> The assumption is that normally different I2RS clients will be > > asking > > > >> the agent to perform operations which change different pieces > > of data. > > > >> We discussed various models of conflict resolution for the > > case when > > > >> one client adjusts a piece of data, and then another client > > goes to > > > >> change that data. We decided that this was an error, and that > we > > > >> wanted a simple mechanism to decide what to do, while the > clients > > > >> sort > > > out what was intended. > > > > > > > > Except for client priorities, there are other factors like > > timing. I > > > assume that a client with higher priority changes a piece of > > data, but then a > > > client with lower priority can make changes to the same piece of > > data. It could > > > possibly depend on the how long the client with higher priority > > wants that > > > change to take effect. > > > > > > > > But when two clients want to make changes to the same data at > > the same > > > time, then the client with higher priority will get the , > > and the request > > > from the client with lower priority will be denied. And we can > > leave the choice > > > on whether to make another try to the client itself. > > > > > > > > Regards! > > > > -Haibin > > > > > > > >> Rather than > > > >> pure FCFS, we decided to have client priorities. And that > clients > > > >> could arrange > > > >> (easily) to be notified of changes to data they are interested > in. > > > >> > > > >> The goal is to keep the mechanisms very lightweight, > > particularly in > > > >> order to support very high rates of operations. > > > >> > > > >> Yours, > > > >> Joel > > > >> > > > >> On 1/14/14 10:29 AM, KwangKoog Lee wrote: > > > >>> I do not fully understand the data model of i2rs. But in case > > that > > > >>> many clients interact forwarding devices with the i2rs-enabled > > > >>> control plane, various policies about routing, signaling, qos > and > > > >>> etc. from multiple clients or multiple upper users (network > > > >>> applications) can be set to those devices and to prevent or > > > >>> negotiate some collision of multiple policies, such a > machanism > > > >>> might be necessary regardless of > > > >> netconf? > > > >>> Joel or anyone can explain more why it does not need? > > Thanks in > > > advance. > > > >>> > > > >>> best regards, > > > >>> Kwang-koog Lee > > > >>> On Tue, Jan 14, 2014 at 11:19 PM, Joel M. Halpern > > > >>> > > >> wrote: > > > >>> > > > >>> As I read the documents, locking is specifically not the > > approach > > > >>> I2RS is taking. So I think that "" does not > > suffice to > > > >>> resolve the I2RS needs, and is in fact not part of the > > current I2RS > > > >>> arhtiecture at all. > > > >>> Yours, > > > >>> Joel > > > >>> On 1/14/14 4:17 AM, Guanxiaoran wrote: > > > >>> > > > >>> Hi, > > > >>> I've a question about i2rs multi-headed control and > > NETCONF. > > > >>> [draft-ietf-i2rs-problem-__statement-00] > > describes:"Additional > > > >>> extensions to handle multi-headed control may need to > be > > > added > > > >>> to NetConf and/or appropriate data models." > > > >>> [draft-ietf-i2rs-architecture-__00] describes:"The > > current > > > >>> recommendation is to have a simple priority > > associated with > > > each > > > >>> I2RS clients, and the highest priority change remains > in > > > effect." > > > >>> As NETCONF has mechanism: "The > operation > > > allows > > > >>> the client to lock the entire configuration > data-store > > > >>> system > > > of > > > >>> a device. Such locks are intended to be short-lived > > and allow a > > > >>> client to make a change without fear of interaction > > with other > > > >>> NETCONF clients, non-NETCONF clients (e.g., SNMP and > > CLI), > > > and > > > >>> human users." > > > >>> Do we still need to do the extensions, i.e. > additional > > > >>> extensions to handle multi-headed control added to > > NETCONF? > > > >>> Regards, > > > >>> Ran > > > >>> _________________________________________________ > > > >>> i2rs mailing list > > > >>> i2rs@ietf.org > > > > > >>> https://www.ietf.org/mailman/__listinfo/i2rs > > > >>> > > > >>> > > > >>> _________________________________________________ > > > >>> i2rs mailing list > > > >>> i2rs@ietf.org > > > > > >>> https://www.ietf.org/mailman/__listinfo/i2rs > > > >>> > > > >>> > > > >> _______________________________________________ > > > >> i2rs mailing list > > > >> i2rs@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > > > > i2rs mailing list > > > > i2rs@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > --047d7bfcec644e68be04f11bb42f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry for my late response.
=A0
I= 've understood=A0the detailed mechanisms about=A0the multi-headed contr= ol of=A0I2RS through review of architecture document and authors' detai= led comments. Thank you, again. Many curiocities are solved but I have more= questions about the congestion control.

=A0
As stated in Sec. 6.1 of the architecture document,=A0I = think a congestion control mechanism of the I2RS=A0transport is also relate= d to=A0the multi-headed control.=A0As Joel explained,=A0the priority inform= ation each client has=A0can=A0simply solve=A0a congestion=A0situation in an= agent. Sec. 6.1 covers a congestion in a client as well as an=A0agent. The= probability of the congestion=A0in a client=A0is generally=A0higher than t= he agent case. Like the=A0client case, each agent can have any priority? Or= , I2RS messages from agents can additionally have priority?

=A0
I think as the architecture distinguishes "notifica= tions (in Sec. 6.6)" and "information collection (in Sec. 6.7)&qu= ot;=A0the notification message's=A0priority=A0is generally higher than = the priority of information collection message because the former has impor= tant and urgent information like interface failure that=A0may affect the ne= xt control of the underlying networks. If does, more detailed matters=A0are= needed to mention in the architecture document. I think it can help allevi= ate concerning of scalability and reliabilty for service providers consider= ing=A0SDN(I2RS)-enabled routing networks.

=A0
best regards,
Kwang-koog Lee (KT)
<= div class=3D"gmail_extra">

On Sat, Jan 18= , 2014 at 9:09 AM, Susan Hares <shares@ndzh.com> wrote:

KwangKoog:

Joel did not answer: "In addition, for basic client redundancy, the
architecture states active and backup network application= can be used. At
this point, I want to know both network applications are physically
separated from the client?"

The definitions in section 1.2 and 3.3 indicate that this is up to th= e
implementation.

Have we answered all your questions?

Sue

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@jo= elhalpern.com]

Sent: Friday, January 17, 201= 4 10:10 AM
To: KwangKoog Lee; Songhaibin (A)
Cc: Susan Hares; i2rs@ietf.org; Guanxi= aoran
Subject: Re: [i2rs] Multi-Headed Control

As was discussed at the last meeting, The authors of the rfernando
requirements draft will be making some changes to align with the working group agreed architecture. =A0There are currently some minor (and I
believe unintentional) discrepancies.

And in the context of collision detection, "first" simply means t= he
first client to change a piece of data. =A0We hope folks do not rely on
that mechanism, as it is unpredictable in outcome when changes are
applied close together in time. =A0That is why we have the priority scheme.=

Yours,
Joel

PS: Client archtiecture, application architecture, and client management are out of scope for this document. =A0There are many ways they can be
built, and we are not mandating an approach.

On 1/17/14 4:15 AM, KwangKoog Lee wrote:
> Dear Susan Hares,
>
> I deeply appreciate for your kind explanation about the multi-headed > control of I2RS so that I reviewed the architecture document again and=
> understood about the error-handling mechanism and the simplicity of I2= RS
> nature. Sorry for my poor understanding of I2RS.
>
> Regarding to your comments, I still have some questions to be more cle= ar.
>
> First, as you explained and the architecture states, the manipulation = of
> the collision of multi-headed control can be processed by the assignme= nt
> of client priorities.
> Rather, when the priority ties, the first client can keep the control.=
> At this point, the first client means the firstly connected client for=
> the controlling data or firstly connected client to the agent with tha= t
> data?
>
> Second, the statements of two documents, architecture
> (draft-ietf-i2rs-architecture-00) and protocol
> requirement(draft-rfernando-i2rs-protocol-requirements-00), seem to ha= ve
> somewhat different views about the communication channel between clien= t
> and agent. In the architecture document, Sec 6.2 states the
> communication channel between client and agent does not need to keep > continuous transport. But Sec 4.2 TR-12 of the protocol requirement > document states that keep-alives at transport level or I2RS protocol > level could be provided for detecting the session failure. And
> simulataneous usage of session and communication channel of the
> architecture document is confusing for me.
>
> Finally, I have a question about the network application and client fo= r
> client redundancy. I think client is not equal to network application.=
> The architecture document states in Sec 6.5 for handling dead clients<= br> > "the network applications or management systems will detect a dea= d
> network application and either restart that network application or cle= an
> up any state left behind." In addition, for basic client redundan= cy, the
> architecture states active and backup network application can be used.=
> At this point, I want to know both network applications are physically=
> separated from the client?
>
> Thank you for your comments, again :-)
>
> best regards,
> Kwang-koog Lee (KT)
>
>
>
> On Fri, Jan 17, 2014 at 5:55 PM, Songhaibin (A) <haibin.song@huawei.com
> <mailto:haibin.song@huawe= i.com>> wrote:
>
> =A0 =A0 Hi Sue,
>
> =A0 =A0 Thank you very much for so detailed explanation. I understand = your
> =A0 =A0 two principles very clearly now.
>
> =A0 =A0 What comes into my mind is the following use case. Let's s= ay it a
> =A0 =A0 bandwidth on demand scenario. Two clients A and B have differe= nt
> =A0 =A0 priorities to change user X's access bandwidth, and one cl= ient could
> =A0 =A0 be embedded in the user itself while another client is the sys= tem
> =A0 =A0 admin. Client A has higher priority. Then user X's access = bandwidth
> =A0 =A0 is the piece of data. At time Y, Client A requests to change X= 's
> =A0 =A0 bandwidth to 20Mbps for two hours. And after two hours, X'= s
> =A0 =A0 bandwidth is reset to its default value. And after the time Y+= 2,
> =A0 =A0 either A or B should have the permission to change X's ban= dwidth data.
>
> =A0 =A0 I guess you probably have already considered this.
>
> =A0 =A0 Best Regards!
> =A0 =A0 -Haibin
>
> =A0 =A0 =A0> -----Original Message-----
> =A0 =A0 =A0> From: Susan Hares [mailto:shares@ndzh.com <mailto:sh= ares@ndzh.com>]
> =A0 =A0 =A0> Sent: Friday, January 17, 2014 7:47 AM
> =A0 =A0 =A0> To: 'Joel M. Halpern'; Songhaibin (A); 'Kw= angKoog Lee'
> =A0 =A0 =A0> Cc: i2rs@ietf.org= <mailto:i2rs@ietf.org>; Guanxia= oran
> =A0 =A0 =A0> Subject: RE: [i2rs] Multi-Headed Control
> =A0 =A0 =A0>
> =A0 =A0 =A0> Mach, Haibin, and KwanKooq:
> =A0 =A0 =A0>
> =A0 =A0 =A0> Joel gave you brief answers and then suggested reading= the
> =A0 =A0 document. =A0As
> =A0 =A0 =A0> one of the co-authors, I will attempt to give the &quo= t;longer"
> =A0 =A0 answers. I hope this
> =A0 =A0 =A0> will encourage discussion sections in the architecture= document.
> =A0 =A0 =A0>
> =A0 =A0 =A0> This is not suggest current flaws in the architecture = draft, but
> =A0 =A0 to elucidate
> =A0 =A0 =A0> (explain in depth) some of the drafts concepts. =A0You= may be
> =A0 =A0 asking questions
> =A0 =A0 =A0> that we hope will be discussed on the list, but I cann= ot tell yet.
> =A0 =A0 =A0> There are many sections in the architecture draft end = with the
> =A0 =A0 phrase "Editor's
> =A0 =A0 =A0> note: This topic (or These topics) need more discussio= n in the
> =A0 =A0 working group."
> =A0 =A0 =A0> We encourage discussion of these drafts.
> =A0 =A0 =A0>
> =A0 =A0 =A0> If I am not answering the question, please just tell m= e. =A0The
> =A0 =A0 important part of
> =A0 =A0 =A0> this work is to get an architecture and drafts that ca= n be
> =A0 =A0 implemented in
> =A0 =A0 =A0> routers and switches.
> =A0 =A0 =A0>
> =A0 =A0 =A0> Ok.. enough introduction. =A0On to a longer review tha= t ends in a
> =A0 =A0 question:
> =A0 =A0 =A0>
> =A0 =A0 =A0> Review:
> =A0 =A0 =A0> ---------
> =A0 =A0 =A0>
> =A0 =A0 =A0> In section 1.2, page 6 (bottom) of the -00 version of = the
> =A0 =A0 architecture draft, I
> =A0 =A0 =A0> states:
> =A0 =A0 =A0>
> =A0 =A0 =A0> " =A0 As can be seen in Figure 1, an I2RS client = can communicate with
> =A0 =A0 =A0> =A0 =A0multiple I2RS agents. =A0An I2RS client may con= nect to one or
> =A0 =A0 more I2RS
> =A0 =A0 =A0> =A0 =A0agents based upon its needs. =A0Similarly, an I= 2RS agent may
> =A0 =A0 =A0> =A0 =A0communicate with multiple I2RS clients - whethe= r to respond to
> =A0 =A0 their
> =A0 =A0 =A0> =A0 =A0requests, to send notifications, etc. =A0Timely= notifications are
> =A0 =A0 =A0> =A0 =A0critical so that several simultaneously operati= ng applications
> =A0 =A0 have
> =A0 =A0 =A0> =A0 =A0up-to-date information on the state of the netw= ork."
> =A0 =A0 =A0>
> =A0 =A0 =A0> Note here that the architecture states you may have on= e agent
> =A0 =A0 talking to
> =A0 =A0 =A0> multiple I2RS clients. =A0Once you enter this zone, yo= u can have
> =A0 =A0 collisions.
> =A0 =A0 =A0> In the beginning , we talk and talked about ways that = you could
> =A0 =A0 handle
> =A0 =A0 =A0> collisions - but we want to start simple.
> =A0 =A0 =A0>
> =A0 =A0 =A0> The phrase "protocol parsimony is clearly a goal&= quot; (section 3.1,
> =A0 =A0 p. 9) suggest we
> =A0 =A0 =A0> are trying to implement just a few things in the first= version of
> =A0 =A0 I2RS Clients and
> =A0 =A0 =A0> I2RS Agents. =A0From there, the I2RS protocol will be = extended later.
> =A0 =A0 =A0>
> =A0 =A0 =A0> The simple rule for multi-headed control (section 6.8)= is to
> =A0 =A0 consider that two
> =A0 =A0 =A0> clients manipulating the same piece of data is an erro= r. For
example,
> =A0 =A0 =A0> configuring an static route of prefix 192.1.1.0/24
> =A0 =A0 <http://1= 92.1.1.0/24> should only be done by one
> =A0 =A0 =A0> client. =A0If two I2RS clients try to change the same = piece of data
> =A0 =A0 in the same
> =A0 =A0 =A0> I2RS Agent, it is an error.
> =A0 =A0 =A0>
> =A0 =A0 =A0> The architecture then requires that the I2RS clients a= nd Agents
> =A0 =A0 have a
> =A0 =A0 =A0> decidable way for the Agent to resolve the error. =A0 = Section 6.8
> =A0 =A0 states our
> =A0 =A0 =A0> simple way:
> =A0 =A0 =A0> 1) assign each client a priority (either by policy or = default
policy)
> =A0 =A0 =A0> 2) If the priorities tie, the first client "whose= attribution is
> =A0 =A0 associated with the
> =A0 =A0 =A0> data" keeps the control.
> =A0 =A0 =A0>
> =A0 =A0 =A0> That means - if you tie is First-come-keeps-control (F= CKC)
> =A0 =A0 =A0>
> =A0 =A0 =A0> This is important to consider when you look at data mo= dels, scope
> =A0 =A0 (Section 2, p.
> =A0 =A0 =A0> 7-8), and identity. =A0You will note that the RIB mana= ger is the
> =A0 =A0 easiest thing to
> =A0 =A0 =A0> start with. =A0Only one person can change one prefix, = but multiple
> =A0 =A0 I2RS clients
> =A0 =A0 =A0> can add different prefixes to the list.
> =A0 =A0 =A0>
> =A0 =A0 =A0> Now, what if I2RS client A wants to add 10 prefixes to= the RIB
> =A0 =A0 and this includes
> =A0 =A0 =A0> 192.= 1.1.0/24 <http://1= 92.1.1.0/24> to a single I2RS agent and
> =A0 =A0 I2RS client B wants to add
> =A0 =A0 =A0> 1 prefix 192.1.1.0/24 <http://192.1.1.0/24>. =A0 Does it cause a
> =A0 =A0 problem with I2RS client A if I24S
> =A0 =A0 =A0> Client B gets there first (FCKC), and only 9 prefixes = get added.
> =A0 =A0 =A0>
> =A0 =A0 =A0> That very issue is what section 6.9 deals with.
> =A0 =A0 =A0>
> =A0 =A0 =A0> Questions:
> =A0 =A0 =A0> -----------
> =A0 =A0 =A0> 1. Are you trying to determine what happens when the m= ulti-headed
> =A0 =A0 control
> =A0 =A0 =A0> hits one of these errors? =A0[See Sections 6.5, 6.6, 6= .8 and 6.9]
> =A0 =A0 =A0>
> =A0 =A0 =A0> 2. Are you trying to build redundant clients (I2RS cli= ent A and
> =A0 =A0 I2RS Client
> =A0 =A0 =A0> A') which are redundant clients? =A0[See section 6= .4.1]
> =A0 =A0 =A0>
> =A0 =A0 =A0> 3. =A0Are you concerned about multi-headed control wit= h multiple
> =A0 =A0 interfaces per
> =A0 =A0 =A0> client?
> =A0 =A0 =A0> =A0 =A0(You could have 4 SCTP and 4 TCP session over w= hich this
> =A0 =A0 protocol runs)
> =A0 =A0 =A0> [Section 6.2]
> =A0 =A0 =A0>
> =A0 =A0 =A0> 4. How does a I2RS client A that reads the data know w= hen I2RS
> =A0 =A0 Client B
> =A0 =A0 =A0> modifies the Data?
> =A0 =A0 =A0> [Section 6.8]
> =A0 =A0 =A0>
> =A0 =A0 =A0> Sue Hares
> =A0 =A0 =A0>
> =A0 =A0 =A0>
> =A0 =A0 =A0>
> =A0 =A0 =A0> -----Original Message-----
> =A0 =A0 =A0> From: i2rs [mailto:i2rs-bounces@ietf.org
> =A0 =A0 <mailto:i2rs-bounc= es@ietf.org>] On Behalf Of Joel M. Halpern
> =A0 =A0 =A0> Sent: Tuesday, January 14, 2014 11:11 PM
> =A0 =A0 =A0> To: Songhaibin (A); KwangKoog Lee
> =A0 =A0 =A0> Cc: i2rs@ietf.org= <mailto:i2rs@ietf.org>; Guanxia= oran
> =A0 =A0 =A0> Subject: Re: [i2rs] Multi-Headed Control
> =A0 =A0 =A0>
> =A0 =A0 =A0> There are no locks.
> =A0 =A0 =A0> The changes made by the higher priority client remain = in effect
> =A0 =A0 until either they
> =A0 =A0 =A0> are removed by that client or an even higher priority = client
> =A0 =A0 erroneously
> =A0 =A0 =A0> over-writes them. =A0Changes do not have lifetimes. > =A0 =A0 =A0>
> =A0 =A0 =A0> One of the points of this mechanism was to avoid needi= ng to guess
> =A0 =A0 what order
> =A0 =A0 =A0> things happened in if they are close in time and you w= ant to know
> =A0 =A0 the results.
> =A0 =A0 =A0>
> =A0 =A0 =A0> Please, read the draft.
> =A0 =A0 =A0>
> =A0 =A0 =A0> Yours,
> =A0 =A0 =A0> Joel
> =A0 =A0 =A0>
> =A0 =A0 =A0> On 1/14/14 10:50 PM, Songhaibin (A) wrote:
> =A0 =A0 =A0> > Hi Joel,
> =A0 =A0 =A0> >
> =A0 =A0 =A0> > It is a little confusing for me. See inline.
> =A0 =A0 =A0> >
> =A0 =A0 =A0> >> -----Original Message-----
> =A0 =A0 =A0> >> From: i2rs [mailto:i2rs-bounces@ietf.org
> =A0 =A0 <mailto:i2rs-bounc= es@ietf.org>] On Behalf Of Joel M.
> =A0 =A0 =A0> >> Halpern
> =A0 =A0 =A0> >> Sent: Tuesday, January 14, 2014 11:43 PM
> =A0 =A0 =A0> >> To: KwangKoog Lee
> =A0 =A0 =A0> >> Cc: i2rs@iet= f.org <mailto:i2rs@ietf.org>= ; Guanxiaoran
> =A0 =A0 =A0> >> Subject: Re: [i2rs] Multi-Headed Control
> =A0 =A0 =A0> >>
> =A0 =A0 =A0> >> While I will try to paraphrase things to answ= er your question, I
> =A0 =A0 =A0> >> recommend you read the archtiecture draft to = get more details.
> =A0 =A0 =A0> >>
> =A0 =A0 =A0> >> The assumption is that normally different I2R= S clients will be
> =A0 =A0 asking
> =A0 =A0 =A0> >> the agent to perform operations which change = different pieces
> =A0 =A0 of data.
> =A0 =A0 =A0> >> We discussed various models of conflict resol= ution for the
> =A0 =A0 case when
> =A0 =A0 =A0> >> one client adjusts a piece of data, and then = another client
> =A0 =A0 goes to
> =A0 =A0 =A0> >> change that data. =A0We decided that this was= an error, and that
we
> =A0 =A0 =A0> >> wanted a simple mechanism to decide what to d= o, while the
clients
> =A0 =A0 =A0> >> sort
> =A0 =A0 =A0> out what was intended.
> =A0 =A0 =A0> >
> =A0 =A0 =A0> > Except for client priorities, there are other fac= tors like
> =A0 =A0 timing. I
> =A0 =A0 =A0> assume that a client with higher priority changes a pi= ece of
> =A0 =A0 data, but then a
> =A0 =A0 =A0> client with lower priority can make changes to the sam= e piece of
> =A0 =A0 data. It could
> =A0 =A0 =A0> possibly depend on the how long the client with higher= priority
> =A0 =A0 wants that
> =A0 =A0 =A0> change to take effect.
> =A0 =A0 =A0> >
> =A0 =A0 =A0> > But when two clients want to make changes to the = same data at
> =A0 =A0 the same
> =A0 =A0 =A0> time, then the client with higher priority will get th= e <lock>,
> =A0 =A0 and the request
> =A0 =A0 =A0> from the client with lower priority will be denied. An= d we can
> =A0 =A0 leave the choice
> =A0 =A0 =A0> on whether to make another try to the client itself. > =A0 =A0 =A0> >
> =A0 =A0 =A0> > Regards!
> =A0 =A0 =A0> > -Haibin
> =A0 =A0 =A0> >
> =A0 =A0 =A0> >> Rather than
> =A0 =A0 =A0> >> pure FCFS, we decided to have client prioriti= es. =A0And that
clients
> =A0 =A0 =A0> >> could arrange
> =A0 =A0 =A0> >> (easily) to be notified of changes to data th= ey are interested
in.
> =A0 =A0 =A0> >>
> =A0 =A0 =A0> >> The goal is to keep the mechanisms very light= weight,
> =A0 =A0 particularly in
> =A0 =A0 =A0> >> order to support very high rates of operation= s.
> =A0 =A0 =A0> >>
> =A0 =A0 =A0> >> Yours,
> =A0 =A0 =A0> >> Joel
> =A0 =A0 =A0> >>
> =A0 =A0 =A0> >> On 1/14/14 10:29 AM, KwangKoog Lee wrote:
> =A0 =A0 =A0> >>> I do not fully understand the data model = of i2rs. But in case
> =A0 =A0 that
> =A0 =A0 =A0> >>> many clients interact forwarding devices = with the i2rs-enabled
> =A0 =A0 =A0> >>> control plane, various policies about rou= ting, signaling, qos
and
> =A0 =A0 =A0> >>> etc. from multiple clients or multiple up= per users (network
> =A0 =A0 =A0> >>> applications) can be set to those devices= and to prevent or
> =A0 =A0 =A0> >>> negotiate some collision of multiple poli= cies, such a machanism
> =A0 =A0 =A0> >>> might be necessary regardless of
> =A0 =A0 =A0> >> netconf?
> =A0 =A0 =A0> >>> =A0 =A0Joel or anyone can explain more wh= y it does not need?
> =A0 =A0 Thanks in
> =A0 =A0 =A0> advance.
> =A0 =A0 =A0> >>>
> =A0 =A0 =A0> >>> best regards,
> =A0 =A0 =A0> >>> Kwang-koog Lee
> =A0 =A0 =A0> >>> On Tue, Jan 14, 2014 at 11:19 PM, Joel M.= Halpern
> =A0 =A0 =A0> >>> <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
> =A0 =A0 <mailto:jmh@joelhalp= ern.com <mailto:jmh@joelhalpe= rn.com>>> wrote:
> =A0 =A0 =A0> >>>
> =A0 =A0 =A0> >>> =A0 =A0 =A0As I read the documents, locki= ng is specifically not the
> =A0 =A0 approach
> =A0 =A0 =A0> >>> =A0 =A0 =A0I2RS is taking. =A0So I think = that "<lock>" does not
> =A0 =A0 suffice to
> =A0 =A0 =A0> >>> =A0 =A0 =A0resolve the I2RS needs, and is= in fact not part of the
> =A0 =A0 current I2RS
> =A0 =A0 =A0> >>> =A0 =A0 =A0arhtiecture at all.
> =A0 =A0 =A0> >>> =A0 =A0 =A0Yours,
> =A0 =A0 =A0> >>> =A0 =A0 =A0Joel
> =A0 =A0 =A0> >>> =A0 =A0 =A0On 1/14/14 4:17 AM, Guanxiaora= n wrote:
> =A0 =A0 =A0> >>>
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0Hi,
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0I've a question ab= out i2rs multi-headed control and
> =A0 =A0 NETCONF.
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0[draft-ietf-i2rs-probl= em-__statement-00]
> =A0 =A0 describes:"Additional
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0extensions to handle m= ulti-headed control may need to
be
> =A0 =A0 =A0> added
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0to NetConf and/or appr= opriate data models."
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0[draft-ietf-i2rs-archi= tecture-__00] describes:"The
> =A0 =A0 current
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0recommendation is to h= ave a simple priority
> =A0 =A0 associated with
> =A0 =A0 =A0> each
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0I2RS clients, and the = highest priority change remains
in
> =A0 =A0 =A0> effect."
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0As NETCONF has <loc= k> mechanism: "The <lock> operation
> =A0 =A0 =A0> allows
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0the client to lock the= entire configuration data-store
> =A0 =A0 =A0> >>> system
> =A0 =A0 =A0> of
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0a device. Such locks a= re intended to be short-lived
> =A0 =A0 and allow a
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0client to make a chang= e without fear of interaction
> =A0 =A0 with other
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0NETCONF clients, non-N= ETCONF clients (e.g., SNMP and
> =A0 =A0 CLI),
> =A0 =A0 =A0> and
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0human users."
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0Do we still need to do= the extensions, i.e. additional
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0extensions to handle m= ulti-headed control added to
> =A0 =A0 NETCONF?
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0Regards,
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0Ran
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0______________________= ___________________________
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0i2rs mailing list
> =A0 =A0 =A0> >>> i2rs@iet= f.org <mailto:i2rs@ietf.org>= <mailto:i2rs@ietf.org
> =A0 =A0 <mailto:i2rs@ietf.org&= gt;>
> =A0 =A0 =A0> >>> https://www.ietf.org/mailman/__listinfo/i= 2rs
> =A0 =A0 =A0> >>> =A0 =A0 =A0 =A0 =A0<https://www.ietf.org= /mailman/listinfo/i2rs>
> =A0 =A0 =A0> >>>
> =A0 =A0 =A0> >>> =A0 =A0 =A0______________________________= ___________________
> =A0 =A0 =A0> >>> =A0 =A0 =A0i2rs mailing list
> =A0 =A0 =A0> >>> i2rs@iet= f.org <mailto:i2rs@ietf.org>= <mailto:i2rs@ietf.org
> =A0 =A0 <mailto:i2rs@ietf.org&= gt;>
> =A0 =A0 =A0> >>> https://www.ietf.org/mailman/__listinfo/i= 2rs
> =A0 =A0 =A0> >>> =A0 =A0 =A0<https://www.ietf.org/mailman= /listinfo/i2rs>
> =A0 =A0 =A0> >>>
> =A0 =A0 =A0> >> _____________________________________________= __
> =A0 =A0 =A0> >> i2rs mailing list
> =A0 =A0 =A0> >> i2rs@ietf.or= g <mailto:i2rs@ietf.org>
> =A0 =A0 =A0> >> https://www.ietf.org/mailman/listinfo/i2rs<= br> > =A0 =A0 =A0> > _______________________________________________ > =A0 =A0 =A0> > i2rs mailing list
> =A0 =A0 =A0> > i2rs@ietf.org <mailto:i2rs@ietf.org>
> =A0 =A0 =A0> > https://www.ietf.org/mailman/listinfo/i2rs
> =A0 =A0 =A0> >
> =A0 =A0 =A0> _______________________________________________
> =A0 =A0 =A0> i2rs mailing list
> =A0 =A0 =A0> i2rs@ietf.org <= ;mailto:i2rs@ietf.org>
> =A0 =A0 =A0> https://www.ietf.org/mailman/listinfo/i2rs
>
>

--047d7bfcec644e68be04f11bb42f-- From kwangkooglee@gmail.com Wed Jan 29 05:37:55 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A65A1A02EA for ; Wed, 29 Jan 2014 05:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkgPNjhyAH-5 for ; Wed, 29 Jan 2014 05:37:53 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCA71A0266 for ; Wed, 29 Jan 2014 05:37:53 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id x13so3462007wgg.21 for ; Wed, 29 Jan 2014 05:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=buwcBt/n/U73XOI1L8xJtlVt4QaUPDGXqrTmNL/sn20=; b=bPS2vTaCkLh9fGNNA8Cf5NSKLQd+dv0Y23m7jxa3FLbmCob6wKGg8/Jn8ZKm7I16y+ o+/KAbk2v47qAzezaXG9k9gVabOPDlSqrCqrit8/XBneNhjvkYsZ7ndh1dpXPic+sit3 gZZiegMfPtj1oo9LnYwpAqZkIjky2SnToRkxT3ONHy9r74DrjvqERbDOLE6wK+lFsoS/ Gb38/JDyjY8vQfdwfdaTkGkDKwrSmr29WfKdec4PbFHgpIleeVQlY02TYhLXpOSpCcwR lZG2Ww0pp+WiSl6qDuvOL+xpO9dYp0/tJTo+My5hASxtHr6E1Qhy7Ao5sfT9TR8WVjlF b2fA== MIME-Version: 1.0 X-Received: by 10.194.178.135 with SMTP id cy7mr5109988wjc.21.1391002670280; Wed, 29 Jan 2014 05:37:50 -0800 (PST) Received: by 10.194.94.169 with HTTP; Wed, 29 Jan 2014 05:37:50 -0800 (PST) Date: Wed, 29 Jan 2014 22:37:50 +0900 Message-ID: From: KwangKoog Lee To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=089e013d1dd40b364c04f11c0cd1 Subject: [i2rs] question to draft-white-i2rs-use-case-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 13:37:55 -0000 --089e013d1dd40b364c04f11c0cd1 Content-Type: text/plain; charset=ISO-8859-1 Dear authors, I read the use case document again and overally I think this document well worked out. There are a few comments below; 1) Why the updated version removes previously described two use cases (MPLS and optimal exit)? 2) In Sec. 5, authors explained preemption on network bandwidth is necessary for urgent movement of information from failed data center to safe data center. But, the summary of I2RS capability and interactions has not any detail capability about this. According to Sec 5.4.4 policy and QoS mechanism of the architure document, I suggest that some statements about queue control capability (priority queueing or other well-known scheduling mechanisms, rate limit, etc ...) should be written in the summary. best regards, Kwang-koog Lee (KT) --089e013d1dd40b364c04f11c0cd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear authors,
=A0
I read the use= case document again and overally I think this document well worked out.
There are=A0a few comments below;
=A0
1) Why t= he updated version removes previously described two use cases (MPLS and opt= imal exit)?

=A0
2) In Sec. 5, authors explained preemption on network ba= ndwidth is necessary for urgent movement of information from failed data ce= nter to safe data center. But, the=A0summary of I2RS capability and interac= tions has not any detail capability about this. According to Sec 5.4.4 poli= cy and QoS mechanism of the architure document, I suggest that some stateme= nts about queue control capability (priority queueing or other well-known s= cheduling mechanisms, rate=A0limit, etc ...) should be written in the summa= ry.

=A0
best regards,
Kwang-koog Lee (KT)
--089e013d1dd40b364c04f11c0cd1-- From abdussalambaryun@gmail.com Thu Jan 30 04:14:52 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E030A1A02C8 for ; Thu, 30 Jan 2014 04:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q92Zqy9wfFFN for ; Thu, 30 Jan 2014 04:14:51 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5630C1A0233 for ; Thu, 30 Jan 2014 04:14:51 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp16so3031458pbb.34 for ; Thu, 30 Jan 2014 04:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/wzpUn7UQtF/r+IFOvv8qNmcxMcQAujVbmpDCeK1c84=; b=TOJu1mrcjhuX+sj1BbogGXSxOeEobjB9jie9Hc2FbiO3rjVR6ERAfgEciLzjjldm+u WZgN+uzdFWEQXqY0wWs0W0Bpzj6qRLWCn4H8QWeaMLbsnCLV5SVn3GcWRWg8GtPZOrY0 MdcraeKODuTekHOP62bClG4dcjf+xHmXQtzH24LmLopO+yWmLHiqj47iIGlRFYlyO3vd 0BnUhPYz2WgRyFaOJ/KXutgLgki5NcwleeC4M22bY2QdReR6crnQ52sp2y/cvW1kVnYL FxJeMPnJmz2ecercX3zJ17Tiwe2y4YSZLA168WsdskKzsmMjcJWUPxHoijqd0dPUD0kB v5Bg== MIME-Version: 1.0 X-Received: by 10.68.230.137 with SMTP id sy9mr13968408pbc.126.1391084088235; Thu, 30 Jan 2014 04:14:48 -0800 (PST) Received: by 10.68.0.104 with HTTP; Thu, 30 Jan 2014 04:14:48 -0800 (PST) In-Reply-To: <2C5AD5728DB9B24189E3A93140E45786366363@szxeml522-mbx.china.huawei.com> References: <2C5AD5728DB9B24189E3A93140E45786366363@szxeml522-mbx.china.huawei.com> Date: Thu, 30 Jan 2014 13:14:48 +0100 Message-ID: From: Abdussalam Baryun To: Guanxiaoran Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Multi-Headed Control X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 12:14:53 -0000 I don't think multi-head control is controlling any thing, to control the system it needs one head/management method. AB On 1/14/14, Guanxiaoran wrote: > Hi, > > I've a question about i2rs multi-headed control and NETCONF. > > [draft-ietf-i2rs-problem-statement-00] describes:"Additional extensions to > handle multi-headed control may need to be added to NetConf and/or > appropriate data models." > > [draft-ietf-i2rs-architecture-00] describes:"The current recommendation is > to have a simple priority associated with each I2RS clients, and the highest > priority change remains in effect." > > As NETCONF has mechanism: "The operation allows the client to > lock the entire configuration data-store system of a device. Such locks are > intended to be short-lived and allow a client to make a change without fear > of interaction with other NETCONF clients, non-NETCONF clients (e.g., SNMP > and CLI), and human users." > > Do we still need to do the extensions, i.e. additional extensions to handle > multi-headed control added to NETCONF? > > Regards, > Ran > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From akatlas@gmail.com Fri Jan 31 17:40:37 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111BB1ACCE3 for ; Fri, 31 Jan 2014 17:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6YK16gIXDVx for ; Fri, 31 Jan 2014 17:40:36 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id DFD2C1ACCE0 for ; Fri, 31 Jan 2014 17:40:35 -0800 (PST) Received: by mail-yk0-f176.google.com with SMTP id 131so2681320ykp.7 for ; Fri, 31 Jan 2014 17:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1d5A75QEbYDtYoHMk2xIA4jl3IYYCu785MFybUkGx9E=; b=uAbJz5TDDqaKcoT9g5xFNAyXbvgtoU8P+7f832aZPGuQlIi+x1EF3vczIttk/CS0Ns uIOewbkW33gOHnXvfVTdYtpAexGh05WYE3IVcksM+6QgPDHKDOnbZurs9XQ+IOUNdi+5 4DnIluspbVQUye0HDMroiF3ywYc1VgxsSQL4ZrzJUoP8RwW7svPA87N6QMYMl1LXnHjz BDyNi89EM73IOLIVroCvHs4SIBW/1IADBksAxIVtoigutBwZMH6gbWmdld5rrppscKPd Freb/E+3EPGR1SWjXx4cBtUAfjXpHEY/V1huSiiPrgcOQ6Iu3JbjM/8tt9st2Xf19wzx RMgw== MIME-Version: 1.0 X-Received: by 10.236.133.147 with SMTP id q19mr21708270yhi.32.1391218832062; Fri, 31 Jan 2014 17:40:32 -0800 (PST) Received: by 10.170.186.88 with HTTP; Fri, 31 Jan 2014 17:40:32 -0800 (PST) Date: Fri, 31 Jan 2014 20:40:32 -0500 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=20cf303b3b9b4a3cbf04f14e60f8 Subject: [i2rs] I2RS scheduled on Friday (prelim agenda) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 01:40:37 -0000 --20cf303b3b9b4a3cbf04f14e60f8 Content-Type: text/plain; charset=ISO-8859-1 Just a quick heads up that i2rs is on Friday 9-11:30 am in London. Alia --20cf303b3b9b4a3cbf04f14e60f8 Content-Type: text/html; charset=ISO-8859-1
Just a quick heads up that i2rs is on Friday 9-11:30 am in London.

Alia
--20cf303b3b9b4a3cbf04f14e60f8--