Re: [sfc] About the possibility of using MPLS source routing (i.e., MPLS-SPRING) mechanism for SFC//RE: SFC Honolulu meeting agenda
2014-10-31 02:28:04 GMT
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)?
From: Ron Parker [mailto:Ron_Parker <at> affirmednetworks.com]
Sent: Friday, October 31, 2014 4:45 AM
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
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.
On Oct 30, 2014, at 3:15 AM, Xuxiaohu <xuxiaohu <at> huawei.com> wrote:
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.
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
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
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.
Sent: Wednesday, October 08, 2014 4:50 PM
To: 'Jim Guichard (jguichar)'; sfc <at> ietf.org
Subject: RE: SFC Honolulu meeting agenda
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.
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