Acee, In-line, as always.
On Tue, Nov 24, 2015 at 12:19 PM, Acee Lindem (acee) <[email protected]> wrote: > 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. > 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). 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… > 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 > Acee > > > > Regards, > Alia > > > > On Tue, Nov 24, 2015 at 8:34 AM, Acee Lindem (acee) <[email protected]> > wrote: > >> From: Susan Hares <[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/ 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:[email protected] <[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] <[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] <[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)" >> <[email protected] >> on behalf of [email protected] >> <[email protected]%20on%20behalf%20of%[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" >> >> ><[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] <[email protected]>] On >> Behalf Of >> >> >>>[email protected] >> >> >>> Sent: Monday, November 23, 2015 3:16 PM >> >> >>> To: [email protected] >> >> >>> Cc: [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/ >> >> >>> >> >> >>> 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/ >> >> >>> >> >> >>> _______________________________________________ >> >> >>> i2rs mailing list >> >> >>> [email protected] >> >> >>> https://www.ietf.org/mailman/listinfo/i2rs >> >> >> >> >> >>_______________________________________________ >> >> >>i2rs mailing list >> >> >>[email protected] >> >> >>https://www.ietf.org/mailman/listinfo/i2rs >> >> > >> >> >_______________________________________________ >> >> >i2rs mailing list >> >> >[email protected] >> >> >https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> >> i2rs mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
