Loa Andersson | 28 Aug 23:11 2014
Picon

Consensus call on draft-ietf-mpls-ipv6-only-gap

Working Group,

draft-ietf-mpls-ipv6-only-gap has been been through working group last, 
with only supportive comments.

We also had a Routing Area Directorate review that also did not bring
up any major technical points. However a few points were brought up,
such as

- this is a very important document, but since is a gap analysis it is
   also only document what is true at a certain point time, and the
   half-life of the document will be fairly short and it doubtful if
   there is value publishing it as an RFC.

- There have also be been some ideas that we should move pointers
   pointers to an appendix or remove them entirely. In order to avoid
   mandating certain solutions before the become working group work
   items.

The working group chairs find that the working group have consensus to 
move ahead with the document (version -02) as it has been updated after
the wglc and reviews.

The value in having  the document publish by far outweigh not having it
published. The benefits in moving the reference to an appendix (or
removing them) is not comparable to have easily at hand when reading
the document.

However, once we have this document published as an RFC we understand 
that keeping on updating an RFC is hardly possible to follow the
(Continue reading)

Stig Venaas | 28 Aug 00:52 2014

Routing Directorate QA review of draft-ietf-mpls-pim-sm-over-mldp-00

Hi

I've been selected as the routing directorate QA reviewer for
draft-ietf-mpls-pim-sm-over-mldp-00. This is part of the QA process
described at https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

The document looks great to me. It is easy to read and I cannot find
any issues with it. The security considerations are quite short, I'm
wondering if there truly are no other considerations.

Idnits shows a few issues, please consider those.

Stig

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

internet-drafts | 27 Aug 18:15 2014
Picon

I-D Action: draft-ietf-mpls-rfc6374-udp-return-path-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 Working Group of the IETF.

        Title           : RFC6374 UDP Return Path
        Authors         : Stewart Bryant
                          Siva Sivabalan
                          Sagar Soni
	Filename        : draft-ietf-mpls-rfc6374-udp-return-path-00.txt
	Pages           : 8
	Date            : 2014-08-27

Abstract:
   This document specifies the proceedure to be used by the Packet Loss
   and Delay Measurement for MPLS Networks protocol defined in RFC6374
   when sending and processing MPLS performance management out-of-band
   responses for delay and loss measurements over an IP/UDP return path.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-rfc6374-udp-return-path-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/

(Continue reading)

Adrian Farrel | 26 Aug 22:32 2014
Picon

Routing Area Tuning - What I heard

Hi,

[Please respond on routing-discussion <at> ietf.org even though I am spamming several
lists]

Thanks for the input on this topic.

I heard a number of opinions about whether to split TE architecture away from
RSVP-TE. I think this leads to some roughish consensus as follows:

TEAS
- core RSVP-TE
- RSVP-TE for generic cases
- IGP-TE extensions in coordination with IGP WGs
- TE architecture
   - including the applicability of PCE for TE in association with PCE WG
- relationships with
   - OSPF and ISIS as above
   - PCE as above
   - MPLS for generalisation of packet-specific protocol extensions
   - CCAMP for generalisation of non-packet-specific protocol extensions

CCAMP
- non-packet technology-specific RSVP-TE
- non-packet technology-specific IGP-TE in association with IGP WGs
- consideration to generalise all protocol extensions via TEAS

That leaves...

MPLS as it is today, except:
(Continue reading)

internet-drafts | 25 Aug 15:17 2014
Picon

I-D Action: draft-ietf-mpls-ipv6-only-gap-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 Working Group of the IETF.

        Title           : Gap Analysis for Operating IPv6-only MPLS Networks
        Authors         : Wesley George
                          Carlos Pignataro
	Filename        : draft-ietf-mpls-ipv6-only-gap-02.txt
	Pages           : 26
	Date            : 2014-08-25

Abstract:
   This document reviews the Multiprotocol Label Switching (MPLS)
   protocol suite in the context of IPv6 and identifies gaps that must
   be addressed in order to allow MPLS-related protocols and
   applications to be used with IPv6-only networks.  This document is
   not intended to highlight a particular vendor's implementation (or
   lack thereof) in the context of IPv6-only MPLS functionality, but
   rather to focus on gaps in the standards defining the MPLS suite.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-only-gap/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-ipv6-only-gap-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ipv6-only-gap-02

Please note that it may take a couple of minutes from the time of submission
(Continue reading)

Gregory Mirsky | 25 Aug 07:14 2014
Picon

draft-tissa-netmod-oam

Dear Authors, et.al,

please kindly consider my comments and questions to this document:

·         Introduction

o    “… it is a reasonable choice to develop the unified OAM framework based on those (CFM) concepts.” I agree that for packet switching connection-oriented networks that are based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless packet switching networks. Thus extending CFM model onto arbitrary networks without consideration whether these are connection-oriented or connectionless is very questionable approach, IMO;

o   “…CFM, it is a reasonable choice to develop the unified OAM framework based on those concepts” IP OAM is not based on Ethernet Service OAM model or principles but, IMO, OAM of overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

o   “The YANG model presented in this document is the base model and supports IP Ping and Traceroute.” If only these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scope of the document, then, I believe, the title may say something like “YANG model of on-demand OAM tool to detect and localize Loss of Continuity defect”. Referring to ping/traceroute as “generic OAM” comes as stretch too far;

o    “…initiate a performance monitoring session can do so in the same manner regardless of the underlying protocol or technology” I’d point to work of LMAP WG on informational model of performance measurements in large-scale access networks, work of ITU-T’s SG15, MEF. Perhaps sentence can be stopped after “… or a Traceroute”.

o   “In this document we define the YANG model for Generic OAM” Can you provide definition or reference to the definition of the “Generic OAM”? It is challenging to validate informational model of something that not been sufficiently defined.

·         Section 3

o   “This allows users to traverse between OAM of different technologies at ease through a uniform API set.” Usually relationships between OAM layers referred and viewed as OAM interworking. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only scenarios of nested OAM layers but peering layers and thus is broader than introduced in the document “nested OAM”.

o   Figure 1 depicts OAM of both connection-oriented and connectionless networks. What you see common, generic in respective OAM of these networks?

·         Section 4

o   “In IP, the MA can be per IP Subnet …” As there’s no definition of MA in IP, is this the definition or one of examples. Can MA in IP network be other than per IP Subnet?

o   “Under each MA, there can be two or more MEPs (Maintenance End Points)” Firstly, since you adopt MA-centric terminology, MEP stands for Maintenance Association End Point. Secondly, in some OAM models Down and Up MEP being distinguished. Would your model consider that? As there’s no definition of MEP for several networks you’ve listed, e.g. IP, how the YANG model will abstract something that is not defined? And thirdly, how and where MIPs are located in IP OAM?

 

Thank you for your consideration of my notes and looking forward to the interesting discussion.

 

Regards,

        Greg

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Martony Demes | 24 Aug 20:39 2014
Picon

Participation in Grupo

Hello,
     I want participation in grupo MPLS.


--
             Martony Demes
     Analista de Tecnologia da Informação 
       86 9990-9064 [WhatsApp]
        http://mardemes.com 


 


_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
internet-drafts | 22 Aug 16:42 2014
Picon

I-D Action: draft-ietf-mpls-p2mp-loose-path-reopt-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 Working Group of the IETF.

        Title           : Reoptimization of Point-to-Multipoint Traffic Engineering Loosely Routed LSPs
        Authors         : Tarek Saad
                          Rakesh Gandhi
                          Zafar Ali
                          Robert H. Venator
                          Yuji Kamite
	Filename        : draft-ietf-mpls-p2mp-loose-path-reopt-00.txt
	Pages           : 11
	Date            : 2014-08-22

Abstract:
   For a Traffic Engineered (TE) point-to-multipoint (P2MP) Label
   Switched Path (LSP), it is preferable in some cases to re-evaluate
   and re-optimize the entire P2MP-TE LSP by re-signaling all its S2L
   sub-LSP(s). Existing mechanisms allow the path re-evaluation and the
   signaling of a the notification of preferred path exists for a single
   S2L sub-LSP only.

   This document defines RSVP-TE signaling extensions to allow an
   ingress Label Switching Router (LSR) of a P2MP-TE LSP to trigger the
   re-evaluation of the entire LSP tree containing one or more S2L sub-
   LSPs whose paths are loose (or abstract) hop expanded, and for a mid-
   point LSR to signal to the ingress LSR that a better tree exists for
   the entire P2MP-TE LSP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-p2mp-loose-path-reopt/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-p2mp-loose-path-reopt-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

Adrian Farrel | 22 Aug 13:58 2014
Picon

Discussion of tuning Routing Area working groups

Hi,

Just wanted to bring to your attention that there is a discussion on the Routing
Discussion mailing list about possible ways to restructure a few of the working
groups in the Routing Area. This concerns MPLS as the discussion relates to
where to put work concerning TE Architecture and RSVP-TE.

You can subscribe to the list and see the message archive at
https://www.ietf.org/mailman/listinfo/routing-discussion

Please join in if you have an opinion.

Thanks,
Adrian

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

Loa Andersson | 21 Aug 12:31 2014
Picon

Shepherds for MPLS MIB modules

Working Group,

We have for some time been looking for someone to help us shepherding
our MIB modules. I'm happy to announce that Mach Chen and Young Lee has
agreed to help us.

Please help Mach and Young as they start working with the documents.

We've assigned Mach as Shepherd for draft-ietf-mpls-tp-oam-id-mib.

Further shepherd assignments will be done as soon as the details are
sorted out.

/Loa
for the mpls wg chairs
--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

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

Loa Andersson | 21 Aug 08:59 2014
Picon

working group last call for draft-ietf-mpls-pim-sm-over-mldp

Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-pim-sm-over-mldp.

Please send your comments to the mpls wg mailing list (mpls <at> ietf.org).

There is one IPR disclosures against this document. All the authors
and contributors have stated on the working group mailing list that
they are not aware of any other IPRs that relates to this draft.

This working group last call ends September 5, 2014.

/Loa
for the MPLS wg chairs
--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

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


Gmane