Hi Xiaohu, Ron, et. al,
what if metadata carried over SF ACH type?
Regards,
Greg
From: mpls [mailto:[email protected]] On Behalf Of Xuxiaohu
Sent: Thursday, October 30, 2014 7:28 PM
To: Ron Parker
Cc: [email protected]; <[email protected]>; [email protected]
Subject: Re: [mpls] [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:[email protected]]
Sent: Friday, October 31, 2014 4:45 AM
To: Xuxiaohu
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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:[email protected]]
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 <[email protected]<mailto:[email protected]>>
Date: Tuesday, October 28, 2014 at 11:30 PM
To: Jim Guichard <[email protected]<mailto:[email protected]>>, Thomas Narten
<[email protected]<mailto:[email protected]>>
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)'; [email protected]<mailto:[email protected]>
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:[email protected]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, October 06, 2014 9:27 PM
To: [email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
