Loa Andersson | 20 May 11:55 2015
Picon

Poll to see if we have consensus adopting draft-bonica-mpls-self-ping as an MPLS wg document

Working Group,

This is to start a two week poll on adopting draft-bonica-mpls-self-
ping-06 as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls <at> ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There is one IPR disclosures directly against this document. All the
authors has stated on the working group mailing that they are unaware of
any undisclosed IPRs against this document.

However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

This poll ends June 5, 2015.

/Loa
--

-- 

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
(Continue reading)

Markus Jork | 19 May 05:07 2015
Picon

Re: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

I was asked to review draft-mirsky-mpls-residence-time-06.txt as part of the review team process.

The document provides justification for why residence time measurement for MPLS LSPs may be useful and
coherently describes the procedure for performing it. However, I could not understand the 2-step
process from reading this document.

The proposed rsvp extensions look technically sound. Though I do question the extra complexity
introduced for keeping track of the RTM capable LSRs (using the RTM_SET object). While I generally
understand the value in supporting incremental deployment of new features, I do wonder how much value
there is in doing partial residence time measurements for random sub-sections of an LSP? Are the
incomplete measurements done in such a scenario really worth the added protocol complexity?

The document talks about the difficulties of applying the measurement procedure to LDP networks due to
ECMP. Maybe it should also discuss potential difficulties with rsvp when there is link
aggregation/bundling which could lead to load-balancing over multiple egress interfaces?

I can't really comment on the usefulness of the document as I'm not familiar with the time synchronization
protocols and use cases.
Under the assumption that partial residence time measurements for an LSP are useful, I think the document
is ready for WG adoption.

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

RFC Errata System | 18 May 23:19 2015

[Errata Rejected] RFC5586 (4364)

The following errata report has been rejected for RFC5586,
"MPLS Generic Associated Channel".

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

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Alexander ("Sasha") Vainshtein <Alexander.Vainshtein <at> ecitele.com>
Date Reported: 2015-05-12
Rejected by: Deborah Brungard (IESG)

Section: 4.2.1

Original Text
-------------
   The Time-To-Live (TTL) field of the LSE that contains the GAL follows
   the definition and processing rules specified in [RFC3443].

Corrected Text
--------------
The value of the  Time-To-Live (TTL) field of the LSE that contains the 
GAL follows is irrelevant as long as it exceeds 1. (Setting this value 
to 0 or 1 SHOULD be avoided because it could result in trapping the OAM 
packets in with wrong reason: "TTL expiration" instead of "GAL  
encountered").  

(Continue reading)

internet-drafts | 18 May 18:06 2015
Picon

I-D Action: draft-bonica-mpls-self-ping-06.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           : LSP Self-Ping
        Authors         : Ravi Torvi
                          Ron Bonica
                          Ina Minei
                          Michael Conn
                          Dante Pacella
                          Luis Tomotaki
                          Mark Wygant
	Filename        : draft-bonica-mpls-self-ping-06.txt
	Pages           : 11
	Date            : 2015-05-18

Abstract:
   When certain RSVP-TE optimizations are implemented, ingress LSRs can
   receive RSVP RESV messages before forwarding state has been installed
   on all downstream nodes.  According to the RSVP-TE specification, the
   ingress LSR can forward traffic through an LSP as soon as it receives
   a RESV message.  However, if the ingress LSR forwards traffic through
   the LSP before forwarding state has been installed on all downstream
   nodes, traffic can be lost.

   This memo describes LSP Self-ping.  When an ingress LSR receives an
   RESV message, it can invoke LSP Self-ping procedures to ensure that
   forwarding state has been installed on all downstream nodes.

   LSP Self-ping is an extremely light-weight mechanism.  It does not
(Continue reading)

internet-drafts | 18 May 15:53 2015
Picon

I-D Action: draft-bonica-mpls-self-ping-05.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           : LSP Self-Ping
        Authors         : Ravi Torvi
                          Ron Bonica
                          Ina Minei
                          Michael Conn
                          Dante Pacella
                          Luis Tomotaki
                          Mark Wygant
	Filename        : draft-bonica-mpls-self-ping-05.txt
	Pages           : 11
	Date            : 2015-05-18

Abstract:
   When certain RSVP-TE optimizations are implemented, ingress LSRs can
   receive RSVP RESV messages before forwarding state has been installed
   on all downstream nodes.  According to the RSVP-TE specification, the
   ingress LSR can forward traffic through an LSP as soon as it receives
   a RESV message.  However, if the ingress LSR forwards traffic through
   the LSP before forwarding state has been installed on all downstream
   nodes, traffic can be lost.

   This memo describes LSP Self-ping.  When an ingress LSR receives an
   RESV message, it can invoke LSP Self-ping procedures to ensure that
   forwarding state has been installed on all downstream nodes.

   LSP Self-ping is an extremely light-weight mechanism.  It does not
(Continue reading)

Lizhong Jin | 17 May 18:08 2015
Picon

Re: MPLS-RT review of draft-farrelll-mpls-opportunistic-encrypt-04.txt

Hi all,
I reviewed draft-farrelll-mpls-opportunistic-encrypt-04 as the member of MPLS Review Team.
I am not an security expert, so I review the draft from the MPLS feasibility point of view,
and think the document is useful and technically sound. I have several questions, and would 
appreciate to resolve them before WG adoption.

Section 2.1, the scale of configuration that is needed for a full set of SAs between all 
communicating parties
[Lizhong] need to expand acronym "SA", security association?

Section 3, Everything that follows the control word is the entire original MPLS packet encrypted.
[Lizhong] also for Figure1, in the PHP case, the original MPLS packet will not have label, then if the 
packet is also encrypted and encapsulated after control work, then how to parse the packet 
correctly? The control word will not tell the following payload is MPLS or IP.

Section 3, The payload is the data carried by the MPLS packet (such as IP) and may be prefixed 
by a control word.
[Lizhong] if the control word is optional, then do we need any negotiation mechanism to enable
control word or not?

When decryption at the egress LER, the TTL&TC processing of the first decrypted label should be
A bit different with previous mechanism. The TTL&TC value may need to inherit from the label before
MEL in uniform mode.

Regards
Lizhong

> -----Original Message-----
> From: Loa Andersson [mailto:loa <at> pi.nu]
> Sent: 2015年5月4日 2:40
(Continue reading)

Mach Chen | 15 May 10:49 2015

MPLS-RT review on draft-farrelll-mpls-opportunistic-encrypt-04.txt

Hi All,

I reviewed draft-farrelll-mpls-opportunistic-encrypt-04.txt as the member of MPLS Review Team and
have the following comments:

is the document coherent?

Yes. 

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

Yes. 

is the document technically sound? 
Yes.

is the document ready to be considered for WG adoption?
Yes. 

BTW, after reading the document, I have the following comments:

1.
Section 1.1
"...Consideration of the impact of MPLS OS
   on MPLS Operations, Administration, and Management (OAM) and other
   MPLS management techniques also needs further exploration."

OAM is a critical tool for MPLS network, some OAM functions (e.g., LSP Ping, traceroute) that depend on
special label (Router Alter label, GAL) and TTL may not work due to the encryption. Especially the
hop-by-hop encrypted scenario. 
(Continue reading)

Ronald Bonica | 14 May 21:59 2015
Picon

SDN/MPLS 2015 CFP Announcement

Call for Presentation Abstract Proposals Now up at http://www.isocore.com/2015/cfp.htm

Submissions Deadline: May 18

Isocore's 2015 International Conference, the 18th Annual event on new networking technologies will be
held November 15-18, 2015, in Washington, DC. This year, the overarching themes of the conference will be
on Softwarization (Integration of SDN and NFV), Programmatic Control, Security and Operational
Experience of the Network and Services in Cloud, Data Centers and DevOps environments.

The conference Program Committee is soliciting presentation proposals seeking original and
unpublished work to continue the tradition initiated by this conference in 1998 of covering
cutting-edge topics. Presentations addressing new technologies and operational experience are
solicited from network equipment vendors, service providers, the research community, government
agencies, and enterprise users. In particular, submission in at least the following topics areas are of interest

* Cybersecurity, Security of the Cloud and Data Governance
* Softwarization (Integration of SDN and NFV) of the Network and Services
* Service Function Chaining
* Mobile and Wireless Packet Infrastructure

Please submit your abstracts to cfp2015 <at> isocore.com

Regards,
Ron Bonica

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

(Continue reading)

rfc-editor | 14 May 00:54 2015

RFC 7524 on Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)

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

        
        RFC 7524

        Title:      Inter-Area Point-to-Multipoint (P2MP) Segmented
                    Label Switched Paths (LSPs) 
        Author:     Y. Rekhter, E. Rosen, R. Aggarwal, T. Morin,
                    I. Grosclaude, N. Leymann, S. Saad
        Status:     Standards Track
        Stream:     IETF
        Date:       May 2015
        Mailbox:    yakov <at> juniper.net, 
                    erosen <at> juniper.net, 
                    raggarwa_1 <at> yahoo.com,
                    thomas.morin <at> orange.com, 
                    irene.grosclaude <at> orange.com,
                    n.leymann <at> telekom.de, 
                    samirsaad1 <at> outlook.com
        Pages:      42
        Characters: 105804
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-mpls-seamless-mcast-17.txt

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

        DOI:        http://dx.doi.org/10.17487/RFC7524

This document describes procedures for building inter-area
(Continue reading)

RFC Errata System | 12 May 16:14 2015

[Technical Errata Reported] RFC5586 (4364)

The following errata report has been submitted for RFC5586,
"MPLS Generic Associated Channel".

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

--------------------------------------
Type: Technical
Reported by: Alexander ("Sasha") Vainshtein <Alexander.Vainshtein <at> ecitele.com>

Section: 4.2.1

Original Text
-------------
   The Time-To-Live (TTL) field of the LSE that contains the GAL follows
   the definition and processing rules specified in [RFC3443].

Corrected Text
--------------
The value of the  Time-To-Live (TTL) field of the LSE that contains the 
GAL follows is irrelevant as long as it exceeds 1. (Setting this value 
to 0 or 1 SHOULD be avoided because it could result in trapping the OAM 
packets in with wrong reason: "TTL expiration" instead of "GAL  
encountered").  

Notes
-----
The processing rules specific in RFC 3443 deal with handling TTL in the LSE of a labeled packets that are
forwarded based on this LSE, or with setting the TTL value by a LER pushing a label stack on an unlabeled packet.
(Continue reading)

Loa Andersson | 12 May 14:21 2015

Re: New Version Notification for draft-hao-mpls-ip-hard-pipe-02.txt

Working Group.

draft-hao-mpls-ip-hard-pipe is a document intended to be published
as and Independent RFC. We have just posted version -02, after the
review initiated by the ISE.

The reviewers were Huub and Mustapha. We have included responses
to their comments (see text file). We have also fixed grammar and
a number of typos.

/Loa

On 2015-05-12 13:58, internet-drafts <at> ietf.org wrote:
>
> A new version of I-D, draft-hao-mpls-ip-hard-pipe-02.txt
> has been successfully submitted by Loa Andersson and posted to the
> IETF repository.
>
> Name:		draft-hao-mpls-ip-hard-pipe
> Revision:	02
> Title:		Architecture of MPLS/IP Network with Hardened Pipes
> Document date:	2015-05-12
> Group:		Individual Submission
> Pages:		16
> URL:            https://www.ietf.org/internet-drafts/draft-hao-mpls-ip-hard-pipe-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-hao-mpls-ip-hard-pipe/
> Htmlized:       https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hao-mpls-ip-hard-pipe-02
>
> Abstract:
(Continue reading)


Gmane