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

["Acee Lindem (acee)" <[e-mail]>]

Alia,

From: Alia Atlas <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 24, 2015 at 12:08 PM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>
Cc: Susan Hares <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Jeff Haas <[e-mail]<mailto:[e-mail]>>, Jeff Tantsura <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> wrote:
From: Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Monday, November 23, 2015 at 9:57 PM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Alia Atlas <[e-mail]<mailto:[e-mail]>>, Jeff Haas <[e-mail]<mailto:[e-mail]>>, Jeff Tantsura <[e-mail]<mailto:[e-mail]>>
Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Acee:

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

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.



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.

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

Sue,

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

Resending to I2RS WG.

From: Susan Hares [mailto:[e-mail]]
Sent: Monday, November 23, 2015 5:33 PM
To: 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; '[e-mail]<mailto:'[e-mail]>'
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.

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






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).

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:[e-mail]] On Behalf Of Jeff Tantsura
Sent: Monday, November 23, 2015 4:27 PM
To: Acee Lindem (acee); Mach Chen; [e-mail]<mailto:[e-mail]>
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-04.txt



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













On 11/23/15, 11:56, "i2rs on behalf of Acee Lindem (acee)" <[e-mail] on behalf of [e-mail]<mailto:[e-mail][e-mail]>> wrote:



>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"

><[e-mail] on behalf of [e-mail]<mailto:[e-mail][e-mail]>> 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

>>

>>> -----Original Message-----

>>> From: i2rs [mailto:[e-mail]] On Behalf Of

>>>[e-mail]<mailto:[e-mail]>

>>> Sent: Monday, November 23, 2015 3:16 PM

>>> To: [e-mail]<mailto:[e-mail]>

>>> Cc: [e-mail]<mailto:[e-mail]>

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

>>>

>>>

>>> 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<http://tools.ietf.org>.

>>>

>>> Internet-Drafts are also available by anonymous FTP at:

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

>>>

>>> _______________________________________________

>>> i2rs mailing list

>>> [e-mail]<mailto:[e-mail]>

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

>>

>>_______________________________________________

>>i2rs mailing list

>>[e-mail]<mailto:[e-mail]>

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

>

>_______________________________________________

>i2rs mailing list

>[e-mail]<mailto:[e-mail]>

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

_______________________________________________

i2rs mailing list

[e-mail]<mailto:[e-mail]>

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