RFC Errata System | 28 Apr 15:53 2015

[Errata Verified] RFC7510 (4350)

The following errata report has been verified for RFC7510,
"Encapsulating MPLS in UDP". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7510&eid=4350

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Adrian Farrel <adrian <at> olddog.co.uk>
Date Reported: 2015-04-27
Verified by: Alia Atlas (IESG)

Section: 7

Original Text
-------------
Absent

Corrected Text
--------------
7.1  BGP Tunnel Encapsulation Attribute Tunnel Type

   IANA maintains a registry called "Border Gateway Protocol (BGP)
   Parameters" with a sub-registry called "BGP Tunnel Encapsulation
   Attribute Tunnel Types".  IANA has previously allocated a code point
   called "MPLS in UDP Encapsulation" with value 13. IANA has added
   this document as a further reference for that code point.
(Continue reading)

RFC Errata System | 28 Apr 15:53 2015

[Errata Verified] RFC7510 (4350)

The following errata report has been verified for RFC7510,
"Encapsulating MPLS in UDP". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7510&eid=4350

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Adrian Farrel <adrian <at> olddog.co.uk>
Date Reported: 2015-04-27
Verified by: Alia Atlas (IESG)

Section: 7

Original Text
-------------
Absent

Corrected Text
--------------
7.1  BGP Tunnel Encapsulation Attribute Tunnel Type

   IANA maintains a registry called "Border Gateway Protocol (BGP)
   Parameters" with a sub-registry called "BGP Tunnel Encapsulation
   Attribute Tunnel Types".  IANA has previously allocated a code point
   called "MPLS in UDP Encapsulation" with value 13. IANA has added
   this document as a further reference for that code point.
(Continue reading)

internet-drafts | 28 Apr 11:01 2015
Picon

I-D Action: draft-ietf-mpls-lsp-ping-relay-reply-08.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           : Relayed Echo Reply mechanism for LSP Ping
        Authors         : Jian Luo
                          Lizhong Jin
                          Thomas Nadeau
                          George Swallow
	Filename        : draft-ietf-mpls-lsp-ping-relay-reply-08.txt
	Pages           : 16
	Date            : 2015-04-28

Abstract:
   In some inter autonomous system (AS) and inter-area deployment
   scenarios for RFC 4379 "Label Switched Path (LSP) Ping and
   Traceroute", a replying LSR may not have the available route to the
   initiator, and the Echo Reply message sent to the initiator would be
   discarded resulting in false negatives or complete failure of
   operation of LSP Ping and Traceroute.  This document describes
   extensions to LSP Ping mechanism to enable the replying Label
   Switching Router (LSR) to have the capability to relay the Echo
   Response by a set of routable intermediate nodes to the initiator.
   This document updates RFC 4379.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply-08
(Continue reading)

Gregory Mirsky | 28 Apr 00:49 2015
Picon

MPLS-RT: review draft-cui-mpls-tp-mfp-use-case-and-requirements

Dear Authors, et. al,

I was tasked to review the draft-cui-mpls-tp-mfp-use-case-and-requirements according the guidance:

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).

 

The document is coherent and well written. It does provide clear requirements toward M:N protection mechanism. But I have concerns:

·         There’s no discussion, nor formal definition of what constitutes simultaneous detection of multiple failures. Is that particular time interval, e.g. 10 msec, or relative to a failure detection interval?

·         Discussion of use cases does not demonstrate that there is sufficient number of scenarios where M:N protection is required. Thus I could not conclude that standardization of a solution that would comply with formulated in the document requirements is needed.

Please find more comments to the document below:

·         I found that the document that presents use cases of multi-failure protection and formulates requirements toward possible solution is on Standard track. I think that such document is more appropriate to be on Informational track;

·         Abstract:

o   I believe that references in the Abstract are not suggested and rewording of the first paragraph encouraged.

·         Introduction

o   s/MUST SHOULD/MUST/ - req. 65 and 67 in RFC 5654 use MUST for 1:1 and 1:n protection schemes

·         Document Scope

o   After reference to existing GMPLS-based restoration mechanisms not clear whether scope of the document is on protection or restoration mechanisms. Networks that do not use distributed control plane do use centralized management system. Such management system can provide service restoration in case of cascading failures as pointed in Section 4.1.2. If that is the case, should the document be discussion service resiliency in case of multiple failures?

 

Regards,

                Greg

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
RFC Errata System | 27 Apr 22:21 2015

[Editorial Errata Reported] RFC7510 (4350)

The following errata report has been submitted for RFC7510,
"Encapsulating MPLS in UDP".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7510&eid=4350

--------------------------------------
Type: Editorial
Reported by: Adrian Farrel <adrian <at> olddog.co.uk>

Section: 7

Original Text
-------------
Absent

Corrected Text
--------------
7.1  BGP Tunnel Encapsulation Attribute Tunnel Type

   IANA maintains a registry called "Border Gateway Protocol (BGP)
   Parameters" with a sub-registry called "BGP Tunnel Encapsulation
   Attribute Tunnel Types".  IANA has previously allocated a code point
   called "MPLS in UDP Encapsulation" with value 13. IANA has added
   this document as a further reference for that code point.

Notes
-----
This text reflects a pre-publication agreement to include a request to IANA for the action that it describes.

Note that the text supplied here shows the use of the past tense as is normal in an RFC that reports IANA action.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7510 (draft-ietf-mpls-in-udp-11)
--------------------------------------
Title               : Encapsulating MPLS in UDP
Publication Date    : April 2015
Author(s)           : X. Xu, N. Sheth, L. Yong, R. Callon, D. Black
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

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

internet-drafts | 26 Apr 01:33 2015
Picon

I-D Action: draft-kumarkini-mpls-spring-lsp-ping-03.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           : Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane
        Authors         : Nagendra Kumar
                          George Swallow
                          Carlos Pignataro
                          Nobo Akiya
                          Sriganesh Kini
                          Hannes Gredler
                          Mach(Guoyi) Chen
	Filename        : draft-kumarkini-mpls-spring-lsp-ping-03.txt
	Pages           : 15
	Date            : 2015-04-25

Abstract:
   Segment Routing architecture leverages the source routing and
   tunneling paradigms and can be directly applied to MPLS data plane.
   A node steers a packet through a controlled set of instructions
   called segments, by prepending the packet with Segment Routing
   header.

   The segment assignment and forwarding semantic nature of Segment
   Routing raises additional consideration for connectivity verification
   and fault isolation in LSP with Segment Routing architecture.  This
   document illustrates the problem and describe a mechanism to perform
   LSP Ping and Traceroute on Segment Routing network over MPLS data
   plane.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kumarkini-mpls-spring-lsp-ping/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-kumarkini-mpls-spring-lsp-ping-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-kumarkini-mpls-spring-lsp-ping-03

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

Loa Andersson | 25 Apr 12:27 2015
Picon

Fwd: [Teas] New Wiki: Some informal guidance for standards track protocol specifications

Working Group,

This appears to be a very useful wiki, if you are in the process of
writing a draft please look at it.

/Loa
mpls wg co-chair

-------- Forwarded Message --------
Subject: [Teas] New Wiki: Some informal guidance for standards track 
protocol specifications
Date: Thu, 23 Apr 2015 15:53:52 -0400
From: Lou Berger <lberger <at> labn.net>
To: TEAS WG <teas <at> ietf.org>

All,
     I thought it might be useful to document some topics that repeatedly
get discussed during document reviews.  I started an "informal" wiki on
the topic. It is located at
http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines . Please take
a look at, comment/modify as you see fit.

As chair,

I ask that all WG authors review this guidance in anticipation of
comment topics you're likely to see before/during WG LC.

Thanks,
Lou

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

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

Ross Callon | 22 Apr 02:19 2015
Picon

FW: [Rtg-yang-coord] Fwd: YANG Editing Session at IETF 93

FYI. There will be a “YANG Advice and Editing Session” on Sunday afternoon at the upcoming IETF in Prague. The pointer below gives a bit more information.

 

Ross

 

From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces <at> ietf.org] On Behalf Of Benoit Claise
Sent: Tuesday, April 21, 2015 12:02 PM
To: Rtg-yang-coord <at> ietf.org
Subject: [Rtg-yang-coord] Fwd: YANG Editing Session at IETF 93

 

FYI.

Regards, Benoit



-------- Forwarded Message --------

Subject:

YANG Editing Session at IETF 93

Date:

Tue, 21 Apr 2015 18:01:20 +0200

From:

Benoit Claise <bclaise <at> cisco.com>

To:

NETMOD Working Group <netmod <at> ietf.org>

 

FYI.

http://www.ietf.org/meeting/93/tutorials/yang-session.html

 

Regards, Benoit

 

 

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

Re: MPLS-Support and Document

On 4/18/15, Houssam Eddine Kassah Laouar <houssam.kl <at> gmail.com> wrote:
> Dear MPLS Team,
>
> i find your mail on ietf.org website, so i want to discuss with you
> and i hope i can find my way with.
>
> my name is Houssam Master 2 student in computer science from Algeria
> and i work on my thesis of Master on IP/MPLS Networks.
>
> my Master thesis topic is about: ""Strategy of security for IP / MPLS
> networks in terms of fault tolerance approach""
>
> so any document in this field send it to me and good luck for your's
> project too
>
>
> Thank you in advance
>
> --
>
>
> *|*Thank You*|*شكرا جزيلا لكم*|*
> *|*With our warmest wishes *|* مع أطيب التمنيات *|*
>
> *|*PEOPLE CARE ABOUT HOW TO GET MONEY BUT...*|*
>
> *|*ME I CARE ABOUT HOW CAN I GIVE THEM HONEY *| *
>
> |hOussam Eddine KASSAH LAOUAR|حسام الدين كاسح لعور|
>
> *|CEO&CO-Founder | Constantine Cisco User Group
> <https://www.facebook.com/ConstantineCiscoUserGroup> |*
> *|IT-Responsible| EuroArab Project | AEGEE-Europe / European Students'
> Forum  |*
> *|Master Degree | Computer Science Option ICT | Constantine University |
> Algeria  |*
> *|Mobile : +213 557 552 012 | Mail : houssam.kassah <at> aegee.org
> <houssam.kassah <at> aegee.org> |*
> *|Social Media :  <at> hOussamKASSAH <https://twitter.com/hOussamKASSAH>| Skype
> :  dr.housekl | My Facebook <https://www.facebook.com/hOussamKASSAH>  | My
> Linkedin <https://www.linkedin.com/in/houssameddinekassahlaouar/>| *
>

-- 

*|*Thank You*|*شكرا جزيلا لكم*|*
*|*With our warmest wishes *|* مع أطيب التمنيات *|*

*|*PEOPLE CARE ABOUT HOW TO GET MONEY BUT...*|*

*|*ME I CARE ABOUT HOW CAN I GIVE THEM HONEY *| *

|hOussam Eddine KASSAH LAOUAR|حسام الدين كاسح لعور|

*|CEO&CO-Founder | Constantine Cisco User Group
<https://www.facebook.com/ConstantineCiscoUserGroup> |*
*|IT-Responsible| EuroArab Project | AEGEE-Europe / European Students'
Forum  |*
*|Master Degree | Computer Science Option ICT | Constantine University |
Algeria  |*
*|Mobile : +213 557 552 012 | Mail : houssam.kassah <at> aegee.org
<houssam.kassah <at> aegee.org> |*
*|Social Media :  <at> hOussamKASSAH <https://twitter.com/hOussamKASSAH>| Skype
:  dr.housekl | My Facebook <https://www.facebook.com/hOussamKASSAH>  | My
Linkedin <https://www.linkedin.com/in/houssameddinekassahlaouar/>| *

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
rfc-editor | 17 Apr 22:38 2015

RFC 7506 on IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM)

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7506

        Title:      IPv6 Router Alert Option for 
                    MPLS Operations, Administration, and Maintenance (OAM) 
        Author:     K. Raza, N. Akiya, C. Pignataro
        Status:     Standards Track
        Stream:     IETF
        Date:       April 2015
        Mailbox:    skraza <at> cisco.com, 
                    nobo.akiya.dev <at> gmail.com, 
                    cpignata <at> cisco.com
        Pages:      6
        Characters: 11322
        Updates:    RFC 4379

        I-D Tag:    draft-ietf-mpls-oam-ipv6-rao-03.txt

        URL:        https://www.rfc-editor.org/info/rfc7506

RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute
mechanism in which the Router Alert Option (RAO) MUST be set in the
IP header of the MPLS Echo Request messages and may conditionally be
set in the IP header of the MPLS Echo Reply messages depending on the
Reply Mode used.  While a generic "Router shall examine packet"
Option Value is used for the IPv4 RAO, there is no generic RAO value
defined for IPv6 that can be used.  This document allocates a new,
generic IPv6 RAO value that can be used by MPLS Operations,
Administration, and Maintenance (OAM) tools, including the MPLS Echo
Request and MPLS Echo Reply messages for MPLS in IPv6 environments.
Consequently, it updates RFC 4379.

The initial motivation to request an IPv6 RAO value for MPLS OAM
comes from the MPLS LSP Ping/Traceroute.  However, this value is
applicable to all MPLS OAM and not limited to MPLS LSP Ping/
Traceroute.

This document is a product of the Multiprotocol Label Switching Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

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

Stephen Farrell | 17 Apr 14:10 2015
Picon
Picon

would the WG like to adopt draft-farrelll-mpls-opportunistic-encrypt?


Hiya,

Adrian and I wrote up [1]. How'd the WG feel about adopting
that? If you did, I'd be willing to continue editing if you
wanted. So consider this as a request that the WG take on
this work.

In case it helps, the current abstract is:

"
   This document describes a way to apply opportunistic security
   between adjacent nodes on an MPLS Label Switched Path (LSP) or
   between end points of an LSP.  It explains how keys may be agreed
   to enable encryption, and how key identifiers are exchanged in
   encrypted MPLS packets.  Finally, this document describes the
   applicability of this approach to opportunistic security in MPLS
   networks with an indication of the level of improved security as
   well as the continued vulnerabilities.

   This document does not describe security for MPLS control plane
   protocols.
"

Cheers,
S.

[1] https://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt

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


Gmane