Xuxiaohu | 31 Oct 03:28 2014

Re: [sfc] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda

Hi Ron,

 

Did you mean an SPL(Special Purpose Label) or an ESPL(Extended Special Purpose Label) by a well-known global label? If so, additional SPLs or ESPLs would need to be allocated for different MPLS payload, such as Ethernet frame and IP packet. However I wonder whether it is the normal usage of the SPL and ESPL space (i.e., used as a protocol type identifier)?

 

Best regards,

Xiaohu

 

From: Ron Parker [mailto:Ron_Parker <at> affirmednetworks.com]
Sent: Friday, October 31, 2014 4:45 AM
To: Xuxiaohu
Cc: sfc <at> ietf.org; mpls <at> ietf.org; <spring <at> ietf.org>
Subject: Re: [sfc] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda

 

Xiaohu,

 

Regarding carriage of metadata -- the MPLS would be only the transport part.  What about reserving a well known global label that means SCH/NSH header follows.  This well known label would always be at the BOS.  

 

   Ron

 


On Oct 30, 2014, at 3:15 AM, Xuxiaohu <xuxiaohu <at> huawei.com> wrote:

Hi all,

 

There are many drafts which mentioned the possibility of using the MPLS source routing (i.e., MPLS-SPRING) mechanism for service function chain purpose. However, we do need a detailed evaluation of such possibility so as to figure out whether any potential extensions to the MPLS architecture is required. For instance,

 

1) although an MPLS label stack could be used to indicate an SFP, however, when an SFF-proxy receives such a MPLS packet, it must know the payload type of the MPLS packet before sending the original packet to the corresponding legacy SF. How? In fact, even in the non-legacy SF case, should the SFF directly forward the MPLS packet to the corresponding SF directly or strip the MPLS header before sending the packet to the corresponding SF? In the former case, the corresponding SF should know the payload type of the MPLS packet. In the latter case, the SFF should know the payload type. To identify the payload type, one way is to allocate a separate local label for each payload type (is this a scalable way?), another way is to allocate an SPL or an ESPL for each payload type (is this the normal purpose of the SPL or ESPL), a third way is to introduce a SPL or ESPL which is followed by a protocol id header (is this a significant change to the MPLS architecture?).

 

2) assume an SFF needs to strip the whole MPLS header before sending the packet to the corresponding SF, does it mean a big change to the current MPLS forwarding plane?

 

3) when using an MPLS label stack to indicate an SFC rather than an SFP, each SF would have to be identified by a domain-wide label. One way is to reserve the same label range for SF SID purpose by all the SFFs. Another way is to rely on the context label concept (i.e., each SF of an SFC would have to be represented by two labels in the label stack, one is the context indication label, the other is the label allocated from that context label space for that SF ). However, it seems that the domain-wide label usage is still a controversial topic in the IETF community.

 

4) how to convey metadata in an MPLS packet? This issue may be the same as issue 1.

 

Any comments?

 

Best regards,

Xiaohu

 

 

From: Jim Guichard (jguichar) [mailto:jguichar <at> cisco.com]
Sent: Wednesday, October 29, 2014 8:15 PM
To: Xuxiaohu; Thomas Narten
Subject: Re: SFC Honolulu meeting agenda

 

Hi Xiaohu,

 

Our agenda is not yet finalized but we will only be allowing slots for drafts that have had mailing list discussion and are directly related to our immediate deliverables. For this reason we are unable to allocate time for discussion of your draft in HI.  Please feel free to continue to solicit discussion on the SFC mailing list.

 

Jim & Thomas

 

From: Xuxiaohu <xuxiaohu <at> huawei.com>
Date: Tuesday, October 28, 2014 at 11:30 PM
To: Jim Guichard <jguichar <at> cisco.com>, Thomas Narten <narten <at> us.ibm.com>
Subject: RE: SFC Honolulu meeting agenda

 

Hi co-chairs,

 

I found there are still available time on the SFC agenda. Hence I wonder whether you could allocate a 15-min slot for presenting this draft.

 

Best regards,

Xiaohu

 

From: Xuxiaohu
Sent: Wednesday, October 08, 2014 4:50 PM
To: 'Jim Guichard (jguichar)'; sfc <at> ietf.org
Subject: RE: SFC Honolulu meeting agenda

 

Hi co-chairs,

 

I would like to request a 15-min slot for presenting the following draft (https://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-00). Since “Generic SFC Encapsulation” is one of the WG charter deliverables and the charter states that “…The working group will consider using an existing encapsulation (with extensions as appropriate) if a suitable candidate is found...” I would like the WG to help evaluating whether the MPLS-SPRING-based SFC encapsulation approach as described in the above draft could be considered as one of the candidates.

 

Best regards,

Xiaohu

 

From: sfc [mailto:sfc-bounces <at> ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, October 06, 2014 9:27 PM
To: sfc <at> ietf.org
Subject: [sfc] SFC Honolulu meeting agenda

 

Greetings WG:

 

Our meeting at the upcoming Honolulu venue is fast approaching.  As always, the goal of the meeting will be to make the best use of limited face-to-face time.

 

As we build the meeting agenda we welcome requests for agenda time. As always, the goal of a meeting slot is to best further the work of the WG, and that generally means focussing on key charter deliverables and topics with important open issues to resolve. In the case of individual IDs, the goal isn’t necessarily to present what is in the draft but rather to help the WG decide what to do with the ID. With that in mind, when making an agenda request please consider what you think the WG should do with its content. For example:

  • Does the document have useful content that should be moved into another WG document or progress on it’s own merit

  • Does the content have a good basis for one of the WG documents per the charter (in order for that to happen the document needs to be the most appropriate out of the collection of related documents)

  • Should the document content be merged with one or more other documents, so that a combined document could become a WG document

Jim & Thomas

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

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Ross Callon | 31 Oct 01:17 2014
Picon

New MPLS WG Document, draft-decraene-mpls-lsp-ping-registry

Working group;
 
After WG chair review by George and myself, we have decided to accept draft-decraene-mpls-lsp-ping-registry as an MPLS WG document. This is a very simple draft which creates registries which are needed for other documents, but otherwise makes no technical change. As soon as the internet draft posting widow reopens would the authors please repost this draft as:
 
    draft-ietf-mpls-lsp-ping-registry-00
 
with no changes other than the draft name, date, and only if necessary updated references.
 
Because this is a very simple draft, and because there are other drafts dependent upon this document, we intend to progress this document quickly and would like to encourage WG participants to review it and comment on the WG list.
 
Thanks, Ross
(as MPLS WG chair)
 
PS: While it seems unlikely for there to be IPR on a draft which only creates registries, nonetheless we intend to do the normal IPR poll prior to WG last call. As always, WG participants are required to be aware of IETF IPR policy, and to disclose any IPR that they are aware of that applies to IETF contributions (including but not limited to Internet Drafts) as soon as they know of such IPR, without waiting for an IPR poll.
 
 
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Shamjhana | 30 Oct 16:30 2014

Cloud & Data Center, WAN and Virtualization/NFV - SDN/MPLS 2014

The SDN/MPLS 2014 Conference in Washington DC starts this Sunday, November 2. There are a limited number of seats still available.

Come and  learn about the future of networking.  Register now at: http://www.isocore.com/sdn-mpls/attendees.php

 

The SDN/MPLS 2014 Conference program is available at: http://www.isocore.com/sdn-mpls/
Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm 
Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_sessions.htm

 

The hotel rooms are sold out!

 

Thank you!

 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Martin Vigoureux | 30 Oct 11:47 2014

IETF91 - MPLS - Agenda available - Please send your presentation material

All,

the agenda is on-line:
http://www.ietf.org/proceedings/91/agenda/agenda-91-mpls

Please have a look at it.

Speakers, please start sending me your presentation material, and please 
do so before Sunday 9th at noon, local time.

Thank you

Martin

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

Xuxiaohu | 30 Oct 11:15 2014

About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda

Hi all,

 

There are many drafts which mentioned the possibility of using the MPLS source routing (i.e., MPLS-SPRING) mechanism for service function chain purpose. However, we do need a detailed evaluation of such possibility so as to figure out whether any potential extensions to the MPLS architecture is required. For instance,

 

1) although an MPLS label stack could be used to indicate an SFP, however, when an SFF-proxy receives such a MPLS packet, it must know the payload type of the MPLS packet before sending the original packet to the corresponding legacy SF. How? In fact, even in the non-legacy SF case, should the SFF directly forward the MPLS packet to the corresponding SF directly or strip the MPLS header before sending the packet to the corresponding SF? In the former case, the corresponding SF should know the payload type of the MPLS packet. In the latter case, the SFF should know the payload type. To identify the payload type, one way is to allocate a separate local label for each payload type (is this a scalable way?), another way is to allocate an SPL or an ESPL for each payload type (is this the normal purpose of the SPL or ESPL), a third way is to introduce a SPL or ESPL which is followed by a protocol id header (is this a significant change to the MPLS architecture?).

 

2) assume an SFF needs to strip the whole MPLS header before sending the packet to the corresponding SF, does it mean a big change to the current MPLS forwarding plane?

 

3) when using an MPLS label stack to indicate an SFC rather than an SFP, each SF would have to be identified by a domain-wide label. One way is to reserve the same label range for SF SID purpose by all the SFFs. Another way is to rely on the context label concept (i.e., each SF of an SFC would have to be represented by two labels in the label stack, one is the context indication label, the other is the label allocated from that context label space for that SF ). However, it seems that the domain-wide label usage is still a controversial topic in the IETF community.

 

4) how to convey metadata in an MPLS packet? This issue may be the same as issue 1.

 

Any comments?

 

Best regards,

Xiaohu

 

 

From: Jim Guichard (jguichar) [mailto:jguichar <at> cisco.com]
Sent: Wednesday, October 29, 2014 8:15 PM
To: Xuxiaohu; Thomas Narten
Subject: Re: SFC Honolulu meeting agenda

 

Hi Xiaohu,

 

Our agenda is not yet finalized but we will only be allowing slots for drafts that have had mailing list discussion and are directly related to our immediate deliverables. For this reason we are unable to allocate time for discussion of your draft in HI.  Please feel free to continue to solicit discussion on the SFC mailing list.

 

Jim & Thomas

 

From: Xuxiaohu <xuxiaohu <at> huawei.com>
Date: Tuesday, October 28, 2014 at 11:30 PM
To: Jim Guichard <jguichar <at> cisco.com>, Thomas Narten <narten <at> us.ibm.com>
Subject: RE: SFC Honolulu meeting agenda

 

Hi co-chairs,

 

I found there are still available time on the SFC agenda. Hence I wonder whether you could allocate a 15-min slot for presenting this draft.

 

Best regards,

Xiaohu

 

From: Xuxiaohu
Sent: Wednesday, October 08, 2014 4:50 PM
To: 'Jim Guichard (jguichar)'; sfc <at> ietf.org
Subject: RE: SFC Honolulu meeting agenda

 

Hi co-chairs,

 

I would like to request a 15-min slot for presenting the following draft (https://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-00). Since “Generic SFC Encapsulation” is one of the WG charter deliverables and the charter states that “…The working group will consider using an existing encapsulation (with extensions as appropriate) if a suitable candidate is found...” I would like the WG to help evaluating whether the MPLS-SPRING-based SFC encapsulation approach as described in the above draft could be considered as one of the candidates.

 

Best regards,

Xiaohu

 

From: sfc [mailto:sfc-bounces <at> ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, October 06, 2014 9:27 PM
To: sfc <at> ietf.org
Subject: [sfc] SFC Honolulu meeting agenda

 

Greetings WG:

 

Our meeting at the upcoming Honolulu venue is fast approaching.  As always, the goal of the meeting will be to make the best use of limited face-to-face time.

 

As we build the meeting agenda we welcome requests for agenda time. As always, the goal of a meeting slot is to best further the work of the WG, and that generally means focussing on key charter deliverables and topics with important open issues to resolve. In the case of individual IDs, the goal isn’t necessarily to present what is in the draft but rather to help the WG decide what to do with the ID. With that in mind, when making an agenda request please consider what you think the WG should do with its content. For example:

  • Does the document have useful content that should be moved into another WG document or progress on it’s own merit

  • Does the content have a good basis for one of the WG documents per the charter (in order for that to happen the document needs to be the most appropriate out of the collection of related documents)

  • Should the document content be merged with one or more other documents, so that a combined document could become a WG document

Jim & Thomas

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Kireeti Kompella | 29 Oct 18:40 2014
Picon

Fwd: New Version Notification for draft-kompella-mpls-rmr-00.txt

Hi Folks,

This is a draft on making MPLS more efficient in ring networks.  I have come around to understanding that:
a) rings are a special topology (there was a time that I didn't appreciate that);
b) MPLS is pretty inefficient in rings (that is/was quite obvious).

This draft attempts to fix that, both by making protection much more efficient, and by making configuration much easier.

Your comments are highly welcome!

Cheers,
Kireeti.

---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: Sun, Oct 26, 2014 at 9:15 PM
Subject: New Version Notification for draft-kompella-mpls-rmr-00.txt
To: Kireeti Kompella <kireeti.kompella <at> gmail.com>



A new version of I-D, draft-kompella-mpls-rmr-00.txt
has been successfully submitted by Kireeti Kompella and posted to the
IETF repository.

Name:           draft-kompella-mpls-rmr
Revision:       00
Title:          Resilient MPLS Rings
Document date:  2014-10-26
Group:          Individual Submission
Pages:          7
URL:            http://www.ietf.org/internet-drafts/draft-kompella-mpls-rmr-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kompella-mpls-rmr/
Htmlized:       http://tools.ietf.org/html/draft-kompella-mpls-rmr-00


Abstract:
   This document describes the use of the MPLS control and data planes
   on ring topologies.  It describes the special nature of rings, and
   proceeds to show how MPLS can be effectively used in such topologies.
   It describes how MPLS rings are configured, auto-discovered and
   signaled, as well as how the data plane works.  Companion documents
   describe the details of discovery and signaling for specific
   protocols.





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




--
Kireeti
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Kireeti Kompella | 29 Oct 18:36 2014
Picon

Fwd: New Version Notification for draft-kompella-mpls-larp-02.txt

Hi All,

Not sure why this didn't get copied to the MPLS WG list.

In any case, this update breaks out the "Hardware Address" into two parts.  The HA part contains just the MAC address of L-ARP replier.  Labels are in a separate TLV that now can contain a label stack.  Finally, the metric is taken out of the HA part and is separate.

We also have a new co-author, George Swallow.

Please comment on the draft as a whole, and on these changes in particular.

Thanks,
Kireeti.

---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: Mon, Oct 27, 2014 at 4:12 PM
Subject: New Version Notification for draft-kompella-mpls-larp-02.txt
To: Kireeti Kompella <kireeti.kompella <at> gmail.com>, George Swallow <swallow <at> cisco.com>, Balaji Rajagopalan <balajir <at> juniper.net>



A new version of I-D, draft-kompella-mpls-larp-02.txt
has been successfully submitted by Kireeti Kompella and posted to the
IETF repository.

Name:           draft-kompella-mpls-larp
Revision:       02
Title:          Label Distribution Using ARP
Document date:  2014-10-27
Group:          Individual Submission
Pages:          11
URL:            http://www.ietf.org/internet-drafts/draft-kompella-mpls-larp-02.txt
Status:         https://datatracker.ietf.org/doc/draft-kompella-mpls-larp/
Htmlized:       http://tools.ietf.org/html/draft-kompella-mpls-larp-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-kompella-mpls-larp-02

Abstract:
   This document describes extensions to the Address Resolution Protocol
   to distribute MPLS labels for IPv4 and IPv6 host addresses.
   Distribution of labels via ARP enables simple plug-and-play operation
   of MPLS, which is a key goal of the MPLS Fabric architecture.





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




--
Kireeti
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Internet-Drafts | 28 Oct 22:44 2014
Picon

I-D ACTION:draft-ietf-mpls-ipv6-only-gap-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         : Gap Analysis for Operating IPv6-only MPLS Networks
    Author(s)     : W. George, et al
    Filename      : draft-ietf-mpls-ipv6-only-gap
    Pages         : 26 
    Date          : 2014-10-28 

   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&#39;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.

A URL for this Internet-Draft is:
https://www.ietf.org/internet-drafts/draft-ietf-mpls-ipv6-only-gap-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-mpls-ipv6-only-gap): message/external-body, 70 bytes
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
internet-drafts | 27 Oct 23:34 2014
Picon

New Version Notification - draft-ravisingh-mpls-el-for-seamless-mpls-04.txt


A new version (-04) has been submitted for draft-ravisingh-mpls-el-for-seamless-mpls:
http://www.ietf.org/internet-drafts/draft-ravisingh-mpls-el-for-seamless-mpls-04.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ravisingh-mpls-el-for-seamless-mpls/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ravisingh-mpls-el-for-seamless-mpls-04

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.

IETF Secretariat.

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

internet-drafts | 27 Oct 23:34 2014
Picon

I-D Action: draft-ravisingh-mpls-el-for-seamless-mpls-04.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 label for seamless MPLS
        Authors         : Ravi Singh
                          Yimin Shen
                          John Drake
	Filename        : draft-ravisingh-mpls-el-for-seamless-mpls-04.txt
	Pages           : 24
	Date            : 2014-10-27

Abstract:
   This document describes certain optimizations to how entropy labels
   can be used for load balancing in a seamless MPLS architecture, as
   enabled by LSP concatenation and LSP hierarchies.

   The definition of the control plane and data plane behavior at LSP
   concatenation points; and at the ingress of an LSP in a hierarchy of
   LSPs, as described in this document, brings the benefits of entropy
   labels to certain deployment scenarios that may not have had such
   benefits as specified in [EL-RFC].

   This document, if approved, updates RFC 6790.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ravisingh-mpls-el-for-seamless-mpls/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ravisingh-mpls-el-for-seamless-mpls-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ravisingh-mpls-el-for-seamless-mpls-04

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

internet-drafts | 27 Oct 23:25 2014
Picon

New Version Notification - draft-ravisingh-mpls-el-for-seamless-mpls-03.txt


A new version (-03) has been submitted for draft-ravisingh-mpls-el-for-seamless-mpls:
http://www.ietf.org/internet-drafts/draft-ravisingh-mpls-el-for-seamless-mpls-03.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ravisingh-mpls-el-for-seamless-mpls/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ravisingh-mpls-el-for-seamless-mpls-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.

IETF Secretariat.

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


Gmane