Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

From: [email-masked]
Date: Sun, 22 Nov 2015 23:15:58 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Interface to the Routing System Working Group of the IETF.

        Title           : A YANG Data Model for Routing Information Base (RIB)
        Authors         : Lixing Wang
                          Hariharan Ananthakrishnan
                          Mach(Guoyi) Chen
                          Amit Dass
                          Sriganesh Kini
                          Nitin Bahadur
	Filename        : draft-ietf-i2rs-rib-data-model-04.txt
	Pages           : 65
	Date            : 2015-11-22

Abstract:
   This document defines a YANG data model for Routing Information Base
   (RIB) that aligns with the I2RS RIB information model.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-data-model-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mach Chen <[email-masked]>
Date: Mon, 23 Nov 2015 07:23:01 +0000

Hi,

We just uploaded an update that addresses the comments received (include online and offline) recently. Please review the draft and comment!

Thanks,
Mach

> -----Original Message-----
> From: i2rs [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, November 23, 2015 3:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt
> 
> 
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 23 Nov 2015 19:56:15 +0000

Hi Mach, 

I’m looking at draft-ietf-i2rs-rib-data-model-04.txt and it still includes
all the tunnel encaps. I know you received several comments that those
should be in the tunnel model(s) and this I2RS RIB model should merely
reference an imported tunnel abstraction. How are you going to address
this? It seemed that the consensus (and an opinion that I share) was that
this model should not attempt to generically created tunnels via RIB/FIB
entries. 
Thanks,
Acee

On 11/23/15, 2:23 AM, "i2rs on behalf of Mach Chen" <[email-masked]
on behalf of [email-masked]> wrote:

>Hi,
>
>We just uploaded an update that addresses the comments received (include
>online and offline) recently. Please review the draft and comment!
>
>Thanks,
>Mach
>
>>  This draft is a work item of the Interface to the Routing System
>>Working Group
>> of the IETF.
>>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 23 Nov 2015 21:27:22 +0000

Hi Mach,

I agree with Acee’s comments and would encourage you to use generic/existing tunnel model(s), please see comments provided during RTGWG meeting in Yokohama.
There are already too many, we need to rationalize this work.

This is what has been discussed in Yokohama, Robin presented

-- draft-li-rtgwg-utunnel-yang
   -- draft-li-rtgwg-tunnel-policy-yang
   -- draft-wwz-netmod-yang-tunnel-cfg
   -- draft-zheng-intarea-gre-yang
   -- draft-liu-intarea-gre-tunnel-yang
   -- draft-liu-intarea-ipipv4-tunnel-yang

Cheers,
Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Nov 2015 17:33:22 -0500

Jeff and Acee: 

Your suggested change goes against the WG adopted RIB Information draft that has been discussed for over 2 years.  The informational draft has been through WG LC and you did not make any suggestions or comments during the WG LC.  Any change of this matter is not simply something you indicate to the authors, but needs to be discussed on the WG as a direction change for the RIB IM/DM models. 

Prior to moving this change through WG adoption cycle, the routing architectural team needs to have: a) concrete proposal for the ephemeral state that covers I2RS RIB and https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/  and  b) I requested this input of Acee Lindem as a representative of the routing architecture team.    

I will be glad to work with you on a concrete proposal that you can send to the email list and present at the I2RS interim meeting on 12/16/2015 (10-11:30am ET). 

 Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; [email-masked]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Hi Mach,

Cheers,

Jeff

 

>I’m looking at draft-ietf-i2rs-rib-data-model-04.txt and it still 

>includes all the tunnel encaps. I know you received several comments 

>that those should be in the tunnel model(s) and this I2RS RIB model 

>should merely reference an imported tunnel abstraction. How are you 

>going to address this? It seemed that the consensus (and an opinion 

>that I share) was that this model should not attempt to generically 

>created tunnels via RIB/FIB entries.

>On 11/23/15, 2:23 AM, "i2rs on behalf of Mach Chen" 

>< <mailto:[email-masked][email-masked]> [email-masked] on behalf of [email-masked]> wrote:

>>We just uploaded an update that addresses the comments received 

>>(include online and offline) recently. Please review the draft and comment!

>>> From: i2rs [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of 

>>> <mailto:[email-masked]> [email-masked]

>>> To:  <mailto:[email-masked]> [email-masked]

>>> Cc:  <mailto:[email-masked]> [email-masked]

>>> A New Internet-Draft is available from the on-line Internet-Drafts 

>>>directories.

>>>Working Group  of the IETF.

>>>         Title           : A YANG Data Model for Routing Information Base

>>> (RIB)

>>>  <https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/> https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/

>>>  <https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04> https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-04

>>>  <https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-data-model-04> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-data-model-04

>>> Please note that it may take a couple of minutes from the time of 

>>>submission  until the htmlized version and diff are available at 

>>>tools.ietf.org.

>>>  <ftp://ftp.ietf.org/internet-drafts/> ftp://ftp.ietf.org/internet-drafts/

>>>  <mailto:[email-masked]> [email-masked]

>>>  <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs

>> <mailto:[email-masked]> [email-masked]

>> <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs

> <mailto:[email-masked]> [email-masked]

> <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs

i2rs mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Nov 2015 17:45:12 -0500

Resending to I2RS WG. 

From: Susan Hares [mailto:[email-masked]] 
Sent: Monday, November 23, 2015 5:33 PM
To: 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; [email-masked]'
Cc: 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise (bclaise)'
Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Jeff and Acee: 

 Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; [email-masked]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Hi Mach,

Cheers,

Jeff

 

i2rs mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 24 Nov 2015 00:29:45 +0000

Sue,

From: i2rs <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 23, 2015 at 5:45 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Resending to I2RS WG.

To: 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; [email-masked]<mailto:[email-masked]>'

Jeff and Acee:

Independent of the I2RS efforts, milestones, and processes, I think we need to address whether provisioning all these tunnels via RIB installation is  appropriate and, additionally, consistent with other WG YANG models. In many cases, it would seem there are tunnel attributes other than the encaps that need to be provisioned. At a minimum, I think you’d need to either reference an RFC describing soft tunnel provisioning or describe the specifics of this provisioning.

The  identification of this problem with tunnel provisioning is a direct outcome of this effort.

I will continue to work on ietf-routing alignment but don’t have the bandwidth for the above.

Acee

 Sue Hares

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Hi Mach,

Cheers,

Jeff

><[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

>>> From: i2rs [mailto:[email-masked]] On Behalf Of

>>>[email-masked]<mailto:[email-masked]>

>>> To: [email-masked]<mailto:[email-masked]>

>>> Cc: [email-masked]<mailto:[email-masked]>

>>> [email-masked]<mailto:[email-masked]>

>>[email-masked]<mailto:[email-masked]>

>[email-masked]<mailto:[email-masked]>

i2rs mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 23 Nov 2015 21:57:02 -0500

Acee: 

Is your input individual input or input from the routing architecture for yang models? 

<I2RS chair hat on> 

The routing architecture for yang models is incomplete without the consideration of the I2RS ephemeral state and I2RS architecture.  Asking the I2RS WG to change a document that is in WG LC based on an incomplete architectural document is not reasonable.  An alignment between  <https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ without the consideration of the I2RS ephemeral state is an incomplete alignment and a problematic  approach for I2RS WG’s efforts.   

In a volunteer organization, each person has the right to makes choices in what they have time to do.   If you do not have bandwidth to provide an adequate routing architecture for yang models that considers ephemeral state or its needs, that is your choice.  Unless you have a concrete proposal for the ephemeral state that covers I2RS RIB and  <https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/, the I2RS WG LC will be closed after 2 week (11/23 – 12/7) WG review of the in draft-ietf-i2rs-rib-data-model-04.txt.     

Please remember that the I2RS RIB model has two parts:  I2RS Informational Model and I2RS Data Model.  The I2RS Informational Model and the I2RS Data Model have descriptions on the soft tunnel provisioning as mechanisms.  Questions at this point must demonstrate a knowledge of these documents or suggest specific changes to the documents.   If you wish to raise the following questions, please do this in light of specific sections that include both the I2RS Informational Model, the I2RS Data Model, and I2RS architecture. 

a)      I2RS tunnels must include additions beyond encapsulation, 

b)      Why the I2RS Informational Model and the I2RS Data Model do not provide the soft tunnel provisioning or describe the specifics of this provision?  

The I2RS Informational Model has examples for these tunnels.  You are welcome to make proposal for specific changes to the I2RS Informational Model or the I2RS Data Model.  The I2RS Informational Model has completed WG LC so the bar for substantive comments is high.    

<I2RS chair hat off> 

Cheers, 

Sue Hares 

From: i2rs [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Monday, November 23, 2015 7:30 PM
To: Susan Hares; [email-masked]
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Sue, 

From: i2rs <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Monday, November 23, 2015 at 5:45 PM
To: "[email-masked]" <[email-masked]>
Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Resending to I2RS WG. 

Jeff and Acee: 

 

 

Acee 

 

 Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; [email-masked]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Hi Mach,

Cheers,

Jeff

 

i2rs mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 24 Nov 2015 13:34:39 +0000

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 23, 2015 at 9:57 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Alia Atlas <[email-masked]<mailto:[email-masked]>>, Jeff Haas <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Acee:

Individual.

<I2RS chair hat on>

The routing architecture for yang models is incomplete without the consideration of the I2RS ephemeral state and I2RS architecture.  Asking the I2RS WG to change a document that is in WG LC based on an incomplete architectural document is not reasonable.

My comment with respect to tunnel provisioning is not based on any architecture document.

An alignment between https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ without the consideration of the I2RS ephemeral state is an incomplete alignment and a problematic  approach for I2RS WG’s efforts.

I2RS models should augment the base models with ephemeral state.

In a volunteer organization, each person has the right to makes choices in what they have time to do.   If you do not have bandwidth to provide an adequate routing architecture for yang models that considers ephemeral state or its needs, that is your choice.  Unless you have a concrete proposal for the ephemeral state that covers I2RS RIB and https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/, the I2RS WG LC will be closed after 2 week (11/23 – 12/7) WG review of the in draft-ietf-i2rs-rib-data-model-04.txt.

We have proposed tunnel models, draft-ietf-netmod-routing-cfg is not meant to supplant them. BTW, we don’t plan to update draft-ietf-i2rs-rib-data-model-04.txt. Updates based on I2RS will be in the a next-hop augmentation draft that extends draft-ietf-netmod-rtg-cfg.

I don’t believe this excerpt from the RIB information models describes soft tunnel provisioning for each of the tunnels proposed in the RIB data model:

7.2.1.  Tunnel nexthops

   A tunnel nexthop points to a tunnel of some kind.  Traffic that goes
   over the tunnel gets encapsulated with the tunnel encap.  Tunnel
   nexthops are useful for abstracting out details of the network, by
   having the traffic seamlessly route between network edges.  At the
   end of a tunnel, the tunnel will get decapsulated.  Thus the grammar
   supports two kinds of operations, one for encap and another for
   decap.

Acee

<I2RS chair hat off>

Cheers,

Sue Hares

From: i2rs [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Monday, November 23, 2015 7:30 PM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Sue,

Resending to I2RS WG.

Jeff and Acee:

Acee

 Sue Hares

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Hi Mach,

Cheers,

Jeff

i2rs mailing list

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Nov 2015 09:55:00 -0500

Acee: 

Top of the morning on a fine snowy day. 

<WG Chair hat on> 

You should also look at section 2.4.3 as well as section 7.2.1.  Can you suggest what you would like to see covered in section 7.2.1?  What use case are you trying to solve?   

None of the models described by your email are working drafts ( draft-li-rtgwg-utunnel-yang,  draft-li-rtgwg-tunnel-policy-yang, draft-wwz-netmod-yang-tunnel-cfg, draft-zheng-intarea-gre-yang, draft-liu-intarea-gre-tunnel-yang, and draft-liu-intarea-ipipv4-tunnel-yang). 

The I2RS RIB model and the tunnels have been in discussion since 2013.  Stating I2RS should change document which have gone to WG LC to follow the work of individual drafts is not a reasonable request. 

Without further clarification of an error case your concerned about, or a specific concern for a I2RS use case, or WG approved architectural document with a specific set of design principles you are concerned about, I cannot re-open a completed WG LC for the I2RS Information Model.   The I2RS RIB Data Model follows the I2RS Informational Model.    

I will host a design team for those who I2RS Members to comment on the incomplete routing architecture for yang models to suggest solutions for the routing architecture.  I2RS members should contact me off-list if you wish to participate.  

<WG Hat off> 

Cheerily, 

Sue 

From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Tuesday, November 24, 2015 8:35 AM
To: Susan Hares; [email-masked]
Cc: 'Alia Atlas'; 'Jeffrey Haas'; 'Jeff Tantsura'
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

From: Susan Hares < <mailto:[email-masked]> [email-masked]>

Date: Monday, November 23, 2015 at 9:57 PM
To: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Alia Atlas <[email-masked]>, Jeff Haas <[email-masked]>, Jeff Tantsura <[email-masked]>
Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Acee: 

Individual. 

<I2RS chair hat on> 

An alignment between  <https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ without the consideration of the I2RS ephemeral state is an incomplete alignment and a problematic  approach for I2RS WG’s efforts.   

 

Sue – Ace did you mean draft-ietf-nemod-routing-config in the previous sentence.  Your proposed tunnel models are individual drafts.   

7.2.1.  Tunnel nexthops

   decap.

Acee 

<I2RS chair hat off> 

Cheers, 

Sue Hares 

Sue, 

Resending to I2RS WG. 

Jeff and Acee: 

 

 

Acee 

 

 Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; [email-masked]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Hi Mach,

Cheers,

Jeff

 

i2rs mailing list

---

From: Alia Atlas <[email-masked]>
Date: Tue, 24 Nov 2015 12:08:18 -0500

Acee,

As Sue has said, the I2RS Info Model has passed WGLC and is just waiting
for the DM to be done in order to progress.  Obviously, substantial
technical concerns are always welcome - there's a long way between WGLC and
final IESG approval; I do not think that you have clearly described your
technical concerns.  Are you mixing up using a tunnel for forwarding with
provisioning the tunnel??

The I2RS RIB model is not for provisioning tunnels.  It is intended so that
traffic can be forwarded properly, regardless of the abstraction.  For
instance, with MPLS, a packet could be sent out with an arbitrary label or
label stack, a packet could follow an LSP, or a packet could follow a
tunnel.   By providing the ability to forward via these different layers of
abstraction, the RIB model allows forwarding to occur correctly even when a
tunnel or LSP changes - just like a next-hop can be specified to forward
like a different prefix and then follows that prefix.

I certainly do not see the I2RS RIB model as creating tunnels - but merely
being able to use ones that already exist.

Now, if your objection is that the I2RS RIB model should use a common
grouping that describes all types of tunnels, I have yet to see one.  The
efforts to provide YANG models for tunnels are still quite immature.
Describing what types of groupings would be useful is the type of work that
I hope the design team will do.
Asking I2RS to stall until time can be dedicated isn't appropriate.

Regards,
Alia

On Tue, Nov 24, 2015 at 8:34 AM, Acee Lindem (acee) <[email-masked]> wrote:

> From: Susan Hares <[email-masked]>
> The routing architecture for yang models is incomplete without the
> consideration of the I2RS ephemeral state and I2RS architecture.  Asking
> the I2RS WG to change a document that is in WG LC based on an incomplete
> architectural document is not reasonable.
>
>
> An alignment between
> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ without
> the consideration of the I2RS ephemeral state is an incomplete alignment
> and a problematic  approach for I2RS WG’s efforts.
>
>
> In a volunteer organization, each person has the right to makes choices in
> what they have time to do.   If you do not have bandwidth to provide an
> adequate routing architecture for yang models that considers ephemeral
> state or its needs, that is your choice.  Unless you have a concrete
> proposal for the ephemeral state that covers I2RS RIB and
> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/, the I2RS
> WG LC will be closed after 2 week (11/23 – 12/7) WG review of the in draft-ietf-i2rs-rib-data-model-04.txt.
>
>
>
> We have proposed tunnel models, draft-ietf-netmod-routing-cfg is not meant
> to supplant them. BTW, we don’t plan to
> update draft-ietf-i2rs-rib-data-model-04.txt. Updates based on I2RS will be
> in the a next-hop augmentation draft that extends
> draft-ietf-netmod-rtg-cfg.
>
>
>
>
>
> Please remember that the I2RS RIB model has two parts:  I2RS Informational
> Model and I2RS Data Model.  The I2RS Informational Model and the I2RS
> Data Model have descriptions on the soft tunnel provisioning as
> mechanisms.  Questions at this point must demonstrate a knowledge of these
> documents or suggest specific changes to the documents.   If you wish to
> raise the following questions, please do this in light of specific sections
> that include both the I2RS Informational Model, the I2RS Data Model, and
> I2RS architecture.
>
>
>
> b)      Why the I2RS Informational Model and the I2RS Data Model do not
> provide the soft tunnel provisioning or describe the specifics of this
> provision?
>
>
>
> The I2RS Informational Model has examples for these tunnels.  You are
> welcome to make proposal for specific changes to the I2RS Informational
> Model or the I2RS Data Model.  The I2RS Informational Model has completed
> WG LC so the bar for substantive comments is high.
>
>
> I don’t believe this excerpt from the RIB information models describes
> soft tunnel provisioning for each of the tunnels proposed in the RIB data
> model:
>
> 7.2.1.  Tunnel nexthops
>
> *From:* i2rs [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Acee Lindem (acee)
> *Sent:* Monday, November 23, 2015 7:30 PM
> *To:* Susan Hares; [email-masked]
> *Subject:* Re: [i2rs] FW: I-D Action:
> draft-ietf-i2rs-rib-data-model-04.txt
>
>
>
> Sue,
>
>
>
> *From: *i2rs <[email-masked]> on behalf of Susan Hares <
> [email-masked]>
> *Date: *Monday, November 23, 2015 at 5:45 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt
>
>
>
> Resending to I2RS WG.
>
>
>
> *From:* Susan Hares [mailto:[email-masked] <[email-masked]>]
> *Sent:* Monday, November 23, 2015 5:33 PM
> *To:* 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; [email-masked]'
> *Cc:* 'Jeffrey Haas'; 'Alia Atlas'; 'Benoit Claise (bclaise)'
> *Subject:* RE: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt
>
>
>
> Jeff and Acee:
>
>
>
> Your suggested change goes against the WG adopted RIB Information draft
> that has been discussed for over 2 years.  The informational draft has been
> through WG LC and you did not make any suggestions or comments during the
> WG LC.  Any change of this matter is not simply something you indicate to
> the authors, but needs to be discussed on the WG as a direction change for
> the RIB IM/DM models.
>
>
>
> Independent of the I2RS efforts, milestones, and processes, I think we
> need to address whether provisioning all these tunnels via RIB installation
> is  appropriate and, additionally, consistent with other WG YANG models. In
> many cases, it would seem there are tunnel attributes other than the encaps
> that need to be provisioned. At a minimum, I think you’d need to either
> reference an RFC describing soft tunnel provisioning or describe the
> specifics of this provisioning.
>
>
>
>
>
> Prior to moving this change through WG adoption cycle, the routing
> architectural team needs to have: a) concrete proposal for the ephemeral
> state that covers I2RS RIB and
> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/  and  b)
> I requested this input of Acee Lindem as a representative of the routing
> architecture team.
>
>
>
> I will be glad to work with you on a concrete proposal that you can send
> to the email list and present at the I2RS interim meeting on 12/16/2015
> (10-11:30am ET).
>
>
>
> From: i2rs [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Jeff Tantsura
> I agree with Acee’s comments and would encourage you to use
> generic/existing tunnel model(s), please see comments provided during RTGWG
> meeting in Yokohama.
>
> On 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" <[email-masked]
> on behalf of [email-masked]
> <[email-masked][email-masked]>> wrote:
>
>
>
> >Hi Mach,
>
> >
>
> ><[email-masked] on behalf of [email-masked]> wrote:
>
> >
>
> >>Hi,
>
> >>
>
> >>> From: i2rs [mailto:[email-masked] <[email-masked]>] On
> Behalf Of
>
> >>>[email-masked]
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 24 Nov 2015 17:19:30 +0000

Alia,

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 24, 2015 at 12:08 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Susan Hares <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jeff Haas <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Acee,

As Sue has said, the I2RS Info Model has passed WGLC and is just waiting for the DM to be done in order to progress.  Obviously, substantial technical concerns are always welcome - there's a long way between WGLC and final IESG approval; I do not think that you have clearly described your technical concerns.  Are you mixing up using a tunnel for forwarding with provisioning the tunnel??

The I2RS RIB model is not for provisioning tunnels.  It is intended so that traffic can be forwarded properly, regardless of the abstraction.  For instance, with MPLS, a packet could be sent out with an arbitrary label or label stack, a packet could follow an LSP, or a packet could follow a tunnel.   By providing the ability to forward via these different layers of abstraction, the RIB model allows forwarding to occur correctly even when a tunnel or LSP changes - just like a next-hop can be specified to forward like a different prefix and then follows that prefix.

I certainly do not see the I2RS RIB model as creating tunnels - but merely being able to use ones that already exist.

I believe the intension of the model is clearly to dynamically create the tunnels.

   Tunnel nexthops allow an external entity to program static tunnel
   headers.  There can be cases where the remote tunnel end-point does
   not support dynamic signaling (e.g. no LDP support on a host) and in
   those cases the external entity might want to program the tunnel
   header on both ends of the tunnel.  The tunnel nexthop is kept
   generic with specifications provided for some commonly used tunnels.
   It is expected that the data-model will model these tunnel types with
   complete accuracy.

Now, if your objection is that the I2RS RIB model should use a common grouping that describes all types of tunnels, I have yet to see one.  The efforts to provide YANG models for tunnels are still quite immature.
Describing what types of groupings would be useful is the type of work that I hope the design team will do.
Asking I2RS to stall until time can be dedicated isn't appropriate.

Nor is not addressing comments on WG drafts…

Acee

Regards,
Alia

On Tue, Nov 24, 2015 at 8:34 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Acee:

Individual.

<I2RS chair hat on>

7.2.1.  Tunnel nexthops

Acee

<I2RS chair hat off>

Cheers,

Sue Hares

Sue,

Resending to I2RS WG.

Jeff and Acee:

Acee

 Sue Hares

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Hi Mach,

Cheers,

Jeff

>>>tools.ietf.org<http://tools.ietf.org>.

i2rs mailing list

---

From: Alia Atlas <[email-masked]>
Date: Tue, 24 Nov 2015 12:28:40 -0500

Acee,

In-line, as always.

On Tue, Nov 24, 2015 at 12:19 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Alia,
>
> From: Alia Atlas <[email-masked]>
> To: Acee Lindem <[email-masked]>
> Cc: Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>, Jeff
> Haas <[email-masked]>, Jeff Tantsura <[email-masked]>
> The I2RS RIB model is not for provisioning tunnels.  It is intended so
> that traffic can be forwarded properly, regardless of the abstraction.  For

If the text makes you believe that it is dynamically creating tunnels, then
that text should be improved.
It shouldn't be creating the tunnel - but what "creating a tunnel" means
may also be open for interpretation.
For instance, a next-hop might include an MPLS label or label-stack - but
that isn't creating an LSP.  It
is allowing a packet that matches to be forwarded with that label-stack.  A
next-hop may include a tunnel name - but that is a reference to an existing
tunnel (or a tunnel that doesn't exist and therefore won't resolve).

> Nor is not addressing comments on WG drafts…

Absolutely - regardless of when they come in.  But this is the first clear
pointing to what you see
as the problem with the draft.   Thanks for clarifying.

Regards,
Alia

>> In a volunteer organization, each person has the right to makes choices
>> in what they have time to do.   If you do not have bandwidth to provide an
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/, the
>> I2RS WG LC will be closed after 2 week (11/23 – 12/7) WG review of the in draft-ietf-i2rs-rib-data-model-04.txt.
>>
>>
>>
>> We have proposed tunnel models, draft-ietf-netmod-routing-cfg is not
>> meant to supplant them. BTW, we don’t plan to
>> Please remember that the I2RS RIB model has two parts:  I2RS
>> Informational Model and I2RS Data Model.  The I2RS Informational Model
>> and the I2RS Data Model have descriptions on the soft tunnel provisioning
>> as mechanisms.  Questions at this point must demonstrate a knowledge of
>> these documents or suggest specific changes to the documents.   If you wish
>> to raise the following questions, please do this in light of specific
>> sections that include both the I2RS Informational Model, the I2RS Data
>> Model, and I2RS architecture.
>>
>>
>>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 Nov 2015 12:43:49 -0500

Acee: 

<WG hat off> 

Ah.. the light of understanding dawns.  You think that the I2RS is provisioning the tunnel rather than just pointing to it.   I’ve re-read the text again to see if I can understand it.  

Section 2.4.3 in the RIB Info model specifies how we will find the next hop specified.  The references all reduce to some combination of interface to interfaces and/or addresses.  The tunnel interface is just another interface like egress interfaces.   The reading of 7.2.1  is expanding this section.    The I2RS RIB does not provision the tunnel because we expect other mechanisms within the system (like the proposed tunnel drafts) would create these tunnels.   

Would a statement in 2.4.3 or 7.2 that I2RS RIB is utilizing tunnels or interfaces created by other mechanisms be helpful? 

<WG hat on> 

Sue 

From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Tuesday, November 24, 2015 12:20 PM
To: Alia Atlas
Cc: Susan Hares; [email-masked]; Jeffrey Haas; Jeff Tantsura
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Alia, 

Cc: Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>, Jeff Haas <[email-masked]>, Jeff Tantsura <[email-masked]>

Acee, 

 

   complete accuracy.

Acee 

Regards,

Alia

Acee: 

Individual. 

<I2RS chair hat on> 

 

 

7.2.1.  Tunnel nexthops

   decap.

Acee 

<I2RS chair hat off> 

Cheers, 

Sue Hares 

Sue, 

Resending to I2RS WG. 

Jeff and Acee: 

 

 

Acee 

 

 Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; [email-masked]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Hi Mach,

Cheers,

Jeff

 

i2rs mailing list

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 24 Nov 2015 15:22:50 -0500

Sue,

As Alia says, in-line as always :)

> On Nov 23, 2015, at 9:57 PM, Susan Hares <[email-masked]> wrote:
> 
> Acee: 
>  
> The routing architecture for yang models is incomplete without the consideration of the I2RS ephemeral state and I2RS architecture.  Asking the I2RS WG to change a document that is in WG LC based on an incomplete architectural document is not reasonable.  An alignment between https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ <https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/> without the consideration of the I2RS ephemeral state is an incomplete alignment and a problematic  approach for I2RS WG’s efforts.   

I’m still trying to figure out what is exactly I2RS ephemeral state. RIB and FIB by definition are ephemeral. Results of routing protocols are ephemeral. The only persistence in it are input parameters that will define the initial behavior of the protocol, but after that everything is ephemeral.
IMO, I2RS agent should almost have no persistence configuration, except basic management and the I2RS client definitions.

Dean

---

From: Mach Chen <[email-masked]>
Date: Wed, 25 Nov 2015 01:34:24 +0000

Hi Acee,

Thanks for your comments!

This data model is totally aligned with the definition of the info model that has already passed the WG LC. So, I think the first step is to discuss whether the changes should be made to the info model. If there is a consensus to make the changes, it should be easy to update the data model accordingly. 

In the model, the description of the tunnel-encap nexthop says:

"This can be an encap representing an IP tunnel or
             MPLS tunnel or others as defined in info model.
             An optional egress interface can be chained to the
             tunnel encap to indicate which interface to send
             the packet out.  The egress interface is useful
             when the network device contains Ethernet interfaces
             and one needs to perform address resolution for the
             IP packet.";

So, IMHO, the model just treats a tunnel as the nexthop, it does not intend to create a tunnel and just uses an existing one. 

Best regards,
Mach

> Sent: Tuesday, November 24, 2015 3:56 AM
> To: Mach Chen; [email-masked]
> I’m looking at draft-ietf-i2rs-rib-data-model-04.txt and it still includes all the
> tunnel encaps. I know you received several comments that those should be in
> the tunnel model(s) and this I2RS RIB model should merely reference an
> imported tunnel abstraction. How are you going to address this? It seemed
> that the consensus (and an opinion that I share) was that this model should not
> attempt to generically created tunnels via RIB/FIB entries.
> Thanks,
> Acee
>