=A0 =A0- s/may help define needed/may require help defining needed/

Andy

--047d7b339cefbb528e04dfc19149-- From abdussalambaryun@gmail.com Sun Jun 23 02:17:00 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAD321F9958 for ; Sun, 23 Jun 2013 02:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l42iOwLOGQnr for ; Sun, 23 Jun 2013 02:16:58 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 673DC21F8F6E for ; Sun, 23 Jun 2013 02:16:50 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so9718805pab.39 for ; Sun, 23 Jun 2013 02:16:43 -0700 (PDT) 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=7D8+q2LFsqn/mcCNJqj+7nNh2UeI/lI/G0pv0bAS8tk=; b=rDuhYQNwA4O26Ao/rSJOsaLgLEeed832HVB6v68NPFUQoXIyf7QUxRPGxVdAyJoRqM XkFwmMbAMD/NzAA7p04IaENUyhlQSg4BWiTCkBB4OYQoa7aQZh2zW2UbyRn6JChLq7eJ u70PyiM4hVZM5KbTCTMkFq7xdUkMrHAIsxKbqVvm0EJUiSQZSjPqsKvSLRwf+zpzgCZA yDW/8yWcS69pQlfymaRTySqnf16RULt4d+C3K1bBNF97H4Gbs1fyWXPpdJa2EtbudZvw FauPxTl4I1yisnuFimoBwHMRYGJT6SJGbXxY8JL+xp544rv99xHu2kfDN4YN6iArYYxS 6K6w== MIME-Version: 1.0 X-Received: by 10.66.230.199 with SMTP id ta7mr23613644pac.153.1371979003000; Sun, 23 Jun 2013 02:16:43 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Sun, 23 Jun 2013 02:16:42 -0700 (PDT) In-Reply-To: References: Date: Sun, 23 Jun 2013 11:16:42 +0200 Message-ID: From: Abdussalam Baryun To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org Subject: Re: [i2rs] standard interfaces within scope for I2RS X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 23 Jun 2013 09:17:00 -0000 I beleive if any thing not shown then they are not allowed by I2RS, if it is shown then it is the way the I2RS will work to solve the problem. So I will understand that I2RS client does not talk to NE but only to the agent, that is why I suggest that we don't show any sign that the client can talk to any other as long it is out of scope. Therefore the drawing methodology (figure 1) is : (if out of scope of the protocol then should not be shown, and if future work of protocol it may be shown). AB On 6/22/13, Andy Bierman wrote: > Hi, > > I just re-read the framework and problem statement drafts. > Only 1 minor issue in the problem statement draft: > > The 'I2RS Agent' is shown as a single box in figure 1. > > 1) Does this mean the protocol between the "broker" and the > NEs is proprietary, or just not shown? > > 2) Does this mean that an I2RS Client never talks directly to an NE > or does it mean all I2RS Agent functionality is available on all NEs? > > Nit, sec. 6, para 4: > - the lack of standard data models is the problem of the NETMOD WG, > not really the NETCONF protocol. > - s/may help define needed/may require help defining needed/ > > > Andy > From andy@yumaworks.com Sun Jun 23 08:59:43 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3416321F9E30 for ; Sun, 23 Jun 2013 08:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfYwx5WtVzVr for ; Sun, 23 Jun 2013 08:59:42 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6A821F9E2B for ; Sun, 23 Jun 2013 08:59:41 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gw10so9329207lab.16 for ; Sun, 23 Jun 2013 08:59:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=91La3AxDkLlJxq+sEU4JVHTpA0a90mk7MduscpeObrI=; b=EPM9AYcnDZWrGHRadTVRoMvuCduV5WQwSeLB4FmSAG4Rmot243usLNVdUV0RVZozh1 ntm7kBNuiJ39xuzmapPZNS58egjakxl1y3J7/hSqlVRKleB+6D4EbYIBGdNupXfKN+CN Sxu6Vk1/YZtBHs6Jq5XYvMlnTa+sctXhpVcBTiaZtzsWtYA9jL7hFBEo/cwD9wMKGUkA 1YdGzNMng+wMSAstIA6Zs/nfXgYmWF+A1SdVK2F8A3gMKmIDvu71EkQI+qHAwNAZZNYg K8AhEId0xrHCymLu2465RRgpojhcwxrBPATBe5amdfVhnBDXSEuHmeiwvNNSH25KkBp2 rpYQ== MIME-Version: 1.0 X-Received: by 10.152.27.9 with SMTP id p9mr9772018lag.4.1372003180943; Sun, 23 Jun 2013 08:59:40 -0700 (PDT) Received: by 10.112.200.234 with HTTP; Sun, 23 Jun 2013 08:59:40 -0700 (PDT) In-Reply-To: References:

Date: Sun, 23 Jun 2013 08:59:40 -0700 Message-ID: From: Andy Bierman To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=089e0160a3ac3b2c7d04dfd46299 X-Gm-Message-State: ALoCoQltd8JIzhc9IT7hM1AjjcASwUDXw6w382nATXAWk9+mdVtarRAj31kwBdSS6GAfSmspOWFI Cc: i2rs@ietf.org Subject: Re: [i2rs] standard interfaces within scope for I2RS X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 23 Jun 2013 15:59:43 -0000 --089e0160a3ac3b2c7d04dfd46299 Content-Type: text/plain; charset=ISO-8859-1 Hi, If an I2RS client wants to set up a tunnel between 2 routers (as a lame example), does it send 1 request to 1 I2RS agent or 2 requests, 1 to each I2RS agent/router? If 1 request, is the southbound protocol between the I2RS agent and at least 1 router proprietary or part of the standard? I think this draft should be clear about what is in scope. It seems to say that the southbound protocol is out of scope. Andy On Sun, Jun 23, 2013 at 2:16 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > I beleive if any thing not shown then they are not allowed by I2RS, if > it is shown then it is the way the I2RS will work to solve the > problem. So I will understand that I2RS client does not talk to NE but > only to the agent, that is why I suggest that we don't show any sign > that the client can talk to any other as long it is out of scope. > Therefore the drawing methodology (figure 1) is : (if out of scope of > the protocol then should not be shown, and if future work of protocol > it may be shown). > > AB > > On 6/22/13, Andy Bierman wrote: > > Hi, > > > > I just re-read the framework and problem statement drafts. > > Only 1 minor issue in the problem statement draft: > > > > The 'I2RS Agent' is shown as a single box in figure 1. > > > > 1) Does this mean the protocol between the "broker" and the > > NEs is proprietary, or just not shown? > > > > 2) Does this mean that an I2RS Client never talks directly to an NE > > or does it mean all I2RS Agent functionality is available on all > NEs? > > > > Nit, sec. 6, para 4: > > - the lack of standard data models is the problem of the NETMOD WG, > > not really the NETCONF protocol. > > - s/may help define needed/may require help defining needed/ > > > > > > Andy > > > --089e0160a3ac3b2c7d04dfd46299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

If an I2RS client wants to set up a tunnel between 2= routers

(as a lame example), does it send 1 request to 1 I2RS ag= ent

or 2 requests, 1 to each I2RS agent/router? =A0If 1 request, = is the southbound

protocol between the I2RS agent and at least 1 router proprietary

or part of the standard?

I think this draft = should be clear about what is in scope.

It seems to say that the = southbound protocol is out of scope.

Andy

On Sun, Jun 23, 2013 at 2:16 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I beleive if any thing not shown then they a= re not allowed by I2RS, if
it is shown then it is the way the I2RS will work to solve the
problem. So I will understand that I2RS client does not talk to NE but
only to the agent, that is why I suggest that we don't show any sign that the client can talk to any other as long it is out of scope.
Therefore the drawing methodology (figure 1) is : (if out of scope of
the protocol then should not be shown, and if future work of protocol
it may be shown).

AB

On 6/22/13, Andy Bierman <andy@yum= aworks.com> wrote:
> Hi,
>
> I just re-read the framework and problem statement drafts.
> Only 1 minor issue in the problem statement draft:
>
> The 'I2RS Agent' is shown as a single box in figure 1.
>
> =A01) Does this mean the protocol between the "broker" and t= he
> =A0 =A0 =A0NEs is proprietary, or just not shown?
>
> =A02) Does this mean that an I2RS Client never talks directly to an NE=
> =A0 =A0 =A0or does it mean all I2RS Agent functionality is available o= n all NEs?
>
> Nit, sec. 6, para 4:
> =A0 =A0- the lack of standard data models is the problem of the NETMOD= WG,
> =A0 =A0 =A0not really the NETCONF protocol.
> =A0 =A0- s/may help define needed/may require help defining needed/ >
>
> Andy
>

--089e0160a3ac3b2c7d04dfd46299-- From jmh@joelhalpern.com Sun Jun 23 12:47:54 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CF221F9CF6 for ; Sun, 23 Jun 2013 12:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi1yYLf74yTP for ; Sun, 23 Jun 2013 12:47:49 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7D87021F9EA6 for ; Sun, 23 Jun 2013 12:47:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 6D37D1C0433; Sun, 23 Jun 2013 12:47:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-231.clppva.east.verizon.net [70.106.134.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BC9CF1C005E; Sun, 23 Jun 2013 12:47:43 -0700 (PDT) Message-ID: <51C750CD.3080805@joelhalpern.com> Date: Sun, 23 Jun 2013 15:47:25 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Bierman References:

In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org Subject: Re: [i2rs] standard interfaces within scope for I2RS X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 23 Jun 2013 19:47:54 -0000 I think that the particular example you propose will onot help. Some tunneling protocols only requrie action at one end to initiate a bi-directional tunnel. I that case, presumably, the I2RS client would only need to interact with that one end. Other protocols require action / configuration at both ends to establish a bi-directional tunnel. In that case, the i2rs client would need to interact with both ends. (And other protocols are even stranger.) If your question is whether i2rs includes a protocol between i2rs agents to coordinate action across boxes, separate from existing protocol mechanisms, then I believe that the answer is a clear "no". There is is agent-agent protocol in scope for the i2rs work. Yours, Joel On 6/23/2013 11:59 AM, Andy Bierman wrote: > Hi, > > If an I2RS client wants to set up a tunnel between 2 routers > (as a lame example), does it send 1 request to 1 I2RS agent > or 2 requests, 1 to each I2RS agent/router? If 1 request, is the southbound > protocol between the I2RS agent and at least 1 router proprietary > or part of the standard? > > I think this draft should be clear about what is in scope. > It seems to say that the southbound protocol is out of scope. > > > Andy > > > On Sun, Jun 23, 2013 at 2:16 AM, Abdussalam Baryun > > wrote: > > I beleive if any thing not shown then they are not allowed by I2RS, if > it is shown then it is the way the I2RS will work to solve the > problem. So I will understand that I2RS client does not talk to NE but > only to the agent, that is why I suggest that we don't show any sign > that the client can talk to any other as long it is out of scope. > Therefore the drawing methodology (figure 1) is : (if out of scope of > the protocol then should not be shown, and if future work of protocol > it may be shown). > > AB > > On 6/22/13, Andy Bierman > wrote: > > Hi, > > > > I just re-read the framework and problem statement drafts. > > Only 1 minor issue in the problem statement draft: > > > > The 'I2RS Agent' is shown as a single box in figure 1. > > > > 1) Does this mean the protocol between the "broker" and the > > NEs is proprietary, or just not shown? > > > > 2) Does this mean that an I2RS Client never talks directly to an NE > > or does it mean all I2RS Agent functionality is available on > all NEs? > > > > Nit, sec. 6, para 4: > > - the lack of standard data models is the problem of the > NETMOD WG, > > not really the NETCONF protocol. > > - s/may help define needed/may require help defining needed/ > > > > > > Andy > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From andy@yumaworks.com Sun Jun 23 13:25:14 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE7D21F9C71 for ; Sun, 23 Jun 2013 13:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqNTE3KVVBnc for ; Sun, 23 Jun 2013 13:25:13 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id A44C921F9C38 for ; Sun, 23 Jun 2013 13:25:13 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so10129746pbb.28 for ; Sun, 23 Jun 2013 13:25:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=KApO7AW0OLGffZEs1UUr5aDIv406uSgFPKv2FR3Le38=; b=lVvdcajw5XhFTsetRUFEQl5ZG3DtHVxmXYpvEqrKTptjF0EDcHBLSLb9zISzAzSXtf aK7IIchm+6/agDjiYFSC5c10GsmMimTz2qfYDtNA2pT981Uwxm1ufivrdjADS9KZuVzI c59hZ6jMkc7JvzXTbYigsq1GdyUwrCEbI5eBhi/6xXTBa7yO7kU05NN2I+ikwImYPUOF lowAerEUhQ/KMX24CB3JWlW+r3rMf7jRFQkcMWXOktKmZ+2tLSJFM+UWljVvKWD2baNX BJ7V761ZSmwRpsjLRk0Mj7449TX7Wf3kDG8gV2bZ2cpStpvs89B3shRTbMuBHvC5rHJm uGmQ== MIME-Version: 1.0 X-Received: by 10.66.190.234 with SMTP id gt10mr25303365pac.136.1372019113404; Sun, 23 Jun 2013 13:25:13 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Sun, 23 Jun 2013 13:25:13 -0700 (PDT) In-Reply-To: <51C750CD.3080805@joelhalpern.com> References:

<51C750CD.3080805@joelhalpern.com> Date: Sun, 23 Jun 2013 13:25:13 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7bdc8c3ee13dc204dfd81758 X-Gm-Message-State: ALoCoQkIYkd9UBxx7BXEw9oXqdi2htXu+edHrdy+N2Jw1Hg0mcrC8J89lqrVS8Gto5fk2DXkzXd6 Cc: i2rs@ietf.org Subject: Re: [i2rs] standard interfaces within scope for I2RS X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 23 Jun 2013 20:25:14 -0000 --047d7bdc8c3ee13dc204dfd81758 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 23, 2013 at 12:47 PM, Joel M. Halpern wrote: > I think that the particular example you propose will onot help. > Some tunneling protocols only requrie action at one end to initiate a > bi-directional tunnel. I that case, presumably, the I2RS client would only > need to interact with that one end. Other protocols require action / > configuration at both ends to establish a bi-directional tunnel. In that > case, the i2rs client would need to interact with both ends. (And other > protocols are even stranger.) > > If your question is whether i2rs includes a protocol between i2rs agents > to coordinate action across boxes, separate from existing protocol > mechanisms, then I believe that the answer is a clear "no". There is is > agent-agent protocol in scope for the i2rs work. > > No, my question is how many I2Rs agents does a client need to contact to perform a task that requires changes on multiple routers? > Yours, > Joel > Andy > > On 6/23/2013 11:59 AM, Andy Bierman wrote: > >> Hi, >> >> If an I2RS client wants to set up a tunnel between 2 routers >> (as a lame example), does it send 1 request to 1 I2RS agent >> or 2 requests, 1 to each I2RS agent/router? If 1 request, is the >> southbound >> protocol between the I2RS agent and at least 1 router proprietary >> or part of the standard? >> >> I think this draft should be clear about what is in scope. >> It seems to say that the southbound protocol is out of scope. >> >> >> Andy >> >> >> On Sun, Jun 23, 2013 at 2:16 AM, Abdussalam Baryun >> >> >> wrote: >> >> I beleive if any thing not shown then they are not allowed by I2RS, if >> it is shown then it is the way the I2RS will work to solve the >> problem. So I will understand that I2RS client does not talk to NE but >> only to the agent, that is why I suggest that we don't show any sign >> that the client can talk to any other as long it is out of scope. >> Therefore the drawing methodology (figure 1) is : (if out of scope of >> the protocol then should not be shown, and if future work of protocol >> it may be shown). >> >> AB >> >> On 6/22/13, Andy Bierman > > wrote: >> > Hi, >> > >> > I just re-read the framework and problem statement drafts. >> > Only 1 minor issue in the problem statement draft: >> > >> > The 'I2RS Agent' is shown as a single box in figure 1. >> > >> > 1) Does this mean the protocol between the "broker" and the >> > NEs is proprietary, or just not shown? >> > >> > 2) Does this mean that an I2RS Client never talks directly to an >> NE >> > or does it mean all I2RS Agent functionality is available on >> all NEs? >> > >> > Nit, sec. 6, para 4: >> > - the lack of standard data models is the problem of the >> NETMOD WG, >> > not really the NETCONF protocol. >> > - s/may help define needed/may require help defining needed/ >> > >> > >> > Andy >> > >> >> >> >> >> ______________________________**_________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/**listinfo/i2rs >> >> --047d7bdc8c3ee13dc204dfd81758 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jun 23, 2013 at 12:47 PM, Joel M= . Halpern <jmh@joelhalpern.com> wrote:

I think that the particular example you propose will onot help.
Some tunneling protocols only requrie action at one end to initiate a bi-di= rectional tunnel. =A0I that case, presumably, the I2RS client would only ne= ed to interact with that one end. =A0Other protocols require action / confi= guration at both ends to establish a bi-directional tunnel. =A0In that case= , the i2rs client would need to interact with both ends. =A0(And other prot= ocols are even stranger.)

If your question is whether i2rs includes a protocol between i2rs agents to= coordinate action across boxes, separate from existing protocol mechanisms= , then I believe that the answer is a clear "no". =A0There is is = agent-agent protocol in scope for the i2rs work.

No, my question is how many I2Rs agent= s does a client need to

contact to perform a task that requires c= hanges on multiple routers?

=A0

Yours,
Joel

Andy

=A0

On 6/23/2013 11:59 AM, Andy Bierman wrote:

Hi,

If an I2RS client wants to set up a tunnel between 2 routers
(as a lame example), does it send 1 request to 1 I2RS agent
or 2 requests, 1 to each I2RS agent/router? =A0If 1 request, is the southbo= und
protocol between the I2RS agent and at least 1 router proprietary
or part of the standard?

I think this draft should be clear about what is in scope.
It seems to say that the southbound protocol is out of scope.

Andy

On Sun, Jun 23, 2013 at 2:16 AM, Abdussalam Baryun
<abdussa= lambaryun@gmail.com <mailto:abdussalambaryun@gmail.com>> wrote= :

=A0 =A0 I beleive if any thing not shown then they are not allowed by I2RS,= if
=A0 =A0 it is shown then it is the way the I2RS will work to solve the
=A0 =A0 problem. So I will understand that I2RS client does not talk to NE = but
=A0 =A0 only to the agent, that is why I suggest that we don't show any= sign
=A0 =A0 that the client can talk to any other as long it is out of scope. =A0 =A0 Therefore the drawing methodology (figure 1) is : (if out of scope = of
=A0 =A0 the protocol then should not be shown, and if future work of protoc= ol
=A0 =A0 it may be shown).

=A0 =A0 AB

=A0 =A0 On 6/22/13, Andy Bierman <andy@yumaworks.com
=A0 =A0 <mailto:= andy@yumaworks.com>> wrote:
=A0 =A0 =A0> Hi,
=A0 =A0 =A0>
=A0 =A0 =A0> I just re-read the framework and problem statement drafts.<= br> =A0 =A0 =A0> Only 1 minor issue in the problem statement draft:
=A0 =A0 =A0>
=A0 =A0 =A0> The 'I2RS Agent' is shown as a single box in figure= 1.
=A0 =A0 =A0>
=A0 =A0 =A0> =A01) Does this mean the protocol between the "broker&= quot; and the
=A0 =A0 =A0> =A0 =A0 =A0NEs is proprietary, or just not shown?
=A0 =A0 =A0>
=A0 =A0 =A0> =A02) Does this mean that an I2RS Client never talks direct= ly to an NE
=A0 =A0 =A0> =A0 =A0 =A0or does it mean all I2RS Agent functionality is = available on
=A0 =A0 all NEs?
=A0 =A0 =A0>
=A0 =A0 =A0> Nit, sec. 6, para 4:
=A0 =A0 =A0> =A0 =A0- the lack of standard data models is the problem of= the
=A0 =A0 NETMOD WG,
=A0 =A0 =A0> =A0 =A0 =A0not really the NETCONF protocol.
=A0 =A0 =A0> =A0 =A0- s/may help define needed/may require help defining= needed/
=A0 =A0 =A0>
=A0 =A0 =A0>
=A0 =A0 =A0> Andy
=A0 =A0 =A0>

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

--047d7bdc8c3ee13dc204dfd81758-- From adrian@olddog.co.uk Sun Jun 23 13:36:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C710921F9F43 for ; Sun, 23 Jun 2013 13:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QQKM9iu-v3d for ; Sun, 23 Jun 2013 13:36:00 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id A839A21F9F42 for ; Sun, 23 Jun 2013 13:35:59 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5NKZvwN008790; Sun, 23 Jun 2013 21:35:57 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5NKZumq008729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 23 Jun 2013 21:35:57 +0100 From: "Adrian Farrel" To: "'Andy Bierman'" , "'Joel M. Halpern'" References:

<51C750CD.3080805@joelhalpern.com> In-Reply-To: Date: Sun, 23 Jun 2013 21:35:54 +0100 Message-ID: <0b5801ce7051$42a62650$c7f272f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNy0/3J7a8BNu3XwdA+q93pfmN22QLyRWHQAmYmvfYBXXwPlQGcKV+RlbhoPyA= Content-Language: en-gb Cc: i2rs@ietf.org Subject: Re: [i2rs] standard interfaces within scope for I2RS X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 20:36:05 -0000 Andy, > my question is how many I2Rs agents does a client need to > contact to perform a task that requires changes on multiple routers? You probably won't like my answer "that depends". If the effect of the action on router 1 is to cause router 1 to use a routing/signaling protocol to make things happen in the network, then the answer may be 1. If the changes cannot be effected in that way, then the client may need to talk to multiple routers to make the different things happen on each router. And in between there lies the case of needing to touch some, but not all routers because other routers in between are worked on by signaling/routing. So the answer is 1 <= #agents <= #routers And that answer is modulo there being only one agent on each router :-) For (crass) examples of the above I give you: Set up an LSP using RSVP-TE (just talk to head-end router) Set up an end-to-end static route (talk to each router) Set up a multi-segment pseudo-wire (talk to the T-PEs and the S-PEs) Adrian From adrian@olddog.co.uk Sun Jun 23 13:54:53 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A153821F9F1D for ; Sun, 23 Jun 2013 13:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUYPip6VqYZc for ; Sun, 23 Jun 2013 13:54:46 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 75B3A21F9F11 for ; Sun, 23 Jun 2013 13:54:46 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5NKsiQM001468; Sun, 23 Jun 2013 21:54:44 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5NKsgmb001458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 23 Jun 2013 21:54:44 +0100 From: "Adrian Farrel" To: "'Andy Bierman'" References: In-Reply-To: Date: Sun, 23 Jun 2013 21:54:37 +0100 Message-ID: <0b5901ce7053$e2838670$a78a9350$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNy0/3J7a8BNu3XwdA+q93pfmN22ZX6/JAA Content-Language: en-gb Cc: i2rs@ietf.org Subject: Re: [i2rs] standard interfaces within scope for I2RS X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Interface to The Internet Routing System $IRS$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 20:54:53 -0000 Hi again Andy, Answering emails out of order and speaking for myself only... > I just re-read the framework and problem statement drafts. > Only 1 minor issue in the problem statement draft: > > The 'I2RS Agent' is shown as a single box in figure 1. > > =A01) Does this mean the protocol between the "broker" and the >=A0 =A0 =A0NEs is proprietary, or just not shown? I think "not shown" and "not considered for the moment". Walking before = we run would tend to suggest that we start with the case of a single client = talking to one or more agents in any single use case. The concept of brokering between multiple clients talking to the same = agent(s) is definitely something we should have in our architectural view, but it = makes sense (to me) to solve the first piece first and only be aware of the = looming problem of brokering without trying to solve it on day one. [That said, I should think in my naive protocol architect view of the = world, that the protocol from broker to agent would be the same as the protocol = from client to agent (because otherwise the agent will go mad), and that the = protocol from client to broker will be the same as the protocol from client to = agent (because otherwise the client will go mad). That means that the broker = is a form of proxy.] > =A02) Does this mean that an I2RS Client never talks directly to an NE >=A0 =A0 =A0or does it mean all I2RS Agent functionality is available on = all NEs? I don't know how to interpret "client never talks direct to an NE" = because I can't imagine putting the agent outside the NE. Maybe you are asking = whether the broker is always present between client and agent. If that is your = question, then my answer is a very strong "no". To the second part of the question, I can imagine that while each agent = will support the full protocol, it will not support all of the data model = components. Crudely, this is the same as MIB module support by different routers all = of which support SNMP. Ciao, Adrian From andy@yumaworks.com Sun Jun 23 14:11:44 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A18821F92EC for ; Sun, 23 Jun 2013 14:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p0hdIAdcesb for ; Sun, 23 Jun 2013 14:11:43 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 306E121F8F38 for ; Sun, 23 Jun 2013 14:11:43 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id xb12so10086375pbc.12 for ; Sun, 23 Jun 2013 14:11:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=2E8ZJWjSncvtB2CT1+tKRKVvp4Snw7tyfKIZNiRZnJw=; b=lcNhr8irb2/IgUM24bdvhoeRzwTmCi4h4Tgp2ixSjnzFIr1NjfWcxu0OnoPG+/w4IJ STg5R1vOc0AeNA5Kq/xv8spRDBBWgllMiIpvX4JLsaNHbTYHJRQSrVUokafS90tdKnh8 4WapwEzzMdFTdMNC5W6RXqMingXNMsW4pPcOv4CLf9BYxnIvJs5ca1w1p+1IEWDEaNIl 5paDRjHU3WVFcoFVAK0II7nLLb/e7GBMgVlxD+c8lVtOAom1GeYNxePvB5E81IMN45AS ppnTJhdXfGtzOhDkNQmszrgbYNqyvf3rCq20kmDXaj+kJP/UqnSogiWwsnNUgkKdQOlb q9KQ== MIME-Version: 1.0 X-Received: by 10.66.163.73 with SMTP id yg9mr23557104pab.77.1372021902927; Sun, 23 Jun 2013 14:11:42 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Sun, 23 Jun 2013 14:11:42 -0700 (PDT) In-Reply-To: <0b5801ce7051$42a62650$c7f272f0$@olddog.co.uk> References:

<51C750CD.3080805@joelhalpern.com> <0b5801ce7051$42a62650$c7f272f0$@olddog.co.uk> Date: Sun, 23 Jun 2013 14:11:42 -0700 Message-ID: From: Andy Bierman To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=047d7b86f75e25f84904dfd8be93 X-Gm-Message-State: ALoCoQm5x+CtyuOOwERI5Yw70w2HDXv6TJV/wShba1FEMPx4DEs6sEoP4LmFaf0F4sWPc5audXGq Cc: i2rs@ietf.org, "Joel M. Halpern" Subject: Re: [i2rs] standard interfaces within scope for I2RS X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 23 Jun 2013 21:11:44 -0000 --047d7b86f75e25f84904dfd8be93 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 23, 2013 at 1:35 PM, Adrian Farrel wrote: > Andy, > > > my question is how many I2Rs agents does a client need to > > contact to perform a task that requires changes on multiple routers? > > You probably won't like my answer "that depends". > > If the effect of the action on router 1 is to cause router 1 to use a > routing/signaling protocol to make things happen in the network, then the > answer > may be 1. > > If the changes cannot be effected in that way, then the client may need to > talk > to multiple routers to make the different things happen on each router. > > I meant a high-level task performed by the client that requires routing state to be manually injected on multiple routers, not via routing protocols. I am happy to consider the I2RS agent to be running on a single router and the I2RS client to be the network-level broker. The API to specific network-wide services topology or routing can be standardized next. IMO it is better to start with the core functionality that is expected on one device (for some definition of "core" the WG will agree on later). Andy And in between there lies the case of needing to touch some, but not all > routers > because other routers in between are worked on by signaling/routing. > > So the answer is 1 <= #agents <= #routers > > And that answer is modulo there being only one agent on each router :-) > > For (crass) examples of the above I give you: > > Set up an LSP using RSVP-TE (just talk to head-end router) > Set up an end-to-end static route (talk to each router) > Set up a multi-segment pseudo-wire (talk to the T-PEs and the S-PEs) > > Adrian > > --047d7b86f75e25f84904dfd8be93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jun 23, 2013 at 1:35 PM, Adrian = Farrel <adrian@olddog.co.uk> wrote:

Andy,

> my question is how many I2Rs agents does a client need to
> contact to perform a task that requires changes on multiple routers?
You probably won't like my answer "that depends".

If the effect of the action on router 1 is to cause router 1 to use a
routing/signaling protocol to make things happen in the network, then the a= nswer
may be 1.

If the changes cannot be effected in that way, then the client may need to = talk
to multiple routers to make the different things happen on each router.

I meant a high-level ta= sk performed by the client that requires

routing state to be manu= ally injected on multiple routers,

not via routing protocols.

I am happy to consider the I2RS agent to be running on = a single router

and the I2RS client to be the network-level broke= r. =A0The API to

specific network-wide services topology or routi= ng can be standardized next.

IMO it is better to start with the core functionality t= hat is expected on one device

(for some definition of "core&= quot; the WG will agree on later).

Andy

And in between there lies the case of needing to touch some, but not all ro= uters
because other routers in between are worked on by signaling/routing.

So the answer is 1 <=3D #agents <=3D #routers

And that answer is modulo there being only one agent on each router :-)

For (crass) examples of the above I give you:

Set up an LSP using RSVP-TE (just talk to head-end router)
Set up an end-to-end static route (talk to each router)
Set up a multi-segment pseudo-wire (talk to the T-PEs and the S-PEs)

Adrian

--047d7b86f75e25f84904dfd8be93-- From akatlas@gmail.com Tue Jun 25 07:08:28 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C16821E80BB for ; Tue, 25 Jun 2013 07:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ev7BfHMMJkO for ; Tue, 25 Jun 2013 07:08:27 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4B43721E80B5 for ; Tue, 25 Jun 2013 07:08:27 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so26062161iec.8 for ; Tue, 25 Jun 2013 07:08:26 -0700 (PDT) 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:cc :content-type; bh=6JkwITpJf365mp19fd2k7iNnFC10RSY2kiOofCqGws8=; b=SjuKXLJxLNv/OJdXLy7W6KFlFZ9IKFJYNgolDNs8fof3fXfuSHZhnpF4kFKnO+OfdJ m6sBAF0osmKZSDs1lZu/RRPibBx/h++dciMwj5Ccb7pem9+TjkRTpiytyn8xXJKNnB7k ktSfT2K5yzBbxLUSD3LS2CSTrRy29jlfKDThOf8/qfPCPBHCLnsC4i2RvLoaZsMNHt44 h5v+O1SMRzajQvJwlOhjJ19E2izjfOnhZc2DW4QX/yKSsnRRBbY8sguumzQnEw6Pd7Dr EpHh2zrbNAEeG3sqwb8fjGChzrHnuJ2q2R0qFCv8WK/NJeca4T0FqGE7MBZ1WwjZQrUS ntcA== MIME-Version: 1.0 X-Received: by 10.42.48.197 with SMTP id t5mt8294051icf.11.1372168890208; Tue, 25 Jun 2013 07:01:30 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Tue, 25 Jun 2013 07:01:30 -0700 (PDT) In-Reply-To: References:

<51C750CD.3080805@joelhalpern.com> <0b5801ce7051$42a62650$c7f272f0$@olddog.co.uk> Date: Tue, 25 Jun 2013 10:01:30 -0400 Message-ID: From: Alia Atlas Content-Type: multipart/alternative; boundary=90e6ba6e8e3e1cd18f04dffb1056 Cc: Adrian Farrel , "Joel M. Halpern" , "i2rs@ietf.org" Subject: Re: [i2rs] standard interfaces within scope for I2RS X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 14:08:28 -0000 --90e6ba6e8e3e1cd18f04dffb1056 Content-Type: text/plain; charset=ISO-8859-1 Hi Andy, Thanks very much for the feedback. In my view, I2RS is between the I2RS Agents and I2RS Clients. An I2RS Agent is associated with a single Routing element. The I2RS agent can communicate with many I2RS Clients; an I2RS client can talk to many I2RS agents. I don't think that an I2RS agent talks to other I2RS agents. A routing element might have an I2RS agent and an I2RS client associated with it. For instance, say there's a routing element that implements BGP and doesn't have a forwarding plane associated with it. The associated I2RS agent might support the BGP service. The associated I2RS client might be used to communicate to a different routing element for its RIB service. If a network application needs routing state at multiple routers, then I agree with Adrian. Either the i2RS client talks to each router individually or the I2RS client talks to a single router to trigger the distribution of the routing state (i.e. an RSVP-TE LSP, a prefix in OSPF, etc). I do hear you on the thoughts about a base core of functionalit y. What I'm picturing is that there are basically two types of info-models that we need to create. The first type are "per service" info models - where it applies to a particular routing functionality - whether BGP, OSPF, ISIS, RIB, PIM, RSVP-TE, etc. We could use a better term than the overloaded service - any suggestions? The second type will be I2RS protocol-related info-models. This might be to describe I2RS-related event notifications or to control the role of a client or to describe the capabilities of the I2RS agent in terms of what services it supplies. We haven't really touched on this part yet... Each routing element may provide a different set of services - and I don't think we can mandate what those are. It'll depend on the role of the routing element in the network. What I think we can require is a set of core I2RS protocol-related functionality - so that I2RS clients can learn what is supported, the associated capabilities, etc. Focusing on a few services at first, from a WG perspective, does make sense to me. I believe that is starting with the RIB information model and the topology information model. I think we need a simple BGP info model soon as well - though I'm not sure if that's being worked on yet. Regards, Alia On Sun, Jun 23, 2013 at 5:11 PM, Andy Bierman wrote: > > > On Sun, Jun 23, 2013 at 1:35 PM, Adrian Farrel wrote: > >> Andy, >> >> > my question is how many I2Rs agents does a client need to >> > contact to perform a task that requires changes on multiple routers? >> >> You probably won't like my answer "that depends". >> >> If the effect of the action on router 1 is to cause router 1 to use a >> routing/signaling protocol to make things happen in the network, then the >> answer >> may be 1. >> >> If the changes cannot be effected in that way, then the client may need >> to talk >> to multiple routers to make the different things happen on each router. >> >> > > I meant a high-level task performed by the client that requires > routing state to be manually injected on multiple routers, > not via routing protocols. > > I am happy to consider the I2RS agent to be running on a single router > and the I2RS client to be the network-level broker. The API to > specific network-wide services topology or routing can be standardized > next. > > IMO it is better to start with the core functionality that is expected on > one device > (for some definition of "core" the WG will agree on later). > > > Andy > > And in between there lies the case of needing to touch some, but not all >> routers >> because other routers in between are worked on by signaling/routing. >> >> So the answer is 1 <= #agents <= #routers >> >> And that answer is modulo there being only one agent on each router :-) >> >> For (crass) examples of the above I give you: >> >> Set up an LSP using RSVP-TE (just talk to head-end router) >> Set up an end-to-end static route (talk to each router) >> Set up a multi-segment pseudo-wire (talk to the T-PEs and the S-PEs) >> >> Adrian >> >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --90e6ba6e8e3e1cd18f04dffb1056 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Andy,

Thanks very much for the feedb= ack.

In my view, I2RS is between the I2RS Agents a= nd I2RS Clients. =A0An I2RS Agent is associated with a single Routing eleme= nt.

The I2RS agent can communicate with many I2RS Clients; an I2RS client = can talk to many I2RS agents. =A0 I don't think that an

I2RS = agent talks to other I2RS agents.

A routing elemen= t might have an I2RS agent and an I2RS client associated with it. =A0For in= stance, say there's a routing element

that implements BGP and doesn't have a forwarding plane associated= with it. =A0 The associated I2RS agent might support the BGP

ser= vice. =A0The associated I2RS client might be used to communicate to a diffe= rent routing element for its RIB service.

If a network application needs routing state at multipl= e routers, then I agree with Adrian. =A0Either the i2RS client talks to eac= h router

individually or the I2RS client talks to a single router= to trigger the distribution of the routing state (i.e. an RSVP-TE LSP, a p= refix in OSPF, etc).

I do hear you on the thoughts about a base core of func= tionalit y. =A0What I'm picturing is that there are basically two types= of info-models that

we need to create. =A0The first type are &qu= ot;per service" info models - where it applies to a particular routing= functionality - whether BGP, OSPF, ISIS, RIB, PIM, RSVP-TE, etc. =A0 We co= uld use a better term than the overloaded service - any suggestions? =A0

The second type will be I2RS protocol-related info-mode= ls. =A0This might be to describe I2RS-related event notifications or to con= trol the role of a client or to describe the capabilities of the I2RS agent= in terms of what services it supplies. =A0We haven't really touched on= this part yet...

Each routing element may provide a different set of ser= vices - and I don't think we can mandate what those are. =A0It'll d= epend on the role of the routing element in the network. =A0What I think we= can require is a set of core I2RS protocol-related functionality - so that= I2RS clients can learn what is supported, the associated capabilities, etc= .

Focusing on a few services at first, from a WG perspect= ive, does make sense to me. =A0I believe that is starting with the RIB info= rmation model and the topology information model. =A0I think we need a simp= le BGP info model soon as well - though I'm not sure if that's bein= g worked on yet.

Regards,

Alia

On = Sun, Jun 23, 2013 at 5:11 PM, Andy Bierman <andy@yumaworks.com> wrote:

On Sun, Jun 23, 2013 at 1:35 PM, Adrian Farrel &= lt;adrian@olddog.c= o.uk> wrote:

Andy,

> my question is how many I2Rs agents does a client need to
> contact to perform a task that requires changes on multiple routers?
You probably won't like my answer "that depends".

If the effect of the action on router 1 is to cause router 1 to use a
routing/signaling protocol to make things happen in the network, then the a= nswer
may be 1.

If the changes cannot be effected in that way, then the client may need to = talk
to multiple routers to make the different things happen on each router.

I meant a high-le= vel task performed by the client that requires
routing state to b= e manually injected on multiple routers,
not via routing protocol= s.

I am happy to consider the I2RS agent to be running on = a single router
and the I2RS client to be the network-level broke= r. =A0The API to
specific network-wide services topology or routi= ng can be standardized next.

IMO it is better to start with the core functionality t= hat is expected on one device
(for some definition of "core&= quot; the WG will agree on later).

Andy

And in between there lies the case of needing to touch some, but not all ro= uters
because other routers in between are worked on by signaling/routing.

So the answer is 1 <=3D #agents <=3D #routers

And that answer is modulo there being only one agent on each router :-)

For (crass) examples of the above I give you:

Set up an LSP using RSVP-TE (just talk to head-end router)
Set up an end-to-end static route (talk to each router)
Set up a multi-segment pseudo-wire (talk to the T-PEs and the S-PEs)

Adrian

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

--90e6ba6e8e3e1cd18f04dffb1056-- From nitinb@juniper.net Tue Jun 25 11:55:38 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA6121F99F7 for ; Tue, 25 Jun 2013 11:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2uewCJ1j0o0 for ; Tue, 25 Jun 2013 11:55:32 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 400E821F8319 for ; Tue, 25 Jun 2013 11:55:28 -0700 (PDT) Received: from mail214-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 18:55:22 +0000 Received: from mail214-ch1 (localhost [127.0.0.1]) by mail214-ch1-R.bigfish.com (Postfix) with ESMTP id B81072E00F4 for ; Tue, 25 Jun 2013 18:55:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I936eI1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail214-ch1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=nitinb@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail214-ch1 (localhost.localdomain [127.0.0.1]) by mail214-ch1 (MessageSwitch) id 1372186519971054_26044; Tue, 25 Jun 2013 18:55:19 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail214-ch1.bigfish.com (Postfix) with ESMTP id E8D211C0135 for ; Tue, 25 Jun 2013 18:55:19 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.52) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Jun 2013 18:55:17 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 25 Jun 2013 11:55:16 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 25 Jun 2013 11:55:16 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.251) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 25 Jun 2013 12:07:10 -0700 Received: from mail59-db9-R.bigfish.com (10.174.16.242) by DB9EHSOBE012.bigfish.com (10.174.14.75) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 18:55:14 +0000 Received: from mail59-db9 (localhost [127.0.0.1]) by mail59-db9-R.bigfish.com (Postfix) with ESMTP id 2ED4E1C015A for ; Tue, 25 Jun 2013 18:55:14 +0000 (UTC) Received: from mail59-db9 (localhost.localdomain [127.0.0.1]) by mail59-db9 (MessageSwitch) id 1372186511741997_17422; Tue, 25 Jun 2013 18:55:11 +0000 (UTC) Received: from DB9EHSMHS007.bigfish.com (unknown [10.174.16.252]) by mail59-db9.bigfish.com (Postfix) with ESMTP id B1B0B60233 for ; Tue, 25 Jun 2013 18:55:11 +0000 (UTC) Received: from SN2PRD0510HT002.namprd05.prod.outlook.com (157.56.234.117) by DB9EHSMHS007.bigfish.com (10.174.14.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Jun 2013 18:55:07 +0000 Received: from SN2PRD0510MB383.namprd05.prod.outlook.com ([169.254.10.159]) by SN2PRD0510HT002.namprd05.prod.outlook.com ([10.255.116.37]) with mapi id 14.16.0324.000; Tue, 25 Jun 2013 18:55:03 +0000 From: Nitin Bahadur To: "i2rs@ietf.org" Thread-Topic: New Version Notification for draft-nitinb-i2rs-rib-info-model-00.txt Thread-Index: AQHOcdRx/Y5SYYaBDUy8vzv3HpSkiZlGUfSA Date: Tue, 25 Jun 2013 18:55:03 +0000 Message-ID: In-Reply-To: <20130625184712.17390.40399.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.116.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <8778B59914A8224E9761840BA0DB2BDB@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 18:55:38 -0000 Folks, We have just posted an initial version of the RIB information model. Looking for feedback and collaborators who can help improve/add-to the draft. Thanks Nitin On 6/25/13 11:47 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-nitinb-i2rs-rib-info-model-00.txt >has been successfully submitted by Nitin Bahadur and posted to the >IETF repository. > >Filename: draft-nitinb-i2rs-rib-info-model >Revision: 00 >Title: Routing Information Base Info Model >Creation date: 2013-06-25 >Group: Individual Submission >Number of pages: 21 >URL: =20 >http://www.ietf.org/internet-drafts/draft-nitinb-i2rs-rib-info-model-00.tx >t >Status: =20 >http://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model >Htmlized: =20 >http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-00 > > >Abstract: > Routing and routing functions in enterprise and carrier networks are > typically performed by network devices (routers and switches) using a > routing information base (RIB). Protocols and configuration push > data into the RIB and the RIB manager install state into the > hardware; for packet forwarding. This draft specifies an information > model for the RIB, to build a standardized RIB model, using which an > external entity (external to the network device) can read and write > information from/to the RIB. > > =20 > =20 > > >The IETF Secretariat > > > From akatlas@gmail.com Tue Jun 25 12:05:48 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD6621F99BC for ; Tue, 25 Jun 2013 12:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnkumRO2x+tp for ; Tue, 25 Jun 2013 12:05:47 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 39BB321F9995 for ; Tue, 25 Jun 2013 12:05:47 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so29234456ieb.10 for ; Tue, 25 Jun 2013 12:05:46 -0700 (PDT) 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=RTvbAmsNNSq/ST3YWfZyJ+tKEf0QhFv95rHTYGBD96k=; b=pLB+Uux4rNagNIX0xzZ0bZ+sK70lJOpXNosOVVIiUo2P4vHy/DPOHgcce2XWvK+rZX J5qjkEWBoYCNCCu0CN8uXq3y14Uj2Es/1CqKCdIElLhBtUs2GQnJnJT+qlnSBkBcAwaa o6SII9bx9rlFp3OwC0Y6dIuxysECQ8OLWAwSwD7DvKWBdorqY6tKPZtsGJ0HwaseForo xFzeCv9CFfz2EykCJ9fWN/DHWPdh1+er3p2dooP/cDHzXHavGb9oJk4jqWq+FFTKSC8L OnYiih7JEpAHeIyIzAskgBJKszSpn1lFzzmv7r3ijkg0Hihpmbu9fUpYi7r5UGua+ebI LQ4A== MIME-Version: 1.0 X-Received: by 10.50.1.70 with SMTP id 6mr213031igk.54.1372187146727; Tue, 25 Jun 2013 12:05:46 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Tue, 25 Jun 2013 12:05:46 -0700 (PDT) In-Reply-To: References: <20130625184712.17390.40399.idtracker@ietfa.amsl.com> Date: Tue, 25 Jun 2013 15:05:46 -0400 Message-ID: From: Alia Atlas To: Nitin Bahadur Content-Type: multipart/alternative; boundary=047d7bd6c73072721504dfff3761 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2013 19:05:48 -0000 --047d7bd6c73072721504dfff3761 Content-Type: text/plain; charset=ISO-8859-1 Thanks for posting this! I look forward to lively discussion :-) Alia On Tue, Jun 25, 2013 at 2:55 PM, Nitin Bahadur wrote: > > Folks, > > We have just posted an initial version of the RIB information model. > Looking for feedback and collaborators who can help improve/add-to the > draft. > > Thanks > Nitin > > > On 6/25/13 11:47 AM, "internet-drafts@ietf.org" > wrote: > > > > >A new version of I-D, draft-nitinb-i2rs-rib-info-model-00.txt > >has been successfully submitted by Nitin Bahadur and posted to the > >IETF repository. > > > >Filename: draft-nitinb-i2rs-rib-info-model > >Revision: 00 > >Title: Routing Information Base Info Model > >Creation date: 2013-06-25 > >Group: Individual Submission > >Number of pages: 21 > >URL: > > > http://www.ietf.org/internet-drafts/draft-nitinb-i2rs-rib-info-model-00.tx > >t > >Status: > >http://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model > >Htmlized: > >http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-00 > > > > > >Abstract: > > Routing and routing functions in enterprise and carrier networks are > > typically performed by network devices (routers and switches) using a > > routing information base (RIB). Protocols and configuration push > > data into the RIB and the RIB manager install state into the > > hardware; for packet forwarding. This draft specifies an information > > model for the RIB, to build a standardized RIB model, using which an > > external entity (external to the network device) can read and write > > information from/to the RIB. > > > > > > > > > > > >The IETF Secretariat > > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7bd6c73072721504dfff3761 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks for posting this! =A0I look forward to lively discu= ssion :-)

Alia

On Tue, Jun 25, 2013 at 2:55 PM, Nitin Baha= dur <nitinb@juniper.net> wrote:

Folks,

=A0 We have just posted an initial version of the RIB information model. Looking for feedback and collaborators who can help improve/add-to the
draft.

Thanks
Nitin

On 6/25/13 11:47 AM, "inte= rnet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>A new version of I-D, draft-nitinb-i2rs-rib-info-model-00.txt
>has been successfully submitted by Nitin Bahadur and posted to the
>IETF repository.
>
>Filename: =A0 =A0 =A0 draft-nitinb-i2rs-rib-info-model
>Revision: =A0 =A0 =A0 00
>Title: =A0 =A0 =A0 =A0 =A0Routing Information Base Info Model
>Creation date: =A02013-06-25
>Group: =A0 =A0 =A0 =A0 =A0Individual Submission
>Number of pages: 21
>URL:
>http://www.ietf.org/internet-drafts/draft= -nitinb-i2rs-rib-info-model-00.tx
>t
>Status:
>http://datatracker.ietf.org/doc/draft-nitinb-i2rs-r= ib-info-model
>Htmlized:
>http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info= -model-00
>
>
>Abstract:
> =A0 Routing and routing functions in enterprise and carrier networks a= re
> =A0 typically performed by network devices (routers and switches) usin= g a
> =A0 routing information base (RIB). =A0Protocols and configuration pus= h
> =A0 data into the RIB and the RIB manager install state into the
> =A0 hardware; for packet forwarding. =A0This draft specifies an inform= ation
> =A0 model for the RIB, to build a standardized RIB model, using which = an
> =A0 external entity (external to the network device) can read and writ= e
> =A0 information from/to the RIB.
>
>
>
>
>
>The IETF Secretariat
>
>
>

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

--047d7bd6c73072721504dfff3761-- From abdussalambaryun@gmail.com Wed Jun 26 03:06:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7425B21F8FA1 for ; Wed, 26 Jun 2013 03:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8otB0n8wWtbo for ; Wed, 26 Jun 2013 03:06:04 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CDBFE21F90CD for ; Wed, 26 Jun 2013 03:06:04 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rl6so14031814pac.1 for ; Wed, 26 Jun 2013 03:06:04 -0700 (PDT) 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=+7/Ejh8xem9Di5SiXkNvwBwB190iXYOyMm07i7BB0OM=; b=NmD1GdYtMuMaqidQl8AT4dl6AtCIktv2jAPW8ba/IAF44vqK2BtGAbhsnF4wPpR6eM V+Ag1L7HHzMJk4DlED5wLBFujI2sd7FbHCAPkmdzlrYhGih+t2WMZmyRO/D3NSYGs0Fp R8boMRZir1Xj0i1tyo/Y05HoXTsZRASIvN6R64pbW4392Td7iTxN7QkUMSt+npaHC4e8 dtN/KKvXehRm1aFd+11w92jhz3uBriHVGaixxpaf/Mv7zGM1eVpJ5c6E6czk7pTBs6iA dsnmyZhfTWbV01voJr6xBCl0dQZF3Jrh6V0TK9KH4HWEISdEYcBLHxly8J0usifbrvZc Wj7Q== MIME-Version: 1.0 X-Received: by 10.68.103.194 with SMTP id fy2mr3159730pbb.158.1372241164597; Wed, 26 Jun 2013 03:06:04 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Wed, 26 Jun 2013 03:06:04 -0700 (PDT) In-Reply-To: References:

Date: Wed, 26 Jun 2013 12:06:04 +0200 Message-ID: From: Abdussalam Baryun To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org Subject: Re: [i2rs] standard interfaces within scope for I2RS X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 10:06:05 -0000 I agree with you Andy, I think the draft still is not clear, AB On 6/23/13, Andy Bierman wrote: > Hi, > > If an I2RS client wants to set up a tunnel between 2 routers > (as a lame example), does it send 1 request to 1 I2RS agent > or 2 requests, 1 to each I2RS agent/router? If 1 request, is the > southbound > protocol between the I2RS agent and at least 1 router proprietary > or part of the standard? > > I think this draft should be clear about what is in scope. > It seems to say that the southbound protocol is out of scope. > > > Andy > > > On Sun, Jun 23, 2013 at 2:16 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> I beleive if any thing not shown then they are not allowed by I2RS, if >> it is shown then it is the way the I2RS will work to solve the >> problem. So I will understand that I2RS client does not talk to NE but >> only to the agent, that is why I suggest that we don't show any sign >> that the client can talk to any other as long it is out of scope. >> Therefore the drawing methodology (figure 1) is : (if out of scope of >> the protocol then should not be shown, and if future work of protocol >> it may be shown). >> >> AB >> >> On 6/22/13, Andy Bierman wrote: >> > Hi, >> > >> > I just re-read the framework and problem statement drafts. >> > Only 1 minor issue in the problem statement draft: >> > >> > The 'I2RS Agent' is shown as a single box in figure 1. >> > >> > 1) Does this mean the protocol between the "broker" and the >> > NEs is proprietary, or just not shown? >> > >> > 2) Does this mean that an I2RS Client never talks directly to an NE >> > or does it mean all I2RS Agent functionality is available on all >> NEs? >> > >> > Nit, sec. 6, para 4: >> > - the lack of standard data models is the problem of the NETMOD WG, >> > not really the NETCONF protocol. >> > - s/may help define needed/may require help defining needed/ >> > >> > >> > Andy >> > >> > From manav.bhatia@alcatel-lucent.com Wed Jun 26 03:09:55 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C818121E80F9 for ; Wed, 26 Jun 2013 03:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjDn5lrbjdP7 for ; Wed, 26 Jun 2013 03:09:49 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABA521E80B9 for ; Wed, 26 Jun 2013 03:09:48 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r5QA9kId023762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Jun 2013 05:09:46 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r5QA9TUb031372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Jun 2013 06:09:45 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 26 Jun 2013 06:09:28 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Wed, 26 Jun 2013 18:09:21 +0800 From: "Bhatia, Manav (Manav)" To: "i2rs@ietf.org" Thread-Topic: Nexthops in draft-nitinb-i2rs-rib-info-model-00.txt Thread-Index: Ac5yVTsExrezKDI7SjSxsyhUF0u1xg== Date: Wed, 26 Jun 2013 10:09:21 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C3066052@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [i2rs] Nexthops in draft-nitinb-i2rs-rib-info-model-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 10:09:55 -0000 Hi, I believe we are missing two nexthops that are quite extensively used. 1. nexthop for which the associated ARP is in the stale state. These are sp= ecial nexthops in the sense that in addition to forwarding traffic we must = punt a copy to CPU so that the ARP can be refreshed. 2. nexthops associated IP interfaces created over vlans or VPLS services (e= xtensively used). In this case the local route needs to point to a set of l= ogical or virtual interfaces. 3. In Sec 2.4.5 the second bullet says: "DISCARD_WITH_ERROR: This indicates that the network device should drop the= packet, increment a drop counter and send back an appropriate error messag= e (like ICMP error)." Whats the ICMP error message that is being referred to here? Cheers, Manav From lhotka@nic.cz Wed Jun 26 05:43:31 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932D711E81B5 for ; Wed, 26 Jun 2013 05:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWRLbjrQSdDu for ; Wed, 26 Jun 2013 05:43:27 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 889F911E80E6 for ; Wed, 26 Jun 2013 05:43:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 140EC540385; Wed, 26 Jun 2013 14:43:18 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OClOf1mrM-9; Wed, 26 Jun 2013 14:42:59 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id A8E3B540165; Wed, 26 Jun 2013 14:42:54 +0200 (CEST) From: Ladislav Lhotka To: Nitin Bahadur , "i2rs\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Date: Wed, 26 Jun 2013 14:42:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 12:43:31 -0000 Hi, this work, or at least its general parts, is closely related to the following work item of the NETMOD WG: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09 I tried to compare these two documents, and IMO the match is pretty good. Paradoxically, the match would be even better if we take one of the previous revisions of the routing-cfg documents because some constraints that were originally present have been relaxed in the meantime (details follow). I think it would make a good sense to coordinate these two efforts, and it should't be difficult. Specific comments: 1. What you call "routing instance" is very similar to "router (instance)" in routing-cfg. Interfaces are also assigned to each router instance, but we don't require (since rev. -03) that the sets of interfaces assigned to different router instances be disjoint. One use case is that two router instances may be used for different address families, e.g., instance A for IPv4 and B for IPv6. Then the same interface may be used in A for IPv4 traffic and in B for IPv6. Perhaps this also depends on the definition of "interface". 2. Until rev. -05, each routing table was also confined to one router instance. This was relaxed based on the following comment of a Routing Directorate reviewer (Thomas Morin): "Allowing multiple "routers" is a good starting point for using these specs in the context of RFC4364 (MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the way the filters are defined would not work in the context of RFC4364, where a BGP routing instance in the master "router" exports selected routes in each of the routing table of each VPN (VRF). The VRF also export routes to the master instance." 3. Route attributes, nexthops etc., as specified in draft-nitinb-i2rs-rib-info-model-00, can be easily added into the YANG data model via augmentation. We expect this will be done by future YANG modules defining data models for routing protocols, such as BGP. For example, an entry like your ISO_SYSTEM_ID can be augmented by an IS-IS module. 4. The data model in routing-cfg doesn't define any event notifications yet, though I think there have already been some proposal. I think we can add the two that you mention in sec. 5. 5. Routing tables can be inspected in the same way as other operational state data, i.e., via the standard NETCONF operation . However, we also have two special RPC operations: o active-route: query the routing system for the active route(s) that are currently used for sending datagrams to a destination host whose address is passed as an input parameter. o route-count: retrieve the total number of entries in a routing table. Cheers, Lada Nitin Bahadur writes: > Folks, > > We have just posted an initial version of the RIB information model. > Looking for feedback and collaborators who can help improve/add-to the > draft. > > Thanks > Nitin > > > On 6/25/13 11:47 AM, "internet-drafts@ietf.org" > wrote: > >> >>A new version of I-D, draft-nitinb-i2rs-rib-info-model-00.txt >>has been successfully submitted by Nitin Bahadur and posted to the >>IETF repository. >> >>Filename: draft-nitinb-i2rs-rib-info-model >>Revision: 00 >>Title: Routing Information Base Info Model >>Creation date: 2013-06-25 >>Group: Individual Submission >>Number of pages: 21 >>URL: >>http://www.ietf.org/internet-drafts/draft-nitinb-i2rs-rib-info-model-00.tx >>t >>Status: >>http://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model >>Htmlized: >>http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-00 >> >> >>Abstract: >> Routing and routing functions in enterprise and carrier networks are >> typically performed by network devices (routers and switches) using a >> routing information base (RIB). Protocols and configuration push >> data into the RIB and the RIB manager install state into the >> hardware; for packet forwarding. This draft specifies an information >> model for the RIB, to build a standardized RIB model, using which an >> external entity (external to the network device) can read and write >> information from/to the RIB. >> >> >> >> >> >>The IETF Secretariat >> >> >> > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From akatlas@gmail.com Wed Jun 26 06:01:47 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0A221F999A for ; Wed, 26 Jun 2013 06:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gry6WMv3-I+4 for ; Wed, 26 Jun 2013 06:01:46 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id C67A611E81BB for ; Wed, 26 Jun 2013 06:01:46 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id ar20so30813019iec.21 for ; Wed, 26 Jun 2013 06:01:46 -0700 (PDT) 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=MxrYhBn7zJ8oipb0riXijpS82fwE3gjKQA5grIF05VU=; b=x8/VftOfDyYlp6VjwtCMUKxYeY76YVvP3d3qyd3N8zfVOgYY6KGJdEDsX//uxA5df2 yqHGRlaqTgZjVd9Jo4FrVR/PwfaJBQ2U9l6kJQL2vydMn/GsutNZtFv/LpZ/0aTYXohX WwATOvI0hOV4Cq4waZ3tH4UrzDEQXroWA3zYeSsePBPgzw90bxF69xToshEVOKwwtZ6m GJa/M/yfDndQqfoSwJ8hfInLir5t7NVbZqf6TazG6xLovdiJFYu5f2Ob2bm8Q1mIIY1+ 7BxlOvJmsA61iukZJAcd+2UrXbtY9bG/Gq46k0vN0lCB0v6ic/XU9z3816tuo8ECFCpN AOaw== MIME-Version: 1.0 X-Received: by 10.43.12.198 with SMTP id pj6mr2162260icb.68.1372251706314; Wed, 26 Jun 2013 06:01:46 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Wed, 26 Jun 2013 06:01:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Jun 2013 09:01:46 -0400 Message-ID: From: Alia Atlas To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=bcaec518701c7f5a9d04e00e3f32 Cc: "i2rs@ietf.org" , Nitin Bahadur Subject: Re: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 13:01:48 -0000 --bcaec518701c7f5a9d04e00e3f32 Content-Type: text/plain; charset=ISO-8859-1 Hi Lada, The draft you mention is certainly of interest - particularly if I2RS requirements for a data modeling language result in selecting YANG. A couple quick points on your comments though. The next-hops are largely the POINT of this info-model. The organization into route-tables and then route-instances allow different ones to be applied to different interfaces and such. So, saying that the nexthops can be easily added via augmentation is saying that a very key feature is not yet there. Similarly, the event notifications are also a key point of the info-model ; that is how different i2rs clients can learn dynamic information. Having a comparison and thinking about how to extend the existing YANG model is certainly interesting - but I think it's important to get and agree on the info-model first. It's also clear that there are large critical aspects that are missing and needed (from the I2RS perspective). Alia On Wed, Jun 26, 2013 at 8:42 AM, Ladislav Lhotka wrote: > Hi, > > this work, or at least its general parts, is closely related to the > following work item of the NETMOD WG: > > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09 > > I tried to compare these two documents, and IMO the match is pretty good. > Paradoxically, the match would be even better if we take one of the > previous revisions of the routing-cfg documents because some constraints > that were originally present have been relaxed in the meantime (details > follow). > > I think it would make a good sense to coordinate these two efforts, and it > should't be difficult. > > Specific comments: > > 1. What you call "routing instance" is very similar to "router (instance)" > in routing-cfg. Interfaces are also assigned to each router instance, but > we don't require (since rev. -03) that the sets of interfaces assigned to > different router instances be disjoint. One use case is that two router > instances may be used for different address families, e.g., instance A for > IPv4 and B for IPv6. Then the same interface may be used in A for IPv4 > traffic and in B for IPv6. Perhaps this also depends on the definition of > "interface". > > 2. Until rev. -05, each routing table was also confined to one router > instance. This was relaxed based on the following comment of a Routing > Directorate reviewer (Thomas Morin): > > "Allowing multiple "routers" is a good starting point for using these > specs in the context of RFC4364 > (MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the > way the filters are defined would > not work in the context of RFC4364, where a BGP routing instance in the > master "router" exports selected > routes in each of the routing table of each VPN (VRF). The VRF also > export routes to the master > instance." > > 3. Route attributes, nexthops etc., as specified in > draft-nitinb-i2rs-rib-info-model-00, can be easily added into the YANG data > model via augmentation. We expect this will be done by future YANG modules > defining data models for routing protocols, such as BGP. For example, an > entry like your ISO_SYSTEM_ID can be augmented by an IS-IS module. > > 4. The data model in routing-cfg doesn't define any event notifications > yet, though I think there have already been some proposal. I think we can > add the two that you mention in sec. 5. > > 5. Routing tables can be inspected in the same way as other operational > state data, i.e., via the standard NETCONF operation . However, we > also have two special RPC operations: > > o active-route: query the routing system for the active route(s) > that are currently used for sending datagrams to a destination > host whose address is passed as an input parameter. > > o route-count: retrieve the total number of entries in a routing > table. > > > Cheers, Lada > > > Nitin Bahadur writes: > > > Folks, > > > > We have just posted an initial version of the RIB information model. > > Looking for feedback and collaborators who can help improve/add-to the > > draft. > > > > Thanks > > Nitin > > > > > > On 6/25/13 11:47 AM, "internet-drafts@ietf.org" < > internet-drafts@ietf.org> > > wrote: > > > >> > >>A new version of I-D, draft-nitinb-i2rs-rib-info-model-00.txt > >>has been successfully submitted by Nitin Bahadur and posted to the > >>IETF repository. > >> > >>Filename: draft-nitinb-i2rs-rib-info-model > >>Revision: 00 > >>Title: Routing Information Base Info Model > >>Creation date: 2013-06-25 > >>Group: Individual Submission > >>Number of pages: 21 > >>URL: > >> > http://www.ietf.org/internet-drafts/draft-nitinb-i2rs-rib-info-model-00.tx > >>t > >>Status: > >>http://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model > >>Htmlized: > >>http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-00 > >> > >> > >>Abstract: > >> Routing and routing functions in enterprise and carrier networks are > >> typically performed by network devices (routers and switches) using a > >> routing information base (RIB). Protocols and configuration push > >> data into the RIB and the RIB manager install state into the > >> hardware; for packet forwarding. This draft specifies an information > >> model for the RIB, to build a standardized RIB model, using which an > >> external entity (external to the network device) can read and write > >> information from/to the RIB. > >> > >> > >> > >> > >> > >>The IETF Secretariat > >> > >> > >> > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --bcaec518701c7f5a9d04e00e3f32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Lada,

The draft you mention is certa= inly of interest - particularly if I2RS requirements for a data modeling la= nguage result in selecting YANG.

A couple quick po= ints on your comments though.

The next-hops are largely the POINT of this info-model.= =A0 The organization into route-tables and then route-instances allow diff= erent ones to be applied to different interfaces and such. =A0So, saying th= at the nexthops can be easily added via augmentation is saying that a very = key feature is not yet there. =A0Similarly, the event notifications are als= o a key point of the info-model ; that is how different i2rs clients can le= arn dynamic information.

Having a comparison and thinking about how to extend th= e existing YANG model is certainly interesting - but I think it's impor= tant to get and agree on the info-model first.=A0

It's also clear that there are large critical aspects that are missing = and needed (from the I2RS perspective).

Alia

On Wed,= Jun 26, 2013 at 8:42 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:=

Hi,

this work, or at least its general parts, is closely related to the followi= ng work item of the NETMOD WG:

http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09<= /a>

I tried to compare these two documents, and IMO the match is pretty good. P= aradoxically, the match would be even better if we take one of the previous= revisions of the routing-cfg documents because some constraints that were = originally present have been relaxed in the meantime (details follow).

I think it would make a good sense to coordinate these two efforts, and it = should't be difficult.

Specific comments:

1. What you call "routing instance" is very similar to "rout= er (instance)" in routing-cfg. Interfaces are also assigned to each ro= uter instance, but we don't require (since rev. -03) that the sets of i= nterfaces assigned to different router instances be disjoint. One use case = is that two router instances may be used for different address families, e.= g., instance A for IPv4 and B for IPv6. Then the same interface may be used= in A for IPv4 traffic and in B for IPv6. Perhaps this also depends on the = definition of "interface".

2. Until rev. -05, each routing table was also confined to one router insta= nce. This was relaxed based on the following comment of a Routing Directora= te reviewer (Thomas Morin):

"Allowing multiple "routers" is a good starting point for us= ing these specs in the context of RFC4364
(MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the way= the filters are defined would
not work in the context of RFC4364, where a BGP routing instance in the mas= ter "router" exports selected
routes in each of the routing table of each VPN (VRF). =A0The VRF also expo= rt routes to the master
instance."

3. Route attributes, nexthops etc., as specified in draft-nitinb-i2rs-rib-i= nfo-model-00, can be easily added into the YANG data model via augmentation= . We expect this will be done by future YANG modules defining data models f= or routing protocols, such as BGP. For example, an entry like your ISO_SYST= EM_ID can be augmented by an IS-IS module.

4. The data model in routing-cfg doesn't define any event notifications= yet, though I think there have already been some proposal. I think we can = add the two that you mention in sec. 5.

5. Routing tables can be inspected in the same way as other operational sta= te data, i.e., via the standard NETCONF operation <get>. However, we = also have two special RPC operations:

=A0 =A0o =A0active-route: query the routing system for the active route(s)<= br> =A0 =A0 =A0 that are currently used for sending datagrams to a destination<= br> =A0 =A0 =A0 host whose address is passed as an input parameter.

=A0 =A0o =A0route-count: retrieve the total number of entries in a routing<= br> =A0 =A0 =A0 table.

Cheers, Lada

Nitin Bahadur <nitinb@juniper.net<= /a>> writes:

> Folks,
>
> =A0 We have just posted an initial version of the RIB information mode= l.
> Looking for feedback and collaborators who can help improve/add-to the=
> draft.
>
> Thanks
> Nitin
>
>
> On 6/25/13 11:47 AM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> wrote:
>
>>
>>A new version of I-D, draft-nitinb-i2rs-rib-info-model-00.txt
>>has been successfully submitted by Nitin Bahadur and posted to the<= br> >>IETF repository.
>>
>>Filename: =A0 =A0 =A0draft-nitinb-i2rs-rib-info-model
>>Revision: =A0 =A0 =A000
>>Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Routing Information Base Inf= o Model
>>Creation date: =A0 =A0 =A0 =A0 2013-06-25
>>Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
>>Number of pages: 21
>>URL:
>>http://www.ietf.org/internet-drafts/d= raft-nitinb-i2rs-rib-info-model-00.tx
>>t
>>Status:
>>http://datatracker.ietf.org/doc/draft-nitinb-i2= rs-rib-info-model
>>Htmlized:
>>http://tools.ietf.org/html/draft-nitinb-i2rs-rib-= info-model-00
>>
>>
>>Abstract:
>> =A0 Routing and routing functions in enterprise and carrier networ= ks are
>> =A0 typically performed by network devices (routers and switches) = using a
>> =A0 routing information base (RIB). =A0Protocols and configuration= push
>> =A0 data into the RIB and the RIB manager install state into the >> =A0 hardware; for packet forwarding. =A0This draft specifies an in= formation
>> =A0 model for the RIB, to build a standardized RIB model, using wh= ich an
>> =A0 external entity (external to the network device) can read and = write
>> =A0 information from/to the RIB.
>>
>>
>>
>>
>>
>>The IETF Secretariat
>>
>>
>>
>
>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

--bcaec518701c7f5a9d04e00e3f32-- From lhotka@nic.cz Wed Jun 26 07:20:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0B01F0D33 for ; Wed, 26 Jun 2013 07:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dduU9CMCMcs for ; Wed, 26 Jun 2013 07:20:46 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 98F021F0D39 for ; Wed, 26 Jun 2013 07:20:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 99657540385; Wed, 26 Jun 2013 16:20:38 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umscd2QeYnwF; Wed, 26 Jun 2013 16:20:34 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 99526540165; Wed, 26 Jun 2013 16:20:20 +0200 (CEST) From: Ladislav Lhotka To: Alia Atlas In-Reply-To: References: User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Date: Wed, 26 Jun 2013 16:20:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "i2rs@ietf.org" , Nitin Bahadur Subject: Re: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 14:20:50 -0000 Hi Alia, Alia Atlas writes: > Hi Lada, > > The draft you mention is certainly of interest - particularly if I2RS > requirements for a data modeling language result in selecting YANG. > > A couple quick points on your comments though. > > The next-hops are largely the POINT of this info-model. The organization > into route-tables and then route-instances allow different ones to be > applied to different interfaces and such. So, saying that the nexthops can > be easily added via augmentation is saying that a very key feature is not > yet there. Similarly, the event notifications are also a key point of the > info-model ; that is how different i2rs clients can learn dynamic > information. As I said, the two notifications will be added in the next revision. However, it is important to note that, by design, the data model in routing-cfg is mainly a skeleton or framework providing placeholders for real stuff (routing protocol or route filter data) to be filled in. As a proof of concept, I can certainly try to write a YANG module that augments the specific items defined in i2rs-rib-info-model, should you find this exercise useful. > > Having a comparison and thinking about how to extend the existing YANG > model is certainly interesting - but I think it's important to get and > agree on the info-model first. The text of the routing-cfg draft in fact presents an information model, and in a very similar structure as the present draft (routing/router instances, routing tables, routes, but in addition also routing protocol instances and route filters). I think we should be able to agree on a common information model, even if the I2RS WG decides to use something else than YANG for data modelling. > > It's also clear that there are large critical aspects that are missing and > needed (from the I2RS perspective). >From the NETMOD perspective, these critical aspects are eagerly waiting to be augmented into the existing YANG data model. :-) Lada > > Alia > > > On Wed, Jun 26, 2013 at 8:42 AM, Ladislav Lhotka wrote: > >> Hi, >> >> this work, or at least its general parts, is closely related to the >> following work item of the NETMOD WG: >> >> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09 >> >> I tried to compare these two documents, and IMO the match is pretty good. >> Paradoxically, the match would be even better if we take one of the >> previous revisions of the routing-cfg documents because some constraints >> that were originally present have been relaxed in the meantime (details >> follow). >> >> I think it would make a good sense to coordinate these two efforts, and it >> should't be difficult. >> >> Specific comments: >> >> 1. What you call "routing instance" is very similar to "router (instance)" >> in routing-cfg. Interfaces are also assigned to each router instance, but >> we don't require (since rev. -03) that the sets of interfaces assigned to >> different router instances be disjoint. One use case is that two router >> instances may be used for different address families, e.g., instance A for >> IPv4 and B for IPv6. Then the same interface may be used in A for IPv4 >> traffic and in B for IPv6. Perhaps this also depends on the definition of >> "interface". >> >> 2. Until rev. -05, each routing table was also confined to one router >> instance. This was relaxed based on the following comment of a Routing >> Directorate reviewer (Thomas Morin): >> >> "Allowing multiple "routers" is a good starting point for using these >> specs in the context of RFC4364 >> (MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the >> way the filters are defined would >> not work in the context of RFC4364, where a BGP routing instance in the >> master "router" exports selected >> routes in each of the routing table of each VPN (VRF). The VRF also >> export routes to the master >> instance." >> >> 3. Route attributes, nexthops etc., as specified in >> draft-nitinb-i2rs-rib-info-model-00, can be easily added into the YANG data >> model via augmentation. We expect this will be done by future YANG modules >> defining data models for routing protocols, such as BGP. For example, an >> entry like your ISO_SYSTEM_ID can be augmented by an IS-IS module. >> >> 4. The data model in routing-cfg doesn't define any event notifications >> yet, though I think there have already been some proposal. I think we can >> add the two that you mention in sec. 5. >> >> 5. Routing tables can be inspected in the same way as other operational >> state data, i.e., via the standard NETCONF operation . However, we >> also have two special RPC operations: >> >> o active-route: query the routing system for the active route(s) >> that are currently used for sending datagrams to a destination >> host whose address is passed as an input parameter. >> >> o route-count: retrieve the total number of entries in a routing >> table. >> >> >> Cheers, Lada >> >> >> Nitin Bahadur writes: >> >> > Folks, >> > >> > We have just posted an initial version of the RIB information model. >> > Looking for feedback and collaborators who can help improve/add-to the >> > draft. >> > >> > Thanks >> > Nitin >> > >> > >> > On 6/25/13 11:47 AM, "internet-drafts@ietf.org" < >> internet-drafts@ietf.org> >> > wrote: >> > >> >> >> >>A new version of I-D, draft-nitinb-i2rs-rib-info-model-00.txt >> >>has been successfully submitted by Nitin Bahadur and posted to the >> >>IETF repository. >> >> >> >>Filename: draft-nitinb-i2rs-rib-info-model >> >>Revision: 00 >> >>Title: Routing Information Base Info Model >> >>Creation date: 2013-06-25 >> >>Group: Individual Submission >> >>Number of pages: 21 >> >>URL: >> >> >> http://www.ietf.org/internet-drafts/draft-nitinb-i2rs-rib-info-model-00.tx >> >>t >> >>Status: >> >>http://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model >> >>Htmlized: >> >>http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-00 >> >> >> >> >> >>Abstract: >> >> Routing and routing functions in enterprise and carrier networks are >> >> typically performed by network devices (routers and switches) using a >> >> routing information base (RIB). Protocols and configuration push >> >> data into the RIB and the RIB manager install state into the >> >> hardware; for packet forwarding. This draft specifies an information >> >> model for the RIB, to build a standardized RIB model, using which an >> >> external entity (external to the network device) can read and write >> >> information from/to the RIB. >> >> >> >> >> >> >> >> >> >> >> >>The IETF Secretariat >> >> >> >> >> >> >> > >> > >> > >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> _______________________________________________ >> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From akatlas@gmail.com Wed Jun 26 07:57:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936A01F0D37 for ; Wed, 26 Jun 2013 07:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weHTSaLqK-gl for ; Wed, 26 Jun 2013 07:57:04 -0700 (PDT) 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 0948921F9AE5 for ; Wed, 26 Jun 2013 07:57:03 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so31366829iea.18 for ; Wed, 26 Jun 2013 07:57:03 -0700 (PDT) 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=QOMu5TDL0/Asu6dvxoOCN89Zb2BWiOqoBvObhBrHIHQ=; b=EQP+IerKFTIwMZxegFmfD0t+pMTWNY+VZk4a+YHon4Hl6/kMINLb8xNaQ4I3N2Dobv 4iKHn1aUbjGJtKUTRJmxPqo7KIVgIQ5Cf1r7VQENmgkqLZVX+DQ7aMuyFpaxXiKHSSlo DzDd2cuwTDL1Oix95QSzOnL3A1JMf+XtVaQgLhzHRdNCHRf2q1BNVovZuCJQ9Np64r5e 2tB59FWsmM0vezBIdYyoAh0dPgXsuSwIcm8WnC+esk6hCB9eyA36LE1Po0r+o63o7UDb ZoU0/EQ3YaqqTcOLn77fuamySOpDHAnRv+FzCkv8lpYxBQF8wv+EOwIJMSB70JPMe8++ D7ZA== MIME-Version: 1.0 X-Received: by 10.43.0.67 with SMTP id nl3mr2489538icb.2.1372258623531; Wed, 26 Jun 2013 07:57:03 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Wed, 26 Jun 2013 07:57:03 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Jun 2013 10:57:03 -0400 Message-ID: From: Alia Atlas To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=bcaec511e1b6cbb90804e00fdb42 Cc: "i2rs@ietf.org" , Nitin Bahadur Subject: Re: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 14:57:05 -0000 --bcaec511e1b6cbb90804e00fdb42 Content-Type: text/plain; charset=ISO-8859-1 Lada, Your enthusiasm is awesome - and I totally agree on trying for a common info-model! I just don't want to assume that everything has to be expressed in the hierarchy of YANG. I think that Joel had some opinions on the different expressiveness in different data-models. It's likely that the RIB info-model is a good place to start exploring that and helping to derive requirements. I do think that the RIB info-model isn't expecting the "real-stuff" to come from elsewhere - but rather is expressing this particular layer fully. Before you start trying to write a YANG module to do the augmentation, you probably want to touch base with Nitin and see where he is on that (other than on Pacific Time). Regards, Alia On Wed, Jun 26, 2013 at 10:20 AM, Ladislav Lhotka wrote: > Hi Alia, > > Alia Atlas writes: > > > Hi Lada, > > > > The draft you mention is certainly of interest - particularly if I2RS > > requirements for a data modeling language result in selecting YANG. > > > > A couple quick points on your comments though. > > > > The next-hops are largely the POINT of this info-model. The > organization > > into route-tables and then route-instances allow different ones to be > > applied to different interfaces and such. So, saying that the nexthops > can > > be easily added via augmentation is saying that a very key feature is not > > yet there. Similarly, the event notifications are also a key point of > the > > info-model ; that is how different i2rs clients can learn dynamic > > information. > > As I said, the two notifications will be added in the next revision. > However, it is important to note that, by design, the data model in > routing-cfg is mainly a skeleton or framework providing placeholders for > real stuff (routing protocol or route filter data) to be filled in. As a > proof of concept, I can certainly try to write a YANG module that augments > the specific items defined in i2rs-rib-info-model, should you find this > exercise useful. > > > > > Having a comparison and thinking about how to extend the existing YANG > > model is certainly interesting - but I think it's important to get and > > agree on the info-model first. > > The text of the routing-cfg draft in fact presents an information model, > and in a very similar structure as the present draft (routing/router > instances, routing tables, routes, but in addition also routing protocol > instances and route filters). I think we should be able to agree on a > common information model, even if the I2RS WG decides to use something else > than YANG for data modelling. > > > > > It's also clear that there are large critical aspects that are missing > and > > needed (from the I2RS perspective). > > From the NETMOD perspective, these critical aspects are eagerly waiting to > be augmented into the existing YANG data model. :-) > > Lada > > > > > Alia > > > > > > On Wed, Jun 26, 2013 at 8:42 AM, Ladislav Lhotka wrote: > > > >> Hi, > >> > >> this work, or at least its general parts, is closely related to the > >> following work item of the NETMOD WG: > >> > >> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09 > >> > >> I tried to compare these two documents, and IMO the match is pretty > good. > >> Paradoxically, the match would be even better if we take one of the > >> previous revisions of the routing-cfg documents because some constraints > >> that were originally present have been relaxed in the meantime (details > >> follow). > >> > >> I think it would make a good sense to coordinate these two efforts, and > it > >> should't be difficult. > >> > >> Specific comments: > >> > >> 1. What you call "routing instance" is very similar to "router > (instance)" > >> in routing-cfg. Interfaces are also assigned to each router instance, > but > >> we don't require (since rev. -03) that the sets of interfaces assigned > to > >> different router instances be disjoint. One use case is that two router > >> instances may be used for different address families, e.g., instance A > for > >> IPv4 and B for IPv6. Then the same interface may be used in A for IPv4 > >> traffic and in B for IPv6. Perhaps this also depends on the definition > of > >> "interface". > >> > >> 2. Until rev. -05, each routing table was also confined to one router > >> instance. This was relaxed based on the following comment of a Routing > >> Directorate reviewer (Thomas Morin): > >> > >> "Allowing multiple "routers" is a good starting point for using these > >> specs in the context of RFC4364 > >> (MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the > >> way the filters are defined would > >> not work in the context of RFC4364, where a BGP routing instance in the > >> master "router" exports selected > >> routes in each of the routing table of each VPN (VRF). The VRF also > >> export routes to the master > >> instance." > >> > >> 3. Route attributes, nexthops etc., as specified in > >> draft-nitinb-i2rs-rib-info-model-00, can be easily added into the YANG > data > >> model via augmentation. We expect this will be done by future YANG > modules > >> defining data models for routing protocols, such as BGP. For example, an > >> entry like your ISO_SYSTEM_ID can be augmented by an IS-IS module. > >> > >> 4. The data model in routing-cfg doesn't define any event notifications > >> yet, though I think there have already been some proposal. I think we > can > >> add the two that you mention in sec. 5. > >> > >> 5. Routing tables can be inspected in the same way as other operational > >> state data, i.e., via the standard NETCONF operation . However, we > >> also have two special RPC operations: > >> > >> o active-route: query the routing system for the active route(s) > >> that are currently used for sending datagrams to a destination > >> host whose address is passed as an input parameter. > >> > >> o route-count: retrieve the total number of entries in a routing > >> table. > >> > >> > >> Cheers, Lada > >> > >> > >> Nitin Bahadur writes: > >> > >> > Folks, > >> > > >> > We have just posted an initial version of the RIB information model. > >> > Looking for feedback and collaborators who can help improve/add-to the > >> > draft. > >> > > >> > Thanks > >> > Nitin > >> > > >> > > >> > On 6/25/13 11:47 AM, "internet-drafts@ietf.org" < > >> internet-drafts@ietf.org> > >> > wrote: > >> > > >> >> > >> >>A new version of I-D, draft-nitinb-i2rs-rib-info-model-00.txt > >> >>has been successfully submitted by Nitin Bahadur and posted to the > >> >>IETF repository. > >> >> > >> >>Filename: draft-nitinb-i2rs-rib-info-model > >> >>Revision: 00 > >> >>Title: Routing Information Base Info Model > >> >>Creation date: 2013-06-25 > >> >>Group: Individual Submission > >> >>Number of pages: 21 > >> >>URL: > >> >> > >> > http://www.ietf.org/internet-drafts/draft-nitinb-i2rs-rib-info-model-00.tx > >> >>t > >> >>Status: > >> >>http://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model > >> >>Htmlized: > >> >>http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-00 > >> >> > >> >> > >> >>Abstract: > >> >> Routing and routing functions in enterprise and carrier networks > are > >> >> typically performed by network devices (routers and switches) > using a > >> >> routing information base (RIB). Protocols and configuration push > >> >> data into the RIB and the RIB manager install state into the > >> >> hardware; for packet forwarding. This draft specifies an > information > >> >> model for the RIB, to build a standardized RIB model, using which > an > >> >> external entity (external to the network device) can read and write > >> >> information from/to the RIB. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >>The IETF Secretariat > >> >> > >> >> > >> >> > >> > > >> > > >> > > >> > _______________________________________________ > >> > i2rs mailing list > >> > i2rs@ietf.org > >> > https://www.ietf.org/mailman/listinfo/i2rs > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> _______________________________________________ > >> 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --bcaec511e1b6cbb90804e00fdb42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Lada,

Your enthusiasm is awesome = - and I totally agree on trying for a common info-model! =A0I just don'= t want to assume that everything has to be expressed in the hierarchy of YA= NG. =A0I think that Joel had some opinions on the different expressiveness = in different data-models. =A0 It's likely that the RIB info-model is a = good place to start exploring that and helping to derive requirements.

I do think that the RIB info-model isn'= t expecting the "real-stuff" to come from elsewhere - but rather = is expressing this particular layer fully.

Before you start trying to write a YANG module to do the augmentation, you = probably want to touch base with Nitin and see where he is on that (other t= han on Pacific Time).

Regards,

Alia

On Wed, Jun 26, 2013 at 10:20 AM, Ladislav Lhotka <lhotka@nic.= cz> wrote:

Hi Alia,

Alia Atlas <akatlas@gmail.com&g= t; writes:

> Hi Lada,
>
> The draft you mention is certainly of interest - particularly if I2RS<= br> > requirements for a data modeling language result in selecting YANG. >
> A couple quick points on your comments though.
>
> The next-hops are largely the POINT of this info-model. =A0 The organi= zation
> into route-tables and then route-instances allow different ones to be<= br> > applied to different interfaces and such. =A0So, saying that the nexth= ops can
> be easily added via augmentation is saying that a very key feature is = not
> yet there. =A0Similarly, the event notifications are also a key point = of the
> info-model ; that is how different i2rs clients can learn dynamic
> information.

As I said, the two notifications will be added in the next revision. = However, it is important to note that, by design, the data model in routing= -cfg is mainly a skeleton or framework providing placeholders for real stuf= f (routing protocol or route filter data) to be filled in. As a proof of co= ncept, I can certainly try to write a YANG module that augments the specifi= c items defined in i2rs-rib-info-model, should you find this exercise usefu= l.

>
> Having a comparison and thinking about how to extend the existing YANG=
> model is certainly interesting - but I think it's important to get= and
> agree on the info-model first.

The text of the routing-cfg draft in fact presents an information mod= el, and in a very similar structure as the present draft (routing/router in= stances, routing tables, routes, but in addition also routing protocol inst= ances and route filters). I think we should be able to agree on a common in= formation model, even if the I2RS WG decides to use something else than YAN= G for data modelling.

>
> It's also clear that there are large critical aspects that are mis= sing and
> needed (from the I2RS perspective).

From the NETMOD perspective, these critical aspects are eagerly waiti= ng to be augmented into the existing YANG data model. :-)

Lada

>
> Alia
>
>
> On Wed, Jun 26, 2013 at 8:42 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Hi,
>>
>> this work, or at least its general parts, is closely related to th= e
>> following work item of the NETMOD WG:
>>
>> http://tools.ietf.org/html/draft-ietf-netmod-routin= g-cfg-09
>>
>> I tried to compare these two documents, and IMO the match is prett= y good.
>> Paradoxically, the match would be even better if we take one of th= e
>> previous revisions of the routing-cfg documents because some const= raints
>> that were originally present have been relaxed in the meantime (de= tails
>> follow).
>>
>> I think it would make a good sense to coordinate these two efforts= , and it
>> should't be difficult.
>>
>> Specific comments:
>>
>> 1. What you call "routing instance" is very similar to &= quot;router (instance)"
>> in routing-cfg. Interfaces are also assigned to each router instan= ce, but
>> we don't require (since rev. -03) that the sets of interfaces = assigned to
>> different router instances be disjoint. One use case is that two r= outer
>> instances may be used for different address families, e.g., instan= ce A for
>> IPv4 and B for IPv6. Then the same interface may be used in A for = IPv4
>> traffic and in B for IPv6. Perhaps this also depends on the defini= tion of
>> "interface".
>>
>> 2. Until rev. -05, each routing table was also confined to one rou= ter
>> instance. This was relaxed based on the following comment of a Rou= ting
>> Directorate reviewer (Thomas Morin):
>>
>> "Allowing multiple "routers" is a good starting poi= nt for using these
>> specs in the context of RFC4364
>> (MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax= , the
>> way the filters are defined would
>> not work in the context of RFC4364, where a BGP routing instance i= n the
>> master "router" exports selected
>> routes in each of the routing table of each VPN (VRF). =A0The VRF = also
>> export routes to the master
>> instance."
>>
>> 3. Route attributes, nexthops etc., as specified in
>> draft-nitinb-i2rs-rib-info-model-00, can be easily added into the = YANG data
>> model via augmentation. We expect this will be done by future YANG= modules
>> defining data models for routing protocols, such as BGP. For examp= le, an
>> entry like your ISO_SYSTEM_ID can be augmented by an IS-IS module.=
>>
>> 4. The data model in routing-cfg doesn't define any event noti= fications
>> yet, though I think there have already been some proposal. I think= we can
>> add the two that you mention in sec. 5.
>>
>> 5. Routing tables can be inspected in the same way as other operat= ional
>> state data, i.e., via the standard NETCONF operation <get>. = However, we
>> also have two special RPC operations:
>>
>> =A0 =A0o =A0active-route: query the routing system for the active = route(s)
>> =A0 =A0 =A0 that are currently used for sending datagrams to a des= tination
>> =A0 =A0 =A0 host whose address is passed as an input parameter. >>
>> =A0 =A0o =A0route-count: retrieve the total number of entries in a= routing
>> =A0 =A0 =A0 table.
>>
>>
>> Cheers, Lada
>>
>>
>> Nitin Bahadur <nitinb@jun= iper.net> writes:
>>
>> > Folks,
>> >
>> > =A0 We have just posted an initial version of the RIB informa= tion model.
>> > Looking for feedback and collaborators who can help improve/a= dd-to the
>> > draft.
>> >
>> > Thanks
>> > Nitin
>> >
>> >
>> > On 6/25/13 11:47 AM, "internet-drafts@ietf.org" <
>> internet-drafts@ietf.o= rg>
>> > wrote:
>> >
>> >>
>> >>A new version of I-D, draft-nitinb-i2rs-rib-info-model-00.= txt
>> >>has been successfully submitted by Nitin Bahadur and poste= d to the
>> >>IETF repository.
>> >>
>> >>Filename: =A0 =A0 =A0draft-nitinb-i2rs-rib-info-model
>> >>Revision: =A0 =A0 =A000
>> >>Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Routing Information= Base Info Model
>> >>Creation date: =A0 =A0 =A0 =A0 2013-06-25
>> >>Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submissi= on
>> >>Number of pages: 21
>> >>URL:
>> >>
>> http://www.ietf.org/internet-drafts/= draft-nitinb-i2rs-rib-info-model-00.tx
>> >>t
>> >>Status:
>> >>http://datatracker.ietf.org/doc/draft-= nitinb-i2rs-rib-info-model
>> >>Htmlized:
>> >>http://tools.ietf.org/html/draft-nitinb-= i2rs-rib-info-model-00
>> >>
>> >>
>> >>Abstract:
>> >> =A0 Routing and routing functions in enterprise and carri= er networks are
>> >> =A0 typically performed by network devices (routers and s= witches) using a
>> >> =A0 routing information base (RIB). =A0Protocols and conf= iguration push
>> >> =A0 data into the RIB and the RIB manager install state i= nto the
>> >> =A0 hardware; for packet forwarding. =A0This draft specif= ies an information
>> >> =A0 model for the RIB, to build a standardized RIB model,= using which an
>> >> =A0 external entity (external to the network device) can = read and write
>> >> =A0 information from/to the RIB.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>The IETF Secretariat
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> > _______________________________________________
>> > i2rs mailing list
>> > i2rs@ietf.org
>> > https://www.ietf.org/mailman/listinfo/i2rs
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> _______________________________________________
>> 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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--bcaec511e1b6cbb90804e00fdb42-- From nitinb@juniper.net Wed Jun 26 10:57:43 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C23E11E8113 for ; Wed, 26 Jun 2013 10:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdM-YHm8tU8Y for ; Wed, 26 Jun 2013 10:57:36 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 736F911E80F5 for ; Wed, 26 Jun 2013 10:57:33 -0700 (PDT) Received: from mail149-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 17:57:33 +0000 Received: from mail149-tx2 (localhost [127.0.0.1]) by mail149-tx2-R.bigfish.com (Postfix) with ESMTP id 64E54A0340 for ; Wed, 26 Jun 2013 17:57:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail149-tx2: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=nitinb@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail149-tx2 (localhost.localdomain [127.0.0.1]) by mail149-tx2 (MessageSwitch) id 1372269431648995_18138; Wed, 26 Jun 2013 17:57:11 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.230]) by mail149-tx2.bigfish.com (Postfix) with ESMTP id 9B1C62A01B6 for ; Wed, 26 Jun 2013 17:57:11 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Jun 2013 17:57:11 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 26 Jun 2013 10:57:10 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 26 Jun 2013 10:57:09 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.13) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 26 Jun 2013 11:01:25 -0700 Received: from mail66-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 17:57:09 +0000 Received: from mail66-tx2 (localhost [127.0.0.1]) by mail66-tx2-R.bigfish.com (Postfix) with ESMTP id 374BD340288 for ; Wed, 26 Jun 2013 17:57:09 +0000 (UTC) Received: from mail66-tx2 (localhost.localdomain [127.0.0.1]) by mail66-tx2 (MessageSwitch) id 1372269399717663_17490; Wed, 26 Jun 2013 17:56:39 +0000 (UTC) Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.244]) by mail66-tx2.bigfish.com (Postfix) with ESMTP id 9F7BC4A0096; Wed, 26 Jun 2013 17:56:39 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Jun 2013 17:56:39 +0000 Received: from SN2PRD0510MB383.namprd05.prod.outlook.com ([169.254.10.159]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0324.000; Wed, 26 Jun 2013 17:56:38 +0000 From: Nitin Bahadur To: "Bhatia, Manav (Manav)" , "i2rs@ietf.org" Thread-Topic: [i2rs] Nexthops in draft-nitinb-i2rs-rib-info-model-00.txt Thread-Index: Ac5yVTsExrezKDI7SjSxsyhUF0u1xgABpeAA Date: Wed, 26 Jun 2013 17:56:38 +0000 Message-ID: In-Reply-To: <20211F91F544D247976D84C5D778A4C3066052@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.116.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8F10BF151D6BFA479B8B26CB8D096935@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [i2rs] Nexthops in draft-nitinb-i2rs-rib-info-model-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 17:57:43 -0000 Hi Manav, > >I believe we are missing two nexthops that are quite extensively used. > >1. nexthop for which the associated ARP is in the stale state. These are >special nexthops in the sense that in addition to forwarding traffic we >must punt a copy to CPU so that the ARP can be refreshed. NB> The RIB model deals with Layer-3 and above information (for the most part). Handling of L2 state machine is beyond the scope of this document (IMO)=8A.just like handling of OSPF state machine is outside the scope of this document. If a ARP entry becomes unresolved, then the nexthop becomes unresolved and the i2rs agent needs to notify the controller of next hop being unresolved. Internally the network device needs to do whatever it does to refresh the ARP entry. This special nexthop is part of the internal FSM on the network device. Note that we are not trying to build a controller that controls each and every thing on the network device. If we were building that, then what you are suggesting needs to be done. > >2. nexthops associated IP interfaces created over vlans or VPLS services >(extensively used). In this case the local route needs to point to a set >of logical or virtual interfaces. NB> A tunnel identifier needs to be added=8A.I had it an earlier revision o= f the draft and removed it by mistake. > >3. In Sec 2.4.5 the second bullet says: > >"DISCARD_WITH_ERROR: This indicates that the network device should drop >the packet, increment a drop counter and send back an appropriate error >message (like ICMP error)." > >Whats the ICMP error message that is being referred to here? NB> Examples include ICMP_REDIRECT or ICMP Destination Unreachable. Exact specifics needs to go in data-model. Thanks Nitin From nitinb@juniper.net Wed Jun 26 11:11:07 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FDD21F93D4 for ; Wed, 26 Jun 2013 11:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYKnaU02fecY for ; Wed, 26 Jun 2013 11:11:01 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE4511E81DE for ; Wed, 26 Jun 2013 11:10:55 -0700 (PDT) Received: from mail170-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE025.bigfish.com (10.243.66.88) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 18:10:55 +0000 Received: from mail170-co1 (localhost [127.0.0.1]) by mail170-co1-R.bigfish.com (Postfix) with ESMTP id 19BD26C0251 for ; Wed, 26 Jun 2013 18:10:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz15bfK1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail170-co1: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=nitinb@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail170-co1 (localhost.localdomain [127.0.0.1]) by mail170-co1 (MessageSwitch) id 1372270252743983_30883; Wed, 26 Jun 2013 18:10:52 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.233]) by mail170-co1.bigfish.com (Postfix) with ESMTP id A9256860047 for ; Wed, 26 Jun 2013 18:10:52 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Jun 2013 18:10:50 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 26 Jun 2013 11:10:49 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 26 Jun 2013 11:10:48 -0700 Received: from DB8EHSOBE031.bigfish.com (213.199.154.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 26 Jun 2013 11:15:03 -0700 Received: from mail23-db8-R.bigfish.com (10.174.8.250) by DB8EHSOBE031.bigfish.com (10.174.4.94) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 18:10:46 +0000 Received: from mail23-db8 (localhost [127.0.0.1]) by mail23-db8-R.bigfish.com (Postfix) with ESMTP id 552E2400E3 for ; Wed, 26 Jun 2013 18:10:46 +0000 (UTC) Received: from mail23-db8 (localhost.localdomain [127.0.0.1]) by mail23-db8 (MessageSwitch) id 1372270244773443_22396; Wed, 26 Jun 2013 18:10:44 +0000 (UTC) Received: from DB8EHSMHS015.bigfish.com (unknown [10.174.8.253]) by mail23-db8.bigfish.com (Postfix) with ESMTP id AD244C80046; Wed, 26 Jun 2013 18:10:44 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by DB8EHSMHS015.bigfish.com (10.174.4.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 26 Jun 2013 18:10:39 +0000 Received: from SN2PRD0510MB383.namprd05.prod.outlook.com ([169.254.10.159]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0324.000; Wed, 26 Jun 2013 18:10:30 +0000 From: Nitin Bahadur To: Ladislav Lhotka , "i2rs@ietf.org" Thread-Topic: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-00.txt Thread-Index: AQHOcdRx/Y5SYYaBDUy8vzv3HpSkiZlGUfSAgAGfsID//+Y5gA== Date: Wed, 26 Jun 2013 18:10:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.116.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%NIC.CZ$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2013 18:11:07 -0000 Hi Ladislav, >this work, or at least its general parts, is closely related to the >following work item of the NETMOD WG: > >http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09 Yes. I agree and I've been aware of this document all along. >I tried to compare these two documents, and IMO the match is pretty good. >Paradoxically, the match would be even better if we take one of the >previous revisions of the routing-cfg documents because some constraints >that were originally present have been relaxed in the meantime (details >follow). > >I think it would make a good sense to coordinate these two efforts, and >it should't be difficult. Agree again. > >Specific comments: > >1. What you call "routing instance" is very similar to "router >(instance)" in routing-cfg. Interfaces are also assigned to each router >instance, but we don't require (since rev. -03) that the sets of >interfaces assigned to different router instances be disjoint. One use >case is that two router instances may be used for different address >families, e.g., instance A for IPv4 and B for IPv6. Then the same >interface may be used in A for IPv4 traffic and in B for IPv6. Perhaps >this also depends on the definition of "interface". Interface is not address family specific. It's not clear why one would need 2 router instances, one per address type. The way I've been modeling this is how I've seen customers use interfaces. They associate all features with a given interface as part of one domain. So everything related to a given GigE interface (like routes, VPNs, etc) are managed in a wholesome way. >2. Until rev. -05, each routing table was also confined to one router >instance. This was relaxed based on the following comment of a Routing >Directorate reviewer (Thomas Morin): > >"Allowing multiple "routers" is a good starting point for using these >specs in the context of RFC4364 >(MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the >way the filters are defined would >not work in the context of RFC4364, where a BGP routing instance in the >master "router" exports selected >routes in each of the routing table of each VPN (VRF). The VRF also >export routes to the master >instance." IMO this is the export-import policy stuff (that I left out on purpose in rev -00). IMO, import-export between tables in different router instances should be supported/allowed. But that does not mean the tables need to be in multiple router instances. Based on your knowledge of Yang, do you think it's not possible to define import-export of routes between tables in different instances? Rest of your comments were data-model specific, which I will defer for now (we'll take that up on a separate thread). Thanks Nitin From sriganeshkini@gmail.com Wed Jun 26 12:09:23 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C16C11E8133 for ; Wed, 26 Jun 2013 12:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhqUVLWkt5fo for ; Wed, 26 Jun 2013 12:09:22 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1694C11E812E for ; Wed, 26 Jun 2013 12:09:21 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id r11so1662510lbv.13 for ; Wed, 26 Jun 2013 12:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=UsPdyMdMaINCU0JZ7E8za2KV5gs/Evpc8CTs+ei70Ck=; b=WUAKb5jUgq7nkxjQ/fKZFi5MVPIuegXd4KJ1P+AX9vhsaJgH/LdEsUHxKZhBXwsjsq Fv75O0uZco55Fr5z7YCf8Wvdc7iu+3muxbQpXML4sqH2axhgAR70hstpOtWLxp0a3BMR /SD312TrVkdApLcNBM1cCzp1vjiWt7PCSQIEyanqva9vg23FbadIbSI/Tm4NCMrX9/9e FP/dV6a/Kz5KrzOR/thY0U8/8F7ipm5qhDguYJTbKqbTIcOkOSjgDhXZFMUVgYBYr13U IQnfPazzdi1pi22/GUEhH+wv6KGtGEPeB4rbmvZjESpPbEwIGOrX+gt57H41mfpADIWQ 7+iw== X-Received: by 10.152.21.99 with SMTP id u3mr2591335lae.18.1372273759767; Wed, 26 Jun 2013 12:09:19 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.114.161.2 with HTTP; Wed, 26 Jun 2013 12:08:49 -0700 (PDT) In-Reply-To: References: <20211F91F544D247976D84C5D778A4C3066052@SG70YWXCHMBA05.zap.alcatel-lucent.com> From: Sriganesh Kini Date: Wed, 26 Jun 2013 12:08:49 -0700 X-Google-Sender-Auth: DAgSfNy62hkGX7_VQwAhIOGy_rE Message-ID: To: Nitin Bahadur Content-Type: multipart/alternative; boundary=089e0149397afc529304e01361dc Cc: "i2rs@ietf.org"