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

[Alia Atlas <[e-mail]>]

Acee,

In-line, as always.

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

> Alia,
>
> From: Alia Atlas <[e-mail]>
> Date: Tuesday, November 24, 2015 at 12:08 PM
> To: Acee Lindem <[e-mail]>
> Cc: Susan Hares <[e-mail]>, "[e-mail]" <[e-mail]>, Jeff
> Haas <[e-mail]>, Jeff Tantsura <[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.
>

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) <[e-mail]>
> wrote:
>
>> From: Susan Hares <[e-mail]>
>> Date: Monday, November 23, 2015 at 9:57 PM
>> To: Acee Lindem <[e-mail]>, "[e-mail]" <[e-mail]>
>> Cc: Alia Atlas <[e-mail]>, Jeff Haas <[e-mail]>, Jeff
>> Tantsura <[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] <[e-mail]>] *On
>> Behalf Of *Acee Lindem (acee)
>> *Sent:* Monday, November 23, 2015 7:30 PM
>> *To:* Susan Hares; [e-mail]
>> *Subject:* Re: [i2rs] FW: I-D Action:
>> draft-ietf-i2rs-rib-data-model-04.txt
>>
>>
>>
>> Sue,
>>
>>
>>
>> *From: *i2rs <[e-mail]> on behalf of Susan Hares <
>> [e-mail]>
>> *Date: *Monday, November 23, 2015 at 5:45 PM
>> *To: *"[e-mail]" <[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] <[e-mail]>]
>> *Sent:* Monday, November 23, 2015 5:33 PM
>> *To:* 'Jeff Tantsura'; 'Acee Lindem (acee)'; 'Mach Chen'; '[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] <[e-mail]>] On
>> Behalf Of Jeff Tantsura
>> Sent: Monday, November 23, 2015 4:27 PM
>> To: Acee Lindem (acee); Mach Chen; [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]
>> <[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]> 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] <[e-mail]>] On
>> Behalf Of
>>
>> >>>[e-mail]
>>
>> >>> Sent: Monday, November 23, 2015 3:16 PM
>>
>> >>> To: [e-mail]
>>
>> >>> Cc: [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.
>>
>> >>>
>>
>> >>> Internet-Drafts are also available by anonymous FTP at:
>>
>> >>> ftp://ftp.ietf.org/internet-drafts/
>>
>> >>>
>>
>> >>> _______________________________________________
>>
>> >>> i2rs mailing list
>>
>> >>> [e-mail]
>>
>> >>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>> >>
>>
>> >>_______________________________________________
>>
>> >>i2rs mailing list
>>
>> >>[e-mail]
>>
>> >>https://www.ietf.org/mailman/listinfo/i2rs
>>
>> >
>>
>> >_______________________________________________
>>
>> >i2rs mailing list
>>
>> >[e-mail]
>>
>> >https://www.ietf.org/mailman/listinfo/i2rs
>>
>> _______________________________________________
>>
>> i2rs mailing list
>>
>> [e-mail]
>>
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>>
>