Loa Andersson | 28 Jul 12:16 2014
Picon

working group last call on draft-ietf-mpls-mldp-in-band-wildcard-encoding

Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-mldp-in-band-wildcard-encoding.

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

There are no 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 IPRs that relates to this draft.

This working group last call ends August 8, 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

internet-drafts | 27 Jul 21:42 2014
Picon

I-D Action: draft-akiya-mpls-lsp-ping-reply-mode-simple-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/Traceroute Reply Mode Simplification
        Authors         : Nobo Akiya
                          George Swallow
                          Carlos Pignataro
                          Loa Andersson
                          Mach(Guoyi) Chen
	Filename        : draft-akiya-mpls-lsp-ping-reply-mode-simple-03.txt
	Pages           : 11
	Date            : 2014-07-27

Abstract:
   The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
   Ping and Traceroute use the Reply Mode field to signal the method to
   be used in the MPLS echo reply.  This document adds one value to the
   Reply Mode field to indicate reverse LSP.  This document also adds an
   optional TLV which can carry ordered list of Reply Mode values.

   This document updates RFC4379.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-reply-mode-simple-03

A diff from the previous version is available at:
(Continue reading)

Nobo Akiya (nobo | 27 Jul 21:05 2014
Picon

Comments on draft-li-mpls-global-label-usecases

Hi Authors,

The presentation for this document at IETF90 added some use cases.

http://www.ietf.org/proceedings/90/slides/slides-90-mpls-13.pptx, Slide 2.

Below are my comments on just the new use cases added.

1. MPLS OAM for LDP LSP

The problem isn't specific to LDP, but SR as well as TE/TP with PHP. However, what you need is a label that
ingress and egress agree on, which granularity is likely at least one label per LSP. Attempting to solve
this through suggested "global label" will unnecessary burn up labels in the "global label space" (i.e.
severe scalability problem). In other words, LSP egress allocated context label appears to be simpler
and technical superior, IMHO.

2. Service Chaining
	
Why not let SFC folks to do their work, which SFC will then work on the MPLS data plane without any changes to
the MPLS data plane nor architecture, certainly doesn't require any "global label" as this use case is
describing. Unless the SFC WG require the "global label" (which it doesn't) or the MPLS WG is re-chartered
to pick up creation of a tangent SFC solution specifically for MPLS, I don't think this use case is valid.

3. Segment Routing

The Segment Routing technology is much further down the road (i.e. we even saw some cool stuff in the
Bits-n-Bites at IETF90) and they already have a solution for SRGB. Even if Segment Routing was using
global labels (which isn't the case), I'm not sure if there's any value in listing this as a use case for
"global label".

(Continue reading)

Loa Andersson | 26 Jul 22:48 2014
Picon

IPR poll on draft-tsaad-mpls-p2mp-loose-path-reopt

Working Group,

The authors of draft-tsaad-mpls-p2mp-loose-path-reopt have told
us that the draft is ready to be accepted as a working group document.

Before we do poll to see if we have consensus to accept the document
as a working group document we want to do an IPR poll on the document.

This mail starts that IPR poll.

Are you aware of any IPR that applies to draft-tsaad-mpls-p2mp-loose-
path-reopt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

Currently there are one IPR disclosures that relates to this document.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The 
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any
IPR that has not yet been disclosed in conformance with IETF rules.

Thanks, Loa
(as MPLS WG co-chair)
(Continue reading)

Tarek Saad (tsaad | 26 Jul 21:56 2014
Picon

Re: New Version Notification for draft-tsaad-mpls-p2mp-loose-path-reopt-03.txt

Working Group,

We¹ve uploaded version -03 of the draft (accessible below). The authors
are soliciting any comments that can be sent the mailer list.

Regards,
Tarek

On 2014-07-21, 11:02 AM, "internet-drafts <at> ietf.org"
<internet-drafts <at> ietf.org> wrote:

>
>A new version of I-D, draft-tsaad-mpls-p2mp-loose-path-reopt-03.txt
>has been successfully submitted by Tarek Saad and posted to the
>IETF repository.
>
>Name:		draft-tsaad-mpls-p2mp-loose-path-reopt
>Revision:	03
>Title:		Reoptimization of Point-to-Multipoint Traffic Engineering Loosely
>Routed LSPs
>Document date:	2014-07-21
>Group:		mpls
>Pages:		11
>URL:            
>http://www.ietf.org/internet-drafts/draft-tsaad-mpls-p2mp-loose-path-reopt
>-03.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-tsaad-mpls-p2mp-loose-path-reopt/
>Htmlized:       
>http://tools.ietf.org/html/draft-tsaad-mpls-p2mp-loose-path-reopt-03
(Continue reading)

Loa Andersson | 26 Jul 15:59 2014
Picon

Fwd: Summary of RTG Tuning as presented to IESG/IAB

Working Group,

You should have heard that the routing area is going through a
tuning process, part of that is that about half of the working
groups will effected by an re-org; for MPLS this means that the
work we have done for RSVP-TE packet and sometimes generic RSVP-TE
will be moved a new TE working group.

Below you find Adrian's summary of the re-tuning discussions to the
IAB and IESG.

There are also slides from the RTG Area meeting to be found here:

http://www.ietf.org/proceedings/90/slides/slides-90-rtgarea-4.ppt

I expect ADs to ask us to start working on the charter for the new
mols wg, possibly based on a proposal from them.

/Loa
for the mpls wg chairs

-------- Original Message --------
Subject: Summary of RTG Tuning as presented to IESG/IAB
Date: Fri, 25 Jul 2014 19:57:47 +0100
From: Adrian Farrel <adrian <at> olddog.co.uk>
Reply-To: adrian <at> olddog.co.uk
To: <routing-discussion <at> ietf.org>

Hi,

(Continue reading)

Loa Andersson | 26 Jul 14:29 2014
Picon

question on draft-cui-mpls-tp-mfp-use-case-and-requirements

Zhenlong,

draft-cui-mpls-tp-mfp-use-case-and-requirements in the mpls wg
yesterday. I had a question that was not very clear, I try to repeat it
here.

In slide 3 you say hat that:

"In the m:n architecture, the m backup paths(p1,p2)
  are sharing backup resource for n working paths, as
  shown in the following example(modeling)."

In slide 5 you say:

" The m backup paths should be sharing backup
   resource for n working paths, where n>=m."

It is not entirely clear if you say that n being a lower number is an
cost optimization or if it is part of the architecture.

 From a strictly architectural could n be lower, equal or higher than m,
i.e. you can protect m working paths with m+x protecting paths. Where
x can be any positive or negative number (as long as it give you at
least some resources for protection).

/Loa

--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
(Continue reading)

Gregory Mirsky | 25 Jul 16:26 2014
Picon

Comments to draft-mirsky-mpls-residence-time-02

Dear All,

greatly appreciate comments we received after presenting our work to TICTOC and MPLS WGs.

Below my recollection of comments with responses:

·         Shahram pointed that TTL Expiration mechanism would alter residence timing comparing with regular forwarding of an MPLS packet that may be carrying time synchronization packet.

True. If RTM used over particular LSP, then all time synchronization packets may be carried over RTM ACH and LER may ignore accumulated residence in certain cases.

·         Yaakov and George expressed concern by possible performance impact that use of TTL Expiration method by RTM may have on installed LSRs that punt packets upon TTL expiration.

If an LSR does not advertise RTM capability in IGP TE, then it would not appear on RTM Set Object and, as result, would not be considered as “next downstream RTM LSR” by RTM capable LSR that calculates distance. If nevertheless non-RTM capable LSR receives RTM ACH packet, then it will drop it as the LSR would not recognize RTM ACH value.

·         Yaakov pointed that RTM capability is per port, not per node.

Yes, and that how we plan to advertise RTM capability in IGP TE.

 

We greatly appreciate all suggestions and comments.

 

                Regards,

                                Greg

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
internet-drafts | 25 Jul 15:29 2014
Picon

I-D Action: draft-ietf-mpls-smp-requirements-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           : Requirements for MPLS-TP Shared Mesh Protection
        Authors         : Yaacov Weingarten
                          Sam Aldrin
                          Ping Pan
                          Jeong-dong Ryoo
                          Greg Mirsky
	Filename        : draft-ietf-mpls-smp-requirements-08.txt
	Pages           : 15
	Date            : 2014-07-25

Abstract:
   This document presents the basic network objectives for the behavior
   of shared mesh protection (SMP) which are not based on control plane
   support. This is an expansion of the basic requirements presented in
   RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC
   6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". This
   document provides requirements for any mechanism that would be used
   to implement SMP for MPLS-TP data paths, in networks that delegate
   protection switch coordination to the data  plane.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-smp-requirements-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-smp-requirements-08

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

Lizhenbin | 25 Jul 07:17 2014

Comments on MPLS Architectural Principles and Special semantics for double labels

Hi George,

Regarding the following concept you mentioned which is proposed over and over again,

"Special semantics for double labels
-- PoP top label; process next label; push PoP’ed label back on
   8 byte label stack entry"

 

Do you think the upstream label defined in RFC5331 and its usage for BGP-based MVPN defined in RFC6514 or the egress node's process of entropy label with ELI defined by RFC 6790 is not "Special semantics for double labels: PoP top label; process next label"?

 

 

Regards,

Robin


 

 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Lizhenbin | 25 Jul 07:09 2014

Comments on MPLS Architectural Principles and MPLS Global Labels

Hi George,

 

Regarding the global label, I have different opinion from that proposed in the slide "MPLS Architectural

Principles".
1. According to the MPLS principle proposed in the page 2 and 3, I think global label comply with all the principles

described here.1) It is still 20 bits and can be in label stack. 2) It is application-spcific. Please refer to the draft

draft-li-mpls-global-label-usecases for the possible application scenarios. 3) It can be allocated by IP-based

control protocols.
 
2. I do not think the concept of global label is proposed over and over again. I began to participate the IETF meeting

in Stockholm in 2009. Only in that meeting, I saw the global label is proposed and critisized by Yakov. Later I

experienced almost all IETF meeting. The global label idea is not proposed until we propose the global label idea in

2014. According to the frequency (one idea every 5 years), I do not think the global label is proposed over and over

again. Maybe some people proposed the ideas many times in the 4 years to you. But it just confine to private talk.

As for me, according to the publised materias, it is not "over and over again".

 

3. Morevoer, after 4 year, the idea of global label is not the old one any more.
-- Firstly we should define what is global label. According to our definition proposed in draft-li-mpls-global-

label-framework, the MPLS global label means the label which meaning can be understood by all nodes or part of

nodes in the network. It is not mandorty that the global label must be understood by ALL nodes. In our opinion,

if one label's meaning can be understood by more than the two local neighboring nodes, it can be defined as the

global label.
-- Secondly, in the past 4-5 years, many new things have been proposed and accepted in the MPLS world. They

includes upstream allocation defined in RFC5331, entropy label defined in RFC 6790, flow label defined in RFC

6391, special-purpose label defined in RFC 7274, etc. According to our definition on global label, all of them can

be seen as some types of global label because these labels can be consistently processed or understood by multiple

nodes in one network instead of the local upstream node and the downstream node.
I wonder what is the global label's definition in the slides "MPLS Architectural Principles". Do you means that

label  allocated by part of nodes in the network can not be called as global label? Or do you means the label which

is unerstood by multiple nodes but allocated from context-specific label space can not be called as the global

label?
In my own opinion, we cannot ignore the fact that the label has already multiple usage beyond the original meaning

which is only understood by the local upstream node and downstream node. It is make no sense to argue that these

label concept are different from that of global label. In my opinion, if the concept of global label is hated, in

the future, I am sure we will not miss some label concepts which just change the name of global label.

 


Regards,

Robin

 

 

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

Gmane