Re: [Teas] Structure of draft-ietf-mpls-static-yang

"Tarek Saad (tsaad)" <tsaad@cisco.com> Wed, 14 November 2018 14:24 UTC

Return-Path: <tsaad@cisco.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD0F130E8F; Wed, 14 Nov 2018 06:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level:
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_S53jm6ir_B; Wed, 14 Nov 2018 06:24:27 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0C4130E83; Wed, 14 Nov 2018 06:24:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9994; q=dns/txt; s=iport; t=1542205467; x=1543415067; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=38MfWliOGUf0tT78O07mbhSYVCviawkGEAsf6U0R1nQ=; b=Ookpv2g27r5AtysGn8nqFDB9oS9NM1GOhQtvrqucovbtD2tor/wPgs21 EVx3ByjY/QALhKitJWoEDI2BGIfamiPU3gzIrzzrKzLYZcs8DdB2y9EbC FbO5xM3G+o1OHKghmPOQUOVqe6UQIvHvqaD+kTw4shY7lqxZwAkQ0DJvw E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAADuLuxb/5tdJa1ZCRkBAQEBAQEBAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIDgWgnCoNuiBiLeYINlzaBegsBAYRsAheDMSI0DQ0BAwEBAgEBAm0ohToBAQEDASMRMxIMBAIBCBEDAQEBAwImAgICMBUICAIEAQ0FgyGBegioCoEviiyBC4p6F4FAP4EQAScfgkyEVAMnJoJeMYImAolBhUiQVQkCkSAYkHWUVIMGAhEUgSYfOIFVcBVlAYJBgicXjhxBMYsagS6BHwEB
X-IronPort-AV: E=Sophos;i="5.56,232,1539648000"; d="scan'208";a="471165712"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2018 14:24:25 +0000
Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wAEEOONx005341 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Nov 2018 14:24:25 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 14 Nov 2018 09:24:24 -0500
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1395.000; Wed, 14 Nov 2018 09:24:24 -0500
From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
To: tom petch <ietfc@btconnect.com>, mpls <mpls@ietf.org>, "teas@ietf.org" <teas@ietf.org>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>
CC: "draft-ietf-mpls-base-yang@ietf.org" <draft-ietf-mpls-base-yang@ietf.org>
Thread-Topic: Structure of draft-ietf-mpls-static-yang
Thread-Index: AQHUe02zLoXhPVZ4oEewoTF89DwZ8aVPVN6A
Date: Wed, 14 Nov 2018 14:24:24 +0000
Message-ID: <6513C0AA-1E1E-4E4D-A9F6-6349F0F5E049@cisco.com>
References: <151871655164.7468.17697751302068907872@ietfa.amsl.com> <03b001d3a714$5e08dce0$4001a8c0@gateway.2wire.net> <A7C87BD7-A6E5-474F-9D19-F3B9A6F83DA4@cisco.com> <001001d4767d$62fb1a40$4001a8c0@gateway.2wire.net> <00c901d478f6$25a75c00$4001a8c0@gateway.2wire.net> <060801d47b4d$730cbd60$4001a8c0@gateway.2wire.net> <8482D196-9EE8-4469-94FA-0DEF1B595252@cisco.com> <006d01d47b74$cde44920$4001a8c0@gateway.2wire.net>
In-Reply-To: <006d01d47b74$cde44920$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.249.239]
Content-Type: text/plain; charset="utf-8"
Content-ID: <24141896A488F149B6DF195F1F23524A@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.143, xch-rtp-003.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/EWJ5U5PlfPoTaRNMh9ZUAvGUW2E>
Subject: Re: [Teas] Structure of draft-ietf-mpls-static-yang
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Nov 2018 14:24:30 -0000

+ draft-ietf-ospf-yang authors
+ teas alias to comment on the utility of TE router-ID in the OSPF YANG model for other non-MPLS technologies too.

Hi Tom,

Inline..

-----Original Message-----
From: tom petch <ietfc@btconnect.com>
Date: Tuesday, November 13, 2018 at 12:19 PM
To: Tarek Saad <tsaad@cisco.com>, mpls <mpls@ietf.org>
Cc: "draft-ietf-mpls-base-yang@ietf.org" <draft-ietf-mpls-base-yang@ietf.org>
Subject: Re: Structure of  draft-ietf-mpls-static-yang

    ----- Original Message -----
    From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
    Sent: Tuesday, November 13, 2018 4:31 PM
    
    > Hi Tom,
    >
    > Thanks. To me, RIP/OSPF/PIM/BGP are all control plane protocols and
    would think should exist below /routing/control-plane-protocols.
    > MPLS on the contrary is a forwarding augmentation to existing V4/V6
    routing table(s) (which are already defined at path
    /routing/ribs/rib/routes/route/next-hop ) - the MPLS augmentation
    carries additional mpls specific data.
    > There are signaling control plane protocols specific to exchange MPLS
    labels (e.g. RSVP-TE, LDP) which I expect will exist at
    /routing/control-plane-protocols/control-plane-protocol (e.g.
    draft-ietf-teas-yang-rsvp)
    
    Tarek
    
    Yes, so BGP is out of line, but that is a problem for another WG.
    
    The MPLS quirks are IMHO twofold.
    
    Why define an address family?  I always think of AFI/SAFI when someone
    says address family and I do not see MPLS figuring in that context.
[TS]: MPLS can augment routes in the V4/V6 AFI routing tables defined in RFC8349. However, there are other type of MPLS routes (cross-connects) that are not associated with an IP prefix or an AFI defined in RFC8349. Examples of such routes can be RSVP-LSP labels/cross-connects, per L2 or L3 VRF de-aggregation labels, etc.).. Such routes will exist in the new MPLS AFI table.
    
    Second, what are MPLS and MPLStunnel doing in the Interface Table?  Ok,
    they are a carry over from the MIB but do they have any role here?
[TS]: currently, this is enabling MPLS on the specific (sub)set of interfaces and setting minimal set of attributes - e.g. MPLS MTU.
    
    I am fishing for some 'when' (or if-feature) statements alongside the
    'augment'
    to make the augment conditional (although perhaps not as many as TEAS
    created:-).  Instinctively I feel there should be something as e.g. OSPF
    has although accepting your point about MPLS not being a protocol; but
    then mpls-ldp is a protocol but has no conditionals that I can see.
[TS]: I think the assumption was MPLS is a base functionality that most router vendors will support - so we've avoided an if-feature check. However, I can see that some devices may not support MPLS (or may not turn MPLS), so we can look into adding a when or feature check to control augments to external YANG models. For MPLS LDP, yes, I think they can add the same for signaling MPLS. However, I am aware LDP protocol can be used for non-MPLS signaling too (e.g. ICCP) - so the LDP YANG modeling team may need to look at what augments can be controlled/associated with MPLS.
    
    At a slight tangent, I see in OSPF and others references such as
           container mpls {
             description "OSPF MPLS config state.";
             container te-rid {
               if-feature te-rid;
    ie conditional but not on MPLS per se.

[TS]: Yes, although traditionally enabled for MPLS-TE, the TE router-ID can apply to non-MPLS technologies too (e.g. for GMPLS OTN, etc.).. IMO, Ideally this would not need to exist under mpls container.. We may need to raise this with OSPF team.

Regards,
Tarek
    
    Tom Petch
    
    > Regards,
    > Tarek
    >
    > -----Original Message-----
    > From: tom petch <ietfc@btconnect.com>
    > Date: Tuesday, November 13, 2018 at 7:37 AM
    > To: Tarek Saad <tsaad@cisco.com>, mpls <mpls@ietf.org>
    > Cc: "draft-ietf-mpls-base-yang@ietf.org"
    <draft-ietf-mpls-base-yang@ietf.org>
    > Subject: Structure of  draft-ietf-mpls-static-yang
    >
    >     I wonder if the IETF has yet worked out how to model routing
    protocols.
    >     I asked, what is MPLS?  Looking at various modules, I see
    >
    >     RIP
    >          augment
    /routing/control-plane-protocols/control-plane-protocol:
    >            +--rw rip
    >               +--rw interfaces
    >
    >     OSPF
    >          augment
    /routing/control-plane-protocols/control-plane-protocol:
    >            +--rw ospf
    >               +--rw areas
    >               |  +--rw area* [area-id]
    >               |     +--rw interfaces
    >
    >     the other IxxxGP
    >       module: ietf-ixxx
    >         augment /routing/ribs/rib/routes/route:
    >           +--ro route-type?   enumeration
    >         augment /interfaces/interface:
    >           +--rw clns-mtu?   uint16
    >         augment
    /routing/control-plane-protocols/:control-plane-protocol:
    >           +--rw ixxx
    >              +--rw enable?                   boolean {admin-control}?
    >              +--rw system-id?                system-id
    >              +--rw area-address*             area-address
    >
    >     BGP
    >          augment "/routing-policy/defined-sets"
    >         module ietf-bgp {
    >                +--rw bgp!
    >                  +--rw global
    >                     +--rw afi-safis
    >                        +--rw afi-safi* [afi-safi-name]
    >                           +--rw ipv4-unicast
    >                           +--rw ipv6-unicast
    >                           +--rw l3vpn-ipv4-unicast
    >
    >     PIM
    >     module: ietf-pim-base
    >          augment /routing/control-plane-protocols:
    >            +--rw pim!
    >               +--rw address-family* [address-family]
    >               |  +--rw address-family        identityref
    >               |  +--rw <per address family configuration>
    >               +--rw interfaces
    >                  +--rw interface* [name]
    >                     +--rw name              if:interface-ref
    >                     +--rw address-family* [address-family]
    >
    >     MPLS
    >
    >     module: ietf-mpls
    >       augment /rt:routing:
    >         +--rw mpls
    >       augment /routing/ribs/rib/routes/:route:
    >         +--ro local-label?   rt-types:mpls-label
    >       augment
    >
    /routing/ribs/rib/routes/route/next-hop/next-hop-options/simple-next-hop
    >     :
    >      ....
    >       identity mpls { base address-family;
    >
    >     Different! which is right?  Perhaps none of them.  It is very
    early days
    >     for routing YANG modules, no RFC, limited experience.  I am
    mindful that
    >     it took several years after the publication of the initial system
    YANG
    >     modules for the advent of NDMA - a radically different approach -
    so
    >     perhaps in a few years we will be looking at the routing modules
    and say
    >     it needs a different approach.  Sigh
    >
    >     Tom Petch
    >
    >
    >
    >