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 protected]] Sent: Tuesday, November 24, 2015 12:20 PM To: Alia Atlas Cc: Susan Hares; [email protected]; Jeffrey Haas; Jeff Tantsura Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt Alia, From: Alia Atlas <[email protected]> Date: Tuesday, November 24, 2015 at 12:08 PM To: Acee Lindem <[email protected]> Cc: Susan Hares <[email protected]>, "[email protected]" <[email protected]>, Jeff Haas <[email protected]>, Jeff Tantsura <[email protected]> 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 protected]> wrote: From: Susan Hares < <mailto:[email protected]> [email protected]> Date: Monday, November 23, 2015 at 9:57 PM To: Acee Lindem <[email protected]>, "[email protected]" <[email protected]> Cc: Alia Atlas <[email protected]>, Jeff Haas <[email protected]>, Jeff Tantsura <[email protected]> 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/> 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/> 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:[email protected]] On Behalf Of Acee Lindem (acee) Sent: Monday, November 23, 2015 7:30 PM To: Susan Hares; [email protected] Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt Sue, From: i2rs <[email protected]> on behalf of Susan Hares <[email protected]> Date: Monday, November 23, 2015 at 5:45 PM To: "[email protected]" <[email protected]> Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt Resending to I2RS WG. From: Susan Hares [mailto:[email protected]] Sent: Monday, November 23, 2015 5:33 PM To: 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; '[email protected]' 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:[email protected]] On Behalf Of Jeff Tantsura Sent: Monday, November 23, 2015 4:27 PM To: Acee Lindem (acee); Mach Chen; [email protected] 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)" < <mailto:[email protected]%20on%20behalf%20of%[email protected]> [email protected] on behalf of [email protected]> 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" >< <mailto:[email protected]%20on%20behalf%20of%[email protected]> >[email protected] on behalf of [email protected]> 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:[email protected]> mailto:[email protected]] >>> On Behalf Of >>> <mailto:[email protected]> [email protected] >>> Sent: Monday, November 23, 2015 3:16 PM >>> To: <mailto:[email protected]> [email protected] >>> Cc: <mailto:[email protected]> [email protected] >>> 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/> >>> 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> >>> 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> >>> 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/> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> i2rs mailing list >>> <mailto:[email protected]> [email protected] >>> <https://www.ietf.org/mailman/listinfo/i2rs> >>> https://www.ietf.org/mailman/listinfo/i2rs >> >>_______________________________________________ >>i2rs mailing list >> <mailto:[email protected]> [email protected] >> <https://www.ietf.org/mailman/listinfo/i2rs> >> https://www.ietf.org/mailman/listinfo/i2rs > >_______________________________________________ >i2rs mailing list > <mailto:[email protected]> [email protected] > <https://www.ietf.org/mailman/listinfo/i2rs> > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list <mailto:[email protected]> [email protected] <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
