"IETF Secretariat" | 24 Jun 18:00 2016
Picon

mpls - Requested session has been scheduled for IETF 96

Dear Tarek Saad,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

mpls Session 1 (2:30:00)
    Monday, Morning Session I 1000-1230
    Room Name: Potsdam I size: 300
    ---------------------------------------------

Request Information:

---------------------------------------------------------
Working Group Name: Multiprotocol Label Switching
Area Name: Routing Area
Session Requester: Tarek Saad

Number of Sessions: 1
Length of Session(s):  2.5 Hours
Number of Attendees: 150
Conflicts to Avoid: 
 First Priority: teas ccamp pce bess bfd idr pals bier
 Second Priority: nvo3 sfc spring i2rs rtgarea rtgwg
 Third Priority: ospf isis sidr

Special Requests:

---------------------------------------------------------

(Continue reading)

Ruediger.Geib | 23 Jun 09:05 2016
Picon

WG: New Version Notification for draft-leipnitz-spring-pms-implementation-report-00.txt

Hi Bruno, hi John,

the draft below reports on an implementation of an MPLS Path Monitoring System. The PMS is using stacked
transport labels as a SPRING router will do. The MPLS topology learned by the PMS is an LDP one. That's why I
copied the message to the MPLS WG (I'm not on the MPLS mailing list - if there are comments and questions,
please discuss on SPRING or reply to me directly).

Finally, I copy the message to IPPM WG. The MPLS PMS captures the Round-Trip Delay metric. RTD measurements
and of the MPLS PMS are compared to those of an IPPM implementation in the draft.

Regards, Ruediger 

-----Ursprüngliche Nachricht-----
Von: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Gesendet: Donnerstag, 23. Juni 2016 07:54
An: Geib, Rüdiger; Leipnitz, Raik
Betreff: New Version Notification for draft-leipnitz-spring-pms-implementation-report-00.txt


A new version of I-D, draft-leipnitz-spring-pms-implementation-report-00.txt
has been successfully submitted by Raik Leipnitz and posted to the IETF repository.

Name:		draft-leipnitz-spring-pms-implementation-report
Revision:	00
Title:		A scalable and topology aware MPLS data plane monitoring system
Document date:	2016-06-22
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-leipnitz-spring-pms-implementation-report-00.txt

Status:         https://datatracker.ietf.org/doc/draft-leipnitz-spring-pms-implementation-report/

(Continue reading)

Michel Gosse | 21 Jun 15:54 2016
Picon

MPLS + SDN + NFV World 2017: Call for papers

The call for proposals for the 19th Edition of the MPLS SDN & NFV World Congress has been issued.

New items include :

-      - MPLS & IPv6 SR instantiation

-      - Docker for optimization

-      - Intent-based  northbound interface

The CFP will be closed the 15th of July.

More info: http://www.uppersideconferences.com/mpls-sdn-nfv/mpls-sdn-nfv_2017_call_for_papers.html

 

 

 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Tarek Saad (tsaad | 18 Jun 19:30 2016
Picon

Re: MPLS-RT review of draft-raza-mpls-ldp-mldp-yang-03

Hi co-authors,

 

I have reviewed the version of draft “draft-raza-mpls-ldp-mldp-yang-03”. This draft is useful as it describes a data model that allows operating and managing widely deployed MPLS LDP and MLDP protocols. I think it is at a good starting point to be adopted by the WG.

My comments are below and can wait until the document is a working group document and the working group has the revision control.

 

General comments:

·         You use of if-feature checks in this model. One feedback from the operators was to possibly split a model into a “base” and “extended” parts- with the “base” part to contain mandatory data nodes that all vendors are expected to support and hence would not have any if-feature check. The “extended” model would contain additional features that can be if-feature checked. I’ll leave it up to you to consider this approach.

·         You are defining MLDP and LDP in same model. You may want to consider having MLDP model (either in a submodule that can included in the ldp module) or a separate module that imports LDP and augments it.

·         Since the model is hanging down from mpls, it is ok to drop the “mpls” from all leaf names (e.g. s/mpls-ldp/ldp)

 

Section 3.1:

>>   o  Read-Write parameters for configuration (Discussed in Section 3.2)

[TS]: the model in I-D.openconfig-netmod-opstate suggests having read-only leaves for applied configuration items hanging down the same branch

 

Section 3.2:

>> augment /rt:routing/rt:routing-instance/mpls:mpls:

[TS]: the above path has changed in draft-ietf-netmod-routing-cfg-21 and rt:routing-instance is not longer there. You’ll need to make the necessary changes

 

>> The "interfaces" is a container to configure parameters related to  VRF interfaces.

[TS]: you seem to be creating a separate “interfaces” container and list (and adding checks for example to ensure ipv4 is enabled). To ensure MPLS is enabled, you’d need to do the same. Or alternatively, you could augment the MPLS enabled interfaces listed in MPLS-BASE model?

 

>> typedef address-family

[TS]: rfc6991 defines “ip-version” data-type- which is similar to the type you’re defining. You may want to use that instead.

 

>> You are defining several data-types as enums. You may want to consider identities for types you think may be extended by other modules.

 

>> oper-status-event-type

Is this specific to events? not applicable to state?

 

>> use of defaults (e.g. hello-interval, etc.) – unless dictated by standard may not be favorable.. You may want to consider leaving it flexible and allow vendor backend to apply their internal default.

 

>> use of “presence” keyword to enable functions. From feedback, having explicit “enable” leaf was more favorable (avoids issues

 

>>      +--ro label?                uint32

[TS]: please consider using mpls:mpls-label instead in similar occurrence

 

Regards,

Tarek

 

 

From: Ross Callon <rcallon <at> juniper.net>
Date: Thursday, May 26, 2016 at 12:36 PM
To: "'Bert (IETF) Wijnen'" <bertietf <at> bwijnen.net>, Mach Chen <mach.chen <at> huawei.com>, Tarek Saad <tsaad <at> cisco.com>, Minto Jeyananth <minto <at> juniper.net>
Cc: "mpls-chairs <at> ietf.org" <mpls-chairs <at> ietf.org>, "Kamran Raza (skraza)" <skraza <at> cisco.com>, "Reshad Rahman (rrahman)" <rrahman <at> cisco.com>, "Rajiv Asati (rajiva)" <rajiva <at> cisco.com>, "xliu <at> kuatrotech.com" <xliu <at> kuatrotech.com>, "jeff.tantsura <at> ericsson.com" <jeff.tantsura <at> ericsson.com>, "jefftant.ietf <at> gmail.com" <jefftant.ietf <at> gmail.com>, Santosh Esale <sesale <at> juniper.net>, "jescia.chenxia <at> huawei.com" <jescia.chenxia <at> huawei.com>, Loa Andersson <loa <at> pi.nu>, "hshah <at> ciena.com" <hshah <at> ciena.com>, "Bocci, Matthew (Matthew)" <matthew.bocci <at> alcatel-lucent.com>, "stephane.litkowski <at> orange.com" <stephane.litkowski <at> orange.com>, "Sowmya Krishnaswamy (sowkrish)" <sowkrish <at> cisco.com>, "Danial Johari (dajohari)" <dajohari <at> cisco.com>
Subject: MPLS-RT review of draft-raza-mpls-ldp-mldp-yang-03

 

Bert, Mach, Tarek, Minto;

 

You have be selected as MPLS review team reviewers for draft-raza-mpls-ldp-mldp-yang-03.

 

Note to authors: You have been CC'd on this email so that you can know

that this review is going on. However, please do not review your own

document.

 

Reviews should comment on whether the document is coherent, is it

useful (ie, is it likely to be actually useful in operational networks), and is

the document technically sound?  We are interested in knowing whether

the document is ready to be considered for WG adoption (ie, it doesn't

have to be perfect at this point, but should be a good start).

 

Reviews should be sent to the document authors, WG co-chairs and WG

secretary, and CC'd to the MPLS WG email list. If necessary, comments

may be sent privately to only the WG chairs.

 

If you have technical comments you should try to be explicit about what

needs to be resolved before adopting it as a working group document, and

what can wait until the document is a working group document and the

working group has the revision control.

 

Because of the size of the document we will increase the review time to three

weeks. Are you able to review this draft by Friday June 17, 2016? Please respond

in a timely fashion.

 

Thanks, Ross

(as MPLS WG chair)

 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
류정동 | 18 Jun 05:27 2016
Picon
Picon

회신: 회신: Review of draft-ietf-mpls-tp-linear-protection-mib-07

Loa, thank you for looking into this.

You have the most recent email on this work.
I am still waiting for Joan's response.

Best regards

Jeong-dong


-------- 원본 이메일 --------
보낸 사람: Loa Andersson <loa <at> pi.nu>
날짜: 16/6/17 19:20 (GMT+09:00)
받은 사람: 류정동 <ryoo <at> etri.re.kr>, Joan Cucchiara <jcucchiara.ietf <at> gmail.com>
참조: Joan Cucchiara <jcucchiara <at> mindspring.com>, mpls <at> ietf.org, draft-ietf-mpls-tp-linear-protection-mib <at> ietf.org, mpls-chairs <at> ietf.org, mib-doctors <at> ietf.org
제목: Re: [mpls] 회신: Review of draft-ietf-mpls-tp-linear-protection-mib-07

Jeong-dong and Joan,

This is the latest I have on this document, what is the status today?

/Loa

On 2016-05-27 03:09, Ryoo, Jeong-dong  wrote:
> Joan, thanks.
>
>
> We are looking forward to hearing from you soon.
>
>
> Jeong-dong
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
> *보낸 사람 : *"Joan Cucchiara" <jcucchiara.ietf <at> gmail.com>
> *보낸 날짜 : *2016-05-26 23:09:46 ( +09:00 )
> *받는 사람 : *류정동 <ryoo <at> etri.re.kr>
> *참조 : *Joan Cucchiara <jcucchiara <at> mindspring.com>, Loa Andersson
> <loa <at> pi.nu>, mpls <at> ietf.org <mpls <at> ietf.org>,
> draft-ietf-mpls-tp-linear-protection-mib <at> ietf.org
> <draft-ietf-mpls-tp-linear-protection-mib <at> ietf.org>,
> mpls-chairs <at> ietf.org <mpls-chairs <at> ietf.org>, mib-doctors <at> ietf.org
> <mib-doctors <at> ietf.org>
> *제목 : *Re: [mpls] 회신: Review of
> draft-ietf-mpls-tp-linear-protection-mib-07
>
>
>
> Jeong-dong,
>
>
>
>
>
> Thank you for the responses to my comments.   I will take a look at the
> updated draft soon.
>
>
>
>
>
> -Joan
>
>
>
>
>
> On Thu, May 19, 2016 at 9:24 AM, 류정동 <ryoo <at> etri.re.kr
> <mailto:ryoo <at> etri.re.kr>> wrote:
>
>
>
>     Dear Joan,
>
>
>
>
>
>     We resolved all of your comments and uploaded a revsion today.
>
>
>
>
>
>     Please, see inlines starting with [Authors] in your previous email
>     below.
>
>
>
>
>
>     The revised draft can be found in:
>
>
>
>     https://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-mib-08.txt
>
>
>
>
>
>
>     We appreciate your help on this draft.
>
>
>
>
>
>     Best regards,
>
>
>
>
>
>     Jeong-dong
>
>
>
>
>
>     ________________________________________
>
>
>
>     보낸 사람: Joan Cucchiara [jcucchiara <at> mindspring.com
>     <mailto:jcucchiara <at> mindspring.com>]
>
>
>
>     보낸 날짜: 2016년 4월 5일 화요일 오전 12:10
>
>
>
>     받는 사람: Loa Andersson; mpls <at> ietf.org <mailto:mpls <at> ietf.org>;
>     draft-ietf-mpls-tp-linear-protection-mib <at> ietf.org
>     <mailto:draft-ietf-mpls-tp-linear-protection-mib <at> ietf.org>;
>     mpls-chairs <at> ietf.org <mailto:mpls-chairs <at> ietf.org>
>
>
>
>     참조: mib-doctors <at> ietf.org <mailto:mib-doctors <at> ietf.org>
>
>
>
>     제목: Review of draft-ietf-mpls-tp-linear-protection-mib-07
>
>
>
>
>
>     Comments for draft-ietf-mpls-tp-linear-protection-mib-07.txt
>
>
>
>
>
>     Authors,
>
>
>
>
>
>     Lots of work went into this draft.  The early MIB Doctor review
>
>
>
>     comments have been incorporated, so thank you for that.   These
>
>
>
>     comments are arranged in 3 sections:  MIB compiler outputs,
>
>
>
>     General Comments which are observations that apply to several
>
>
>
>     places in the MIB and should be checked for throughout the MIB.
>
>
>
>
>
>     The last section is for specific comments.
>
>
>
>
>
>     Please take these comments as part of the last call.
>
>
>
>
>
>     Thanks,
>
>
>
>     -Joan
>
>
>
>
>
>     Compiles cleanly with smilint
>
>
>
>
>
>     smicng flagged some errors
>
>
>
>     Output from smicng
>
>
>
>     E: f(MPLS-LSP-MIB.my), (370,4) Row "mplsLpsConfigEntry" may not
>
>
>
>     have columns with MAX-ACCESS of read-write if any column is read-create
>
>
>
>     E: f(MPLS-LSP-MIB.my), (378,15) Index item
>
>
>
>     "mplsLpsConfigDomainIndex" must be defined with syntax that
>
>
>
>     includes a range
>
>
>
>     E: f(MPLS-LSP-MIB.my), (907,4) Item "mplsLpsMeConfigDomainIndex"
>
>
>
>     has invalid value for MAX-ACCESS
>
>
>
>
>
>
>
>     When looking at the MIB, I see that there do appear to be some
>     potential
>
>
>
>     errors:
>
>
>
>        mplsLpsConfigCommand OBJECT-TYPE
>
>
>
>           SYNTAX      MplsLpsCommand
>
>
>
>           MAX-ACCESS  read-write    <---- should be read-create
>
>
>
>
>
>     because row created using RowStatus
>
>
>
>           STATUS      current
>
>
>
>
>
>     [Authors] OK, Fixed.
>
>
>
>
>
>     In general, indices should specify a range so this is why it was
>
>
>
>     flagged by compiler.  Looking at this specific index would like to
>
>
>
>     understand how the value is supposed to be assigned?   If this is
>
>
>
>     assigned by an operator, perhaps there should be a mechanism for
>
>
>
>     the operator to choose a value (for example, by using a
>
>
>
>     IndexIntegerNextFree object)?  Please clarify.
>
>
>
>
>
>        mplsLpsConfigDomainIndex OBJECT-TYPE
>
>
>
>           SYNTAX        Unsigned32
>
>
>
>
>
>     [Authors] Fixed by using the IndexIntegerNextFree object.
>
>
>
>
>
>     mplsLpsMeConfigDomainIndex <--- name implies that this is an index
>
>
>
>     but it is NOT included in the INDEX clause for this table.
>
>
>
>
>
>     Please clarify what is intended.
>
>
>
>
>
>     [Authors] This is not the INDEX for this table. It is used to
>     identify the corresponding mplsLpsConfigDomainIndex value in the
>     other table, “mplsLpsConfigTable”. The name of this object is
>     changed to mplsLpsMeConfigDomainIndexValue to avoid confusion.
>
>
>
>
>
>
>
>     General Comments:
>
>
>
>     =====================
>
>
>
>
>
>     * There are mentions of there being two MIB Modules in this
>
>
>
>     document, but there is only one MIB Module. I have tried to note
>
>
>
>     these statements under specific comments, but please check for
>
>
>
>     such statements.   If the intention is to create two MIB Modules,
>
>
>
>     that is fine, but currently, there is only one.
>
>
>
>
>
>     [Authors] Yes, there is only one defined in this document. Fixed
>
>
>
>
>
>     * The relationships of these Tables is not clear.
>
>
>
>     MplsLpsConfigTable has an INDEX but how the operator
>
>
>
>     is supposed to choose a value for this index is
>
>
>
>     not specified.  The MplsLpsMeConfigTable indexing is confusing.
>
>
>
>     Although the document states that this table is an extension
>
>
>
>     of the MPLSOamIdMeTable, the name of the object,
>
>
>
>     mplsLpsMeConfigDomainIndex is confusing because it suggests
>
>
>
>     this is an INDEX (as does the status of not-accessible).   Please
>     clarify.
>
>
>
>
>
>     [Authors] Fixed by using the IndexIntegerNextFree object and
>     changing the name of mplsLpsConfigDomainIndex to
>     mplsLpsMeConfigDomainIndexValue
>
>
>
>
>
>     Since the indexing for these Tables is confusing to me, then
>
>
>
>     please realize that this MIB may have additional comments
>
>
>
>     during the next review once the indexing is clarified.
>
>
>
>
>
>     * In general more REFERENCE Clauses could/should be added throughout
>     MIB.
>
>
>
>
>
>     Objects such as mplsLpsMeConfigDomainIndex, mplsLpsMeStatusCurrent,
>
>
>
>     mplsLpsConfigMode, mplsLpsConfigProtectionType, etc.   This was also
>
>
>
>     mentioned during the early MIB Dr. review.
>
>
>
>
>
>     [Authors] OK. Added more REFERENCE Clauses.
>
>
>
>
>
>     * Some of the objects use Integer32 but they probably should
>
>
>
>     use Unsigned32.   In other words, if the objects can only take on
>     values 0
>
>
>
>     and above, then
>
>
>
>     they should use Unsigned32.
>
>
>
>
>
>     e.g.     mplsLpsConfigSdBadSeconds, mplsLpsConfigSdGoodSeconds,
>
>
>
>     mplsLpsConfigWaitToRestore, mplsLpsConfigHoldOff, etc.  Please
>
>
>
>     check all the Integer32 objects to see if they should be Unsigned32.
>
>
>
>
>
>     [Authors] OK, Fixed.
>
>
>
>
>
>     *) Date is same a previous version.  This should be updated for
>
>
>
>     every revision of the document.  Please update.
>
>
>
>           LAST-UPDATED  and REVISION clauses
>
>
>
>         "201512060000Z"  -- December 06, 2015
>
>
>
>
>
>     [Authors] OK, Fixed.
>
>
>
>
>
>     *) Only FullCompliance is done for this MIB Module.  As you
>
>
>
>     probably are aware, not all operators want to configure
>
>
>
>     using SNMP, if there is not a ReadOnly Compliance available, then
>
>
>
>     they will not be compliant with the MIB.  I think a ReadOnly Compliance
>
>
>
>     for a MIB is useful and would like to understand why this MIB
>     doesn't have
>
>
>
>     one.
>
>
>
>     Could the authors please clarify?
>
>
>
>
>
>     [Authors] OK, ReadOnly Compliance is added.
>
>
>
>
>
>
>
>     Specific Comments:
>
>
>
>
>
>     Section 1. Introductions
>
>
>
>
>
>     Mentions multiple MIB Modules but there is only one.  Please
>
>
>
>     clarify the text:  "However, since the MIB modules ..." <-- plural
>
>
>
>
>
>     [Authors] Yes, there is only one. Fixed.
>
>
>
>
>
>
>
>     Section 4.
>
>
>
>
>
>     As mentioned before there is only 1 MIB module.  Please update.
>
>
>
>
>
>        "This document specifies a MIB module
>
>
>
>         for the Label Edge Router (LER)
>
>
>
>         that supports MPLS TP Linear protection and a MIB
>
>
>
>         module that defines textual conventions....."
>
>
>
>
>
>     [Authors] OK. Fixed.
>
>
>
>
>
>     Section 5.1 Textual Conventions
>
>
>
>
>
>     * I don't see a separate MIB Module for TCs.  Please clarify.
>
>
>
>
>
>     [Authors] Fixed.
>
>
>
>
>
>     Section 5.4 The Table Structure
>
>
>
>
>
>      * The mplsLpsConfigTable
>
>
>
>
>
>     "The protection domain is identified by mplsLpsConfigGroupName."
>
>
>
>     This statement does not seem to be entirely accurate given the MIB
>
>
>
>     design for 2 reasons, 1.  there doesn't seem to be an object
>
>
>
>     mplsLpsConfigGroupName
>
>
>
>     and 2. the INDEX is mplsLpsConfigDomainIndex Unsigned32 (which also
>     appears
>
>
>
>     in the
>
>
>
>     mplsLpsMeConfigEntry with a status of not-accessible
>
>
>
>     (and I think you intend for it to be an object)?
>
>
>
>
>
>     [Authors] “mplsLpsConfigGroupName” should be
>     “mplsLpsConfigDomainName”. It’s been corrected.
>
>
>
>
>
>     As a reviewer, this is confusing because the relationship with
>
>
>
>     these tables is unclear and so it is very difficult to
>
>
>
>     review the MIB Module.  Please clarify the relationship with
>
>
>
>     these tables and to the mplsOamIdMeTable in the
>
>
>
>     MPLS-OAM-ID-STD-MIB.
>
>
>
>
>
>     [Authors] A protection domain consists of two paths, working and
>     protection paths, and requires two OAM MEs; one OAM ME for the
>     working path and the other ME for the protection path. In other
>     words, a row of “mplsLpsConfigTable” is for one protection domain,
>     which requires two rows in “mplsOamIdMeTable”: one for the working
>     path and the other for the protection path. Also note that an entry
>     of “mplsOamIdMeTable” may not belong to any protection domain. The
>     row of “mplsLpsMeConfigTable” defined in this document has a sparse
>     relationship with that of the “mplsOAMIdMeTable” defined in RFC 7697.
>
>
>
>
>
>
>
>     "The other attributes in this table", do you mean objects?
>
>
>
>
>
>     [Authors] Yes. Fixed.
>
>
>
>
>
>
>
>     * The  mplsLpsStatusTable
>
>
>
>
>
>     There is no mention that the mplsLpsStatusTable's Entries have an
>
>
>
>     AUGMENTS relationship with the mplsLpsConfigTable Entries.  Please add.
>
>
>
>
>
>     [Authors] Added.
>
>
>
>
>
>
>
>     6.1  Relationship to the MPLS OAM maintenance identifier MIB Module
>
>
>
>
>
>     The title needs to be capitalized correctly, Relationship to the
>
>
>
>     MPLS OAM Maintenance Identifier MIB Module
>
>
>
>
>
>     Please update this section to use RFC7697 (and in Informative
>     References
>
>
>
>     also)
>
>
>
>     instead of draft-ietf-mpls-tp-oam-id-mib.
>
>
>
>
>
>     [Authors] Ok. Fixed.
>
>
>
>
>
>
>
>     As mentioned above, the mplsLpsMeConfigTable has an object
>
>
>
>     mplsLpsMeConfigDomainIndex which is (not-accessible).
>
>
>
>     Is this supposed to be an INDEX, or is this an object?   I am
>
>
>
>     confused by what is intended.
>
>
>
>
>
>     [Authors] The name of this object is changed to
>     mplsLpsMeConfigDomainIndexValue to avoid confusion.
>
>
>
>
>
>
>
>     7.  Example of Protection switching configuration for
>
>
>
>
>
>     MPLS-TP TE tunnel (Please change title:  Example of Protection
>     Switching
>
>
>
>     Configuration)
>
>
>
>
>
>     * I am unclear how mplsLspConfigEntry is actually configured for
>
>
>
>     use in this example.   Is an operator supposed to randomly choose an
>     INDEX
>
>
>
>     value?
>
>
>
>
>
>     Would an IndexNext object be useful to use in conjunction with this
>     INDEX?
>
>
>
>
>
>     [Authors] Yes, it has been addressed with IndexIntegerNextFree.
>
>
>
>
>
>
>
>
>
>     MIB Module
>
>
>
>     ------------
>
>
>
>
>
>     (general comment:  the DESCRIPTION clauses could be more readable
>
>
>
>     if consistency was used.  Sometimes the
>
>
>
>     value is listed on the side and the description follows on the
>
>
>
>     same line and sometimes the value is listed
>
>
>
>     on a single line and the description follows a couple of lines
>
>
>
>     after.   Please be consistent.)
>
>
>
>
>
>     [Authors] Ok. Fixed.
>
>
>
>
>
>
>
>     * mplsLpsConfigDomainName  -- Is there a DEFAULT value for this
>
>
>
>     object?   The string size is 1..32 with no
>
>
>
>     option of 0 length string, so wanted to check about a default
>
>
>
>     value?  Under what circumstances can this value
>
>
>
>     be modified?   Please give a REFERENCE.
>
>
>
>
>
>     [Authors] No DEFAULT value is needed. The size has been changed to
>     0..32.
>
>
>
>
>
>
>
>     * mplsLpsConfigMode - Needs REFERENCE (and please try to be
>
>
>
>     specific).  Under what circumstances can this be modified?
>
>
>
>
>
>     [Authors] REFERENCE is given.
>
>
>
>
>
>
>
>     * mplsLpsConfigWaitToRestore
>
>
>
>     Why is this not in minutes?  If someone configures this to be 30
>
>
>
>     seconds is that valid?  Doesn't seem so based on the DESCRIPTION.
>     Please
>
>
>
>     clarify.
>
>
>
>
>
>     [Authors] Fixed with “minutes”. The range is also corrected.
>
>
>
>
>
>
>
>     * mplsLpsConfigHoldOff What is meant by "Can be configured in
>
>
>
>     steps of 100?"   Is this 100 milliseconds?  If so then maybe a
>     better unit
>
>
>
>     choice would be
>
>
>
>     centiseconds.   Please clarify.
>
>
>
>
>
>     [Authors] It can be configured like: 0, 100 ms, 200 ms, … , 10
>     seconds. So, the units and the description are changed using
>     “deciseconds”.
>
>
>
>
>
>     *mplsLpsConfigCommand is read-write.  Is this supposed to be
>
>
>
>     read-create?
>
>
>
>
>
>     [Authors] Yes. Fixed
>
>
>
>
>
>
>
>     *mplsLpsConfigRowStatus --  I think there is some conflicting
>
>
>
>     advice given to the operator.  Several objects say that it is fine
>     to change
>
>
>
>     the
>
>
>
>     value of the object when RowStatus is active, but this is not specified
>
>
>
>     consistently.  Limiting the
>
>
>
>     values of RowStatus in the Conformance Section
>
>
>
>     may be the way to go.  Please clarify.
>
>
>
>
>
>     [Authors] There are some objects that can be changed during protocol
>     operation, while other objects cannot be changed but their values
>     need to be given before the operation. In the revision, we specified
>     them consistently.
>
>
>
>
>
>
>
>     *mplsLpsMeConfigState is a read-create. This is probably okay, but
>
>
>
>     again, that depends on if mplsLpsMeConfigDomainIndex
>
>
>
>     is an INDEX for this table given that it has a status of
>     not-accessible,
>
>
>
>     etc.
>
>
>
>
>
>     [Authors] “mplsLpsMeConfigDomainIndex” was not intended to be INDEX,
>     but to contain the value of the value of protection domain index. We
>     changed it to mplsLpsMeConfigDomainIndexValue to avoid confusion
>
>
>
>
>
>
>
>     *mplsLpsMeStatusSwitchoverSeconds
>
>
>
>     Needs a units clause for Seconds
>
>
>
>
>
>     [Authors] Fixed.
>
>
>
>
>
>
>
>     Notifications
>
>
>
>
>
>     There are a couple Notifications that are send when values of certain
>
>
>
>     counters increment.  Maybe this is valid, but it seems suspect.
>
>
>
>     If a management stations needs information on counters,
>
>
>
>     why can't it just retrieve them at that point?   I don't see any
>
>
>
>     counter discontinuity objects, so was wondering about that too.
>
>
>
>
>
>     [Authors] Whenever there is an increment in any of the enabled
>     counters, network operators need to be alarmed.
>
>
>
>
>
>
>
>     * mplsLpsEventFopTimOut Notification
>
>
>
>
>
>     Please rename this to mplsLpsEventFopTimeout
>
>
>
>
>
>     [Authors] OK. Fixed.
>
>
>
>
>
>
>
>     * Compliance/Conformance Section of the MIB Module
>
>
>
>
>
>     Currently, there is only FullCompliance.   Why is there no
>
>
>
>     ReadOnlyCompliance?
>
>
>
>
>
>     [Authors] OK. It’s been added.
>
>
>
>
>
>
>
>     --- end of comments ---
>
>
>
>
>
>
>
>     _______________________________________________
>
>
>
>     mpls mailing list
>
>
>
>     mpls <at> ietf.org <mailto:mpls <at> ietf.org>
>
>
>
>     https://www.ietf.org/mailman/listinfo/mpls
>
>
>
>
>
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
internet-drafts | 15 Jun 08:34 2016
Picon

I-D Action: draft-ietf-mpls-tp-shared-ring-protection-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology
        Authors         : Weiqiang Cheng
                          Lei Wang
                          Han Li
                          Huub van Helvoort
                          Kai Liu
                          Jie Dong
                          Jia He
                          Fang Li
                          Jian Yang
                          Junfang Wang
	Filename        : draft-ietf-mpls-tp-shared-ring-protection-02.txt
	Pages           : 47
	Date            : 2016-06-14

Abstract:
   This document describes requirements, architecture and solutions for
   MPLS-TP Shared Ring Protection (MSRP) in the ring topology for point-
   to-point (P2P) services.  The mechanism of MSRP is illustrated and
   how it satisfies the requirements for optimized ring protection in
   RFC 5654 is analyzed.  This document also defines the Ring Protection
   Switch (RPS) Protocol which is used to coordinate the protection
   behavior of the nodes on MPLS ring.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-tp-shared-ring-protection-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-shared-ring-protection-02

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/

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Alexander Vainshtein | 14 Jun 12:22 2016

YANG for MPLS-TP?

Hi all,

I wonder what are the WG plans (if any) regarding YANG data models for MPLS-TP.

 

While it is obviously true that static MPLS and MPLS-TP are different (neither is the subset of the other), MPLS-TP is today the most important application of static MPLS.

 

However, after looking up  draft-ietf-mpls-static-yang I did not find there any mention of MPLS-TP-specific issues.

 

One example that comes to mind is co-routed bi-directional and associated bi-directional MPLS-TP LSPs. Other issues include:

1.       MPLS-TP Identifiers (i.e. YANG model for RFC 6370). From my POV such a data model is a pre-requisite for all MPLS-TP-related work

2.       MPLS-TP protection mechanisms

3.       MPLS-TP OAM mechanisms. There is an individual draft that tries to address these issues, but it looks to me like very much incomplete. E.g.:

o   It does not even mention RFC 6428

o   While RFC 6427 appears in the list of Normative references in this draft, there are no actual references to this document.

 

Any inputs in this regard would be highly appreciated.

 

Regards, and lots of thanks in advance,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein <at> ecitele.com

 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
internet-drafts | 12 Jun 09:41 2016
Picon

I-D Action: draft-ietf-mpls-static-yang-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : A YANG Data Model for MPLS Static LSPs
        Authors         : Tarek Saad
                          Kamran Raza
                          Rakesh Gandhi
                          Xufeng Liu
                          Vishnu Pavan Beeram
                          Himanshu Shah
                          Igor Bryskin
                          Xia Chen
                          Raqib Jones
                          Bin Wen
	Filename        : draft-ietf-mpls-static-yang-00.txt
	Pages           : 13
	Date            : 2016-06-11

Abstract:
   This document contains the specification for the MPLS Static Label
   Switched Paths (LSPs) YANG model.  The model allows for the
   provisioning of static LSP(s) on LER(s) and LSR(s) devices along a
   LSP path without the dependency on any signaling protocol.  The MPLS
   Static LSP model augments the MPLS base YANG model with specific data
   to configure and manage MPLS Static LSP(s).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-static-yang-00

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/

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

internet-drafts | 12 Jun 09:41 2016
Picon

I-D Action: draft-ietf-mpls-base-yang-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : A YANG Data Model for MPLS Base
        Authors         : Tarek Saad
                          Kamran Raza
                          Rakesh Gandhi
                          Xufeng Liu
                          Vishnu Pavan Beeram
                          Himanshu Shah
                          Igor Bryskin
                          Xia Chen
                          Raqib Jones
                          Bin Wen
	Filename        : draft-ietf-mpls-base-yang-00.txt
	Pages           : 10
	Date            : 2016-06-11

Abstract:
   This document contains a specification of the the MPLS base YANG
   model.  The MPLS base YANG module serves as a base framework for
   configuring and managing an MPLS switching subsystem.  It is expected
   that other MPLS technology YANG models (e.g.  MPLS LSP Static, LDP or
   RSVP-TE models) will augment the MPLS base YANG model.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-base-yang/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-base-yang-00

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/

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

internet-drafts | 10 Jun 20:20 2016
Picon

I-D Action: draft-ietf-mpls-flow-ident-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : MPLS Flow Identification Considerations
        Authors         : Stewart Bryant
                          Carlos Pignataro
                          Mach Chen
                          Zhenbin Li
                          Gregory Mirsky 
	Filename        : draft-ietf-mpls-flow-ident-01.txt
	Pages           : 11
	Date            : 2016-06-10

Abstract:
   This memo discusses the desired capabilities for MPLS flow
   identification.  The key application that needs this is in-band
   performance monitoring of user data packets.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-flow-ident/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-flow-ident-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-flow-ident-01

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/

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Tarek Saad (tsaad | 9 Jun 18:46 2016
Picon

YANG label type definition for multiple technologies

Hi WGs,

 

In our last TE YANG meeting, the team discussed the issue of a unified YANG label type that can apply to multiple technologies. Below are some minutes. Let us know if you have further comments/suggestions.

For reference, RFC3471 (section 3.2.1) defines the generalized label as a variable length field whose interpretation is dependent on the link label type.

Also RFC7139 (section 6.1) defines the OTN label as variable size field too.

 

Two options were discussed: A) strict label type definition per technology, B) unified generic label type that applies to all technologies

 

Couple of things that we thought may need to be covered:

  1. Sanity on label value(s) on per technology:

    1. For A) the sanity could be implicit in the label type definition, e.g.

  typedef mpls-label {

    type uint32 {

      range "0..1048575";

    }

  }

    1. For B):

                                                               i.      the sanity can be done in YANG with a “must” check under the respective leaf(s), or

                                                             ii.      the sanity can be left for the device backend to validate input values – no check in YANG

 

  1. We debated if an abstract (technology-independent) YANG model(s) may require the use of generic label type – e.g. to cover a case of multiple technologies objects being represented in same model.

 

 

Here are options we discussed:

A. Per-technology strict type definitions (e.g. mpls-label, otn-label, etc..):

- MPLS technology type:

  typedef mpls-label {

    type uint32 {

      range "0..1048575";

    }

  }

 

in MPLS model use:

e.g. for MPLS LSPs, use

  leaf incoming-label {

    type mpls:mpls-label;

  }

 

- OTN technology (rfc7139, section 6.1 defines variable size field):

  typedef otn-label {

    type binary;

  }

 

e.g. for OTN LSPs, use

  leaf incoming-label {

    type otn:otn-label;

  }

 

B. Generalized label type (liberal):

Geneic label covers all label types by defining it as binary with no strict length check.

typedef generic-label {

  type binary;

}

 

somewhat similar to way ip-address type is defined in YANG:

typedef ip-address {

 type union {

   type ipv4-address;

   type ipv6-address;

 }

}

 

in MPLS model use:

e.g. for MPLS LSPs, use

  leaf incoming-label {

    type generic-label;

    must “0 <= current() <= 1048575”

  }

 

Regards,

Tarek

 

 

 

 

From: tsaad <at> cisco.com
When: 9:00 AM - 10:00 AM June 10, 2016
Subject: MPLS and TE tunnels YANG data model meeting
Location: webex

 

 

Refreshing invite for MPLS and TE tunnels YANG data model meeting. Please forward to anyone I missed.

 

 



-- Do not delete or change any of the following text. --


Join WebEx meeting
Meeting number: 208 554 462
Meeting password: 3jwMRXEd


If you are a host, go here to view host information.

Join by phone
+1-408-525-6800 Call-in toll number (US/Canada)
+1-866-432-9903 Call-in toll-free number (US/Canada)
Access code: 208 554 462
Numeric meeting password: 24305603
Global call-in numbers
| Toll-free calling restrictions


Can't join the meeting? Contact support.

IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session..

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Gmane