Loa Andersson | 5 Mar 08:30 2015
Picon

New working group document.

Working Group,

Around the IETF meeting in Honolulu we did an adoption poll on
draft-kini-mpls-spring-entropy-label. There were very strong support to
adopt the document.

At the same time we have a comment from the MPLS-RT review that had not
been addressed. This comment was of such a nature that we found it
necessary to address before making it a wg document.

The WG chairs closed the adoption poll, but also decided that once we
see the update and have the acknowledgement from the MPLS-RT reviewer
we would send out the mail on adoption.

We now have both, could the authors therefore re-post the draft as
draft-ietf-mpls-spring-entropy-label-00, without any other changes than
date, file name and version number.

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

Spencer Dawkins | 5 Mar 02:19 2015
Picon

Spencer Dawkins' No Objection on draft-ietf-mpls-lsp-ping-registry-02: (with COMMENT)

Spencer Dawkins has entered the following ballot position for
draft-ietf-mpls-lsp-ping-registry-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registry/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Pete's comments make perfect sense to me.

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

IETF Secretariat | 4 Mar 22:05 2015
Picon

ID Tracker State Update Notice: <draft-ietf-mpls-oam-ipv6-rao-03.txt>

IANA action state changed to RFC-Ed-Ack
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/

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

The IESG | 4 Mar 15:02 2015
Picon

Protocol Action: 'Updates to LDP for IPv6' to Proposed Standard (draft-ietf-mpls-ldp-ipv6-17.txt)

The IESG has approved the following document:
- 'Updates to LDP for IPv6'
  (draft-ietf-mpls-ldp-ipv6-17.txt) as Proposed Standard

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

The IESG contact persons are Alia Atlas and Adrian Farrel.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/

Technical Summary

     The LDP [RFC5036] specification defines procedures and messages for
     exchanging FEC-label bindings over either IPv4 or IPv6 or networks deploying
     both  types of technologies (e.g. dual-stack networks).

     Although LDP is defined in RFC5036 so that it may be used over IPv4 
     and/or IPv6, RFC 5036 really does not really allow for interoperable
     implementations of LDP over IPv6. In this respect RFC 5036 is too
     under-specified to be implemented over IPv6.

     Consequently, this document list 7 deficiencies in RFC5036 (see the Introduction)
     that needs to be addressed to allow interoperable LDP implementations in 
     IPv6 networks
.
     The document and also specifies how these deficiencies should be addressed
     in regards to IPv6 usage. In general there can be said that RFC 5036 lack
     in detail, rules and procedures for using LDP in IPv6 enabled  networks 
(Continue reading)

曾峻波 | 4 Mar 09:25 2015
Picon

Mail regarding draft-cheng-mpls-tp-shared-ring-protection

<!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 12pt; font-family:微软雅黑 } -->
Hi authors
        We are developing the solution in our system.
One question about the ring tunnel. For one destination node, the solution needs setup 4 different ring tunnels, 2 for working and 2 for protection. My suggestion is two tunnels are enough, one for clockwise working and protection, and the other for anti-clockwise working and protection?


Best Regards!
Bobo

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
internet-drafts | 4 Mar 08:20 2015
Picon

I-D Action: draft-kini-mpls-spring-entropy-label-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           : Entropy labels for source routed stacked tunnels
        Authors         : Sriganesh Kini
                          Kireeti Kompella
                          Siva Sivabalan
                          Stephane Litkowski
                          Rob Shakir
                          Xiaohu Xu
                          Wim Hendrickx
                          Jeff Tantsura
	Filename        : draft-kini-mpls-spring-entropy-label-03.txt
	Pages           : 11
	Date            : 2015-03-03

Abstract:
   Source routed tunnel stacking is a technique that can be leveraged to
   provide a method to steer a packet through a controlled set of
   segments.  This can be applied to the Multi Protocol Label Switching
   (MPLS) data plane.  Entropy label (EL) is a technique used in MPLS to
   improve load balancing.  This document examines and describes how ELs
   are to be applied to source routed stacked tunnels.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kini-mpls-spring-entropy-label/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-kini-mpls-spring-entropy-label-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-kini-mpls-spring-entropy-label-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

Pete Resnick | 4 Mar 06:58 2015

Pete Resnick's No Objection on draft-ietf-mpls-lsp-ping-registry-02: (with COMMENT)

Pete Resnick has entered the following ballot position for
draft-ietf-mpls-lsp-ping-registry-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registry/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It's not at all clear to me why this document is going for Standards
Track or why it updates 4379 and 6424, nor does the ballot nor shepherd
writeup explain. It's creating a registry, which doesn't change the
protocol in either of those documents. Seems to me fine that it be
Informational, and that it doesn't update anything.

2.2, 2.3, 2.4:

OLD
   The registration policies [RFC5226] for this registry are:

      0-250    Standards Action
    251-254    Experimental
        255    Standards Action
NEW
   The registration policies [RFC5226] for this registry is Standards
   Action.

The registration policy for the entire registry is "Standards Action".
Within the registry itself, the values 251-254 should be marked
Experimental (which they are) and 255 should be marked Reserved (which it
is), but that doesn't change the registration policy.

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

Xuxiaohu | 4 Mar 05:10 2015

Re: New Version Notification for draft-xu-sfc-using-mpls-spring-02.txt

The rationales for leveraging the MPLS-SPRING mechanism to realize the service path layer functionality
of the service function chaining are as follows:

1) eliminate the SFC/SFP states on SFFs. This follows the same logic as MPLS-SPRING and BIER.
2) utilize the existing encapsulation (e.g., the MPLS-SPRING) to a maximum extent. This follows the
Transport Derived SFF concept as described in Section 4.3.1 of draft-ietf-sfc-architecture.
Meanwhile, this is aligned with the current SFC charter, e.g., "...The working group will consider using
an existing encapsulation (with extensions as appropriate) if a suitable candidate is found..."
3) seamlessly support the SFC in a multi-tenant environment (e.g., MPLS VPN). For example, the MPLS VPN
packet (containing metadata) could be further imposed with a label stack which indicates an SFC or SFP
associated with that packet. SFFs receiving the above packet would strip the whole label stack and then
send the payload of the MPLS packet (with metadata) to the corresponding SFs which are tenant-aware and
therefore easily could determine the tenant profile according to the tenant info contained in the
metadata (a.k.a., the NSH). 

Best regards,
Xiaohu

> -----Original Message-----
> From: Xuxiaohu
> Sent: Wednesday, March 04, 2015 11:31 AM
> To: sfc <at> ietf.org; '<spring <at> ietf.org>'; mpls <at> ietf.org
> Subject: FW: New Version Notification for draft-xu-sfc-using-mpls-spring-02.txt
> 
> Hi all,
> 
> This document describes how to leverage the MPLS-based source routing (i.e.,
> MPLS-SPRING) mechanism as developed by the SPRING WG to realize the
> service path layer functionality of the service function chaining. In addition, this
> document also describes how to carry metadata in an MPLS packet by using the
> NSH as a metadata container.
> 
> Any comments are suggestions are welcome.
> 
> Best regards,
> Xiaohu
> 
> > -----Original Message-----
> > From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> > Sent: Wednesday, March 04, 2015 11:24 AM
> > To: Lizhenbin; Luis M. Contreras; Xuxiaohu; Himanshu C. Shah;
> > Xuxiaohu; Himanshu Shah; Luis M. Contreras; Lizhenbin
> > Subject: New Version Notification for
> > draft-xu-sfc-using-mpls-spring-02.txt
> >
> >
> > A new version of I-D, draft-xu-sfc-using-mpls-spring-02.txt
> > has been successfully submitted by Xiaohu Xu and posted to the IETF
> repository.
> >
> > Name:		draft-xu-sfc-using-mpls-spring
> > Revision:	02
> > Title:		Service Function Chaining Using MPLS-SPRING
> > Document date:	2015-03-03
> > Group:		Individual Submission
> > Pages:		8
> > URL:
> > http://www.ietf.org/internet-drafts/draft-xu-sfc-using-mpls-spring-02.
> > txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-xu-sfc-using-mpls-spring/
> > Htmlized:       http://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-02
> > Diff:
> > http://www.ietf.org/rfcdiff?url2=draft-xu-sfc-using-mpls-spring-02
> >
> > Abstract:
> >    Source Packet Routing in Networking (SPRING) WG specifies a special
> >    source routing mechanism.  Such source routing mechanism can be
> >    leveraged to realize the service path layer functionality of the
> >    service function chaining (i.e, steering traffic through a particular
> >    service function path) by encoding the service function path or the
> >    service function chain information as the explicit path information.
> >    This document describes how to leverage the MPLS-based source routing
> >    mechanism as developed by the SPRING WG to realize the service path
> >    layer functionality of the service function chaining.
> >
> >
> >
> >
> > 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.
> >
> > The IETF Secretariat

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

Xuxiaohu | 4 Mar 04:30 2015

FW: New Version Notification for draft-xu-sfc-using-mpls-spring-02.txt

Hi all,

This document describes how to leverage the MPLS-based source routing (i.e., MPLS-SPRING) mechanism as
developed by the SPRING WG to realize the service path layer functionality of the service function
chaining. In addition, this document also describes how to carry metadata in an MPLS packet by using the
NSH as a metadata container. 

Any comments are suggestions are welcome.

Best regards,
Xiaohu

> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Wednesday, March 04, 2015 11:24 AM
> To: Lizhenbin; Luis M. Contreras; Xuxiaohu; Himanshu C. Shah; Xuxiaohu;
> Himanshu Shah; Luis M. Contreras; Lizhenbin
> Subject: New Version Notification for draft-xu-sfc-using-mpls-spring-02.txt
> 
> 
> A new version of I-D, draft-xu-sfc-using-mpls-spring-02.txt
> has been successfully submitted by Xiaohu Xu and posted to the IETF repository.
> 
> Name:		draft-xu-sfc-using-mpls-spring
> Revision:	02
> Title:		Service Function Chaining Using MPLS-SPRING
> Document date:	2015-03-03
> Group:		Individual Submission
> Pages:		8
> URL:
> http://www.ietf.org/internet-drafts/draft-xu-sfc-using-mpls-spring-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-xu-sfc-using-mpls-spring/
> Htmlized:       http://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-02
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-xu-sfc-using-mpls-spring-02
> 
> Abstract:
>    Source Packet Routing in Networking (SPRING) WG specifies a special
>    source routing mechanism.  Such source routing mechanism can be
>    leveraged to realize the service path layer functionality of the
>    service function chaining (i.e, steering traffic through a particular
>    service function path) by encoding the service function path or the
>    service function chain information as the explicit path information.
>    This document describes how to leverage the MPLS-based source routing
>    mechanism as developed by the SPRING WG to realize the service path
>    layer functionality of the service function chaining.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat

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

IETF Secretariat | 4 Mar 04:05 2015
Picon

ID Tracker State Update Notice: <draft-ietf-mpls-oam-ipv6-rao-03.txt>

IANA action state changed to Waiting on RFC Editor
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/

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

IETF Secretariat | 4 Mar 04:05 2015
Picon

ID Tracker State Update Notice: <draft-ietf-mpls-oam-ipv6-rao-03.txt>

IANA action state changed to In Progress
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/

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


Gmane