Subject: [mpls] How to indicate the presence of NSH in an MPLS packet?

From: Xuxiaohu <[email-masked]>
Date: Fri, 23 Jan 2015 02:17:20 +0000

Hi all,

It said in (https://tools.ietf.org/html/draft-quinn-sfc-nsh-04):

   The service header is independent of the encapsulation used and is
   encapsulated in existing transports.  The presence of NSH is
   indicated via protocol type or other indicator in the outer
   encapsulation.

In the case where the outer encapsulation is an MPLS LSP, how to indicate the presence of NSH since the MPLS encapsulation has no explicit protocol identifier field to indicate the protocol type of the MPLS payload? Should we make each SFF to allocate a unique label for indicating the presence of NSH? Or should we use the control word to indicate it? Or should we reconsider the possibility of adding an explicit protocol identifier field to the MPLS encapsulation so as to solve such kind of issues once and for all?

Best regards,
Xiaohu

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 23 Jan 2015 11:28:10 +0100

Xuxiaohu 您好！

Please correct me if I am wrong:

It has always been my understanding that the MPLS header/label
was independent of the protocol/payload.
So no indication of the actual payload content was necessary.

IMHO you could use the alert label 1 to indicate to the LSR
that it has to further examine the content of a packet.

Regards, Huub.

========

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 26 Jan 2015 03:05:06 +0000

Hi Huub,

The alter label itself couldn’t make the receiving LSR to determine the MPLS payload type by examining the MPLS payload.

Best regards,
Xiaohu

> -----Original Message-----
> From: Huub van Helvoort [mailto:[email-masked]]
> Sent: Friday, January 23, 2015 6:28 PM
> To: Xuxiaohu; [email-masked]; [email-masked]
> Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet?
> 
> Xuxiaohu 您好！
> 
> It has always been my understanding that the MPLS header/label was
> independent of the protocol/payload.
> IMHO you could use the alert label 1 to indicate to the LSR that it has to further
> examine the content of a packet.
> 
> Regards, Huub.
> 
> ========
> 
> > In the case where the outer encapsulation is an MPLS LSP, how to indicate the
> presence of NSH since the MPLS encapsulation has no explicit protocol identifier
> field to indicate the protocol type of the MPLS payload? Should we make each
> SFF to allocate a unique label for indicating the presence of NSH? Or should we
> use the control word to indicate it? Or should we reconsider the possibility of
> adding an explicit protocol identifier field to the MPLS encapsulation so as to
> solve such kind of issues once and for all?
> >
> > Best regards,
> > Xiaohu
> >
> 
> 
> --

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 26 Jan 2015 06:21:32 +0000

Xiaohu, Huub,
I do not follow the SFC work closely, so I would like to understand whether the NSH should be captured by  transit LSRs on the LSP - or just by the LER acting as the LSP tail-end?

If the latter is correct, the simplest way to indicate presence of the NSH in the MPLS payload would be by allocating an "application label" indicating its presence by the tail-end LER and by inserting it at the bottom of the label stack by the head-end LER - similar to what is done for L2/L3VPN.  Within this approach, if label-based demultiplexing of  packets with NSH in the MPLS payload is not required, you could request allocation of a new special purpose label from the extended special purposes label space as per RFC 7274, and to insert such a label (preceded by the Extension Label ) at the BoS.

If the former is correct, the process above still has to be used but it has to be augmented by adding the Router Alert Label   at the top of the label stack.

From my POV these suggestions are in line with the provisions of Section 2.2 of RFC 3032 "Determining the Network Layer Protocol" that states:

<quote>
   When the last label is popped from a packet's label stack (resulting
   in the stack being emptied), further processing of the packet is
   based on the packet's network layer header.  The LSR which pops the
   last label off the stack must therefore be able to identify the
   packet's network layer protocol.  However, the label stack does not
   contain any field which explicitly identifies the network layer
   protocol.  This means that the identity of the network layer protocol
   must be inferable from the value of the label which is popped from
   the bottom of the stack, possibly along with the contents of the
   network layer header itself.
<end quote>

My 2c,
Sasha
________________________________________
From: mpls <[email-masked]> on behalf of Xuxiaohu <[email-masked]>
Sent: Monday, January 26, 2015 5:05 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] How to indicate the presence of NSH in an MPLS packet?

Hi Huub,

Best regards,
Xiaohu

> solve such kind of issues once and for all?
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Tue, 27 Jan 2015 14:27:44 +0800

Sasha,

> If the latter is correct, the simplest way to indicate presence of the NSH in the MPLS payload would be by allocating an "application label" indicating its presence by the tail-end LER and by inser…
I think "the latter" is correct, the only issue I see is adding one
more label stack entry to the label stack.

/Loa
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 27 Jan 2015 06:45:18 +0000

Hi Sasha,

> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: Monday, January 26, 2015 2:22 PM
> To: Xuxiaohu; [email-masked]
> Cc: [email-masked]; [email-masked]
> I do not follow the SFC work closely, so I would like to understand whether the
> NSH should be captured by  transit LSRs on the LSP - or just by the LER acting as
> the LSP tail-end?
> 
> If the latter is correct, the simplest way to indicate presence of the NSH in the
> MPLS payload would be by allocating an "application label" indicating its
> presence by the tail-end LER and by inserting it at the bottom of the label stack
> by the head-end LER - similar to what is done for L2/L3VPN.  Within this

If I understand it correct, the above approach is the same as option 1 as I mentioned in the earlier email (i.e., making each SFF to allocate a unique label for indicating the
presence of NSH).

> approach, if label-based demultiplexing of  packets with NSH in the MPLS
> payload is not required, you could request allocation of a new special purpose
> label from the extended special purposes label space as per RFC 7274, and to
> insert such a label (preceded by the Extension Label ) at the BoS.

What's the purpose of inserting a particular ESP label at the BoS?

Best regards,
Xiaohu

> If the former is correct, the process above still has to be used but it has to be
> augmented by adding the Router Alert Label   at the top of the label stack.
> 
> From my POV these suggestions are in line with the provisions of Section 2.2 of
> RFC 3032 "Determining the Network Layer Protocol" that states:
> 
> <quote>
> The alter label itself couldn’t make the receiving LSR to determine the MPLS
> payload type by examining the MPLS payload.
> 
> Best regards,
> Xiaohu
> 
> > IMHO you could use the alert label 1 to indicate to the LSR that it
> > has to further examine the content of a packet.
> >
> > Regards, Huub.
> >
> > ========
> >
> > presence of NSH since the MPLS encapsulation has no explicit protocol
> > identifier field to indicate the protocol type of the MPLS payload?
> > Should we make each SFF to allocate a unique label for indicating the
> > presence of NSH? Or should we use the control word to indicate it? Or
> > should we reconsider the possibility of adding an explicit protocol
> > identifier field to the MPLS encapsulation so as to solve such kind of issues
> once and for all?
> > >
> > > Best regards,
> > > Xiaohu
> > >
> >
> >
> > --
> >

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 27 Jan 2015 07:27:38 +0000

Xiaohu,
Regarding your question: "What's the purpose of inserting a particular ESP label at the BoS?" 

This is an alternative to each SFF allocating a unique application label. 
This alternative would work if demultiplexing of a received labeled packet with NSH header to a specific SSF within the processing node can be done based on the NSH only.
Saves you the need to allocate and distribute per SSF labels.

Hopefully this answers your question.

Regards,
Sasha 

________________________________________
From: Xuxiaohu <[email-masked]>
Sent: Tuesday, January 27, 2015 8:45 AM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] How to indicate the presence of NSH in an MPLS packet?

Hi Sasha,

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 27 Jan 2015 07:46:00 +0000

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Tuesday, January 27, 2015 2:28 PM
> To: Alexander Vainshtein; Xuxiaohu
> Cc: [email-masked]; [email-masked]
> Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet?
> 
> Sasha,
> 
> 
> 
> I think "the latter" is correct, the only issue I see is adding one more label stack
> entry to the label stack.

Yes, the latter is correct. The issue of adding one more label stack entry to the label stack may become unacceptable in the case where the Service Function Path (SFP) is represented by an label stack while the NSH is now only used as a metadata container. For example, for an SFP consist of n SFs, n "application labels" would have to be inserted into the label stack.

Best regards,
Xiaohu

> >  From my POV these suggestions are in line with the provisions of Section 2.2
> of RFC 3032 "Determining the Network Layer Protocol" that states:
> >
> > <quote>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 27 Jan 2015 07:49:19 +0000

Hi Sasha,

> Sent: Tuesday, January 27, 2015 3:28 PM
> To: Xuxiaohu
> Cc: [email-masked]; [email-masked]; [email-masked]
> This alternative would work if demultiplexing of a received labeled packet with
> NSH header to a specific SSF within the processing node can be done based on
> the NSH only.

Did you mean to use a particular ESP label to indicate a given MPLS payload type (e.g., NSH)?

Best regards,
Xiaohu

> > I do not follow the SFC work closely, so I would like to understand
> > whether the NSH should be captured by  transit LSRs on the LSP - or
> > just by the LER acting as the LSP tail-end?
> >
> > If the latter is correct, the simplest way to indicate presence of the
> > NSH in the MPLS payload would be by allocating an "application label"
> > indicating its presence by the tail-end LER and by inserting it at the
> > bottom of the label stack by the head-end LER - similar to what is
> > done for L2/L3VPN.  Within this
> 
> If I understand it correct, the above approach is the same as option 1 as I
> mentioned in the earlier email (i.e., making each SFF to allocate a unique label
> for indicating the presence of NSH).
> 
> > approach, if label-based demultiplexing of  packets with NSH in the
> > MPLS payload is not required, you could request allocation of a new
> > special purpose label from the extended special purposes label space
> > as per RFC 7274, and to insert such a label (preceded by the Extension Label )
> at the BoS.
> 
> > From my POV these suggestions are in line with the provisions of
> > Section 2.2 of RFC 3032 "Determining the Network Layer Protocol" that
> states:
> >
> > <quote>
> > The alter label itself couldn’t make the receiving LSR to determine
> > the MPLS payload type by examining the MPLS payload.
> >
> > Best regards,
> > Xiaohu
> >
> > > presence of NSH since the MPLS encapsulation has no explicit
> > > protocol identifier field to indicate the protocol type of the MPLS payload?
> > > Should we make each SFF to allocate a unique label for indicating
> > > the presence of NSH? Or should we use the control word to indicate
> > > it? Or should we reconsider the possibility of adding an explicit
> > > protocol identifier field to the MPLS encapsulation so as to solve
> > > such kind of issues
> > once and for all?
> > > >
> > > > Best regards,
> > > > Xiaohu
> > > >
> > >
> > >
> > > --
> > >
> >

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 27 Jan 2015 08:45:30 +0000

Xiaoh hi!
I do not think you need multiple application labels. 
Rather, you could swap these labels as the packet progresses along the SFP, same as is done with MS-PWs.

Regards,
       Sasha 
Email: [email-masked]
Mobile: 054-9266302

> From: Xuxiaohu [mailto:[email-masked]]
> Sent: Tuesday, January 27, 2015 9:46 AM
> To: Loa Andersson; Alexander Vainshtein
> Subject: RE: [sfc] [mpls] How to indicate the presence of NSH in an MPLS
> packet?
> 
> 
> 
> > > whether the
> > NSH should be captured by  transit LSRs on the LSP - or just by the
> > LER acting as the LSP tail-end?
> > >
> > MPLS payload would be by allocating an "application label" indicating
> > its presence by the tail-end LER and by inserting it at the bottom of
> > the label stack by the head-end LER - similar to what is done for
> > L2/L3VPN.  Within this approach, if label-based demultiplexing of
> > packets with NSH in the MPLS payload is not required, you could
> > request allocation of a new special purpose label from the extended
> > special purposes label space as per RFC 7274, and to insert such a label
> (preceded by the Extension Label ) at the BoS.
> > >
> Yes, the latter is correct. The issue of adding one more label stack entry to
> the label stack may become unacceptable in the case where the Service
> Function Path (SFP) is represented by an label stack while the NSH is now
> only used as a metadata container. For example, for an SFP consist of n SFs, n
> "application labels" would have to be inserted into the label stack.
> 
> Best regards,
> Xiaohu
> 
> > /Loa
> > > Section 2.2
> > > the MPLS
> **********************************************************
> ***
> > >> ****
> > >>                 请记住，你是独一无二的，就像其他每一个人一样

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 27 Jan 2015 08:58:41 +0000

Hi Sasha,

If only one application label is required to be inserted into the label stack, where should it be inserted? at the BoS? If so, it seems that the application label must be an ESP label.

Best regards,
Xiaohu

> Sent: Tuesday, January 27, 2015 4:46 PM
> To: Xuxiaohu
> Cc: [email-masked]; [email-masked]; Loa Andersson
> Subject: RE: [sfc] [mpls] How to indicate the presence of NSH in an MPLS packet?
> 
> Xiaoh hi!

---

From: Loa Andersson <[email-masked]>
Date: Tue, 27 Jan 2015 18:02:51 +0800

Sasha, (correct me if I'm wrong)

I thnk you say that there are tow cases

- you can infer from the NSH everything you need to treat the SFC packet
   correct
- you need more information than the NSH

In the first case you can the label at the BoS just need to point out 
that the NSH is present and the rest is done based on the HSH

There are two cases here also
- you assign the label that points to the NSH tLDP style and it is
   signaled between the egress and ingress LSR
- you assign a ESPL and you don't need the signaling.

In the second case you need the application label to point out how the
and the correct handling of the NSH should be done.
In this case you need the signaling?

/Loa

--

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 27 Jan 2015 11:12:47 +0000

Loa,
Your analysis is absolutely correct. There are two cases, and I do not know which one is applicable since by knowledge of SFC is non-existent.

- If specific SF instance within the node can be inferred from the NSH, and if its processing includes identification of the next hop of the SF path, then we can use ESPL, and there is no need for signaling (since it is one value only and  its interpretation is predefined).
- If some information about the handling cannot be inferred from the NSH, be it specific SF instance in this node, or the next hop on the SF path and the SF instance within this node, or, possibly, some combination of those, then you need application labels being allocated by the SF nodes with some granularity, and their distribution via some form of signaling (tLDP or MP-BGP could be used).  

Regards,
       Sasha 

> Sent: Tuesday, January 27, 2015 12:03 PM
> To: Xuxiaohu; Alexander Vainshtein
> In the first case you can the label at the BoS just need to point out that the
> NSH is present and the rest is done based on the HSH
> 
> In the second case you need the application label to point out how the and
> the correct handling of the NSH should be done.
> > If only one application label is required to be inserted into the label stack,
> where should it be inserted? at the BoS? If so, it seems that the application
> label must be an ESP label.
> >
> > Best regards,
> > Xiaohu
> >
> >>>> Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in an
> >>>> MPLS
> >>> packet?
> >>>>
> >>>> Sasha,
> >>>>
> >>>>
> >>>>
> >>>> MPLS payload would be by allocating an "application label"
> >>>> indicating its presence by the tail-end LER and by inserting it at
> >>>> the bottom of the label stack by the head-end LER - similar to what
> >>>> is done for L2/L3VPN.  Within this approach, if label-based
> >>>> demultiplexing of packets with NSH in the MPLS payload is not
> >>>> required, you could request allocation of a new special purpose
> >>>> label from the extended special purposes label space as per RFC
> >>>> 7274, and to insert such a label
> >>> Yes, the latter is correct. The issue of adding one more label stack
> >>> entry to the label stack may become unacceptable in the case where
> >>> the Service Function Path (SFP) is represented by an label stack
> >>> while the NSH is now only used as a metadata container. For example,
> >>> for an SFP consist of n SFs, n "application labels" would have to be
> inserted into the label stack.
> >>>
> >>> Best regards,
> >>> Xiaohu
> >>>
> >>>> /Loa
> >>>>>      based on the packet's network layer header.  The LSR which
> >>>>> pops
> >> the
> >>>>>> Subject: Re: [mpls] How to indicate the presence of NSH in an
> >>>>>> MPLS
> >>> packet?
> >>>>>>
> >>>>>> Xuxiaohu 您好！
> >>>>>>
> >>>>>> IMHO you could use the alert label 1 to indicate to the LSR that
> >>>>>> it has to further examine the content of a packet.
> >>>>>>
> >>>>>> Regards, Huub.
> >>>>>>
> >>>>>> ========
> >>>>>>
> >>>>>>>       The service header is independent of the encapsulation
> >>>>>>> used and
> >> is
> >>>>>> protocol identifier field to indicate the protocol type of the
> >>>>>> MPLS
> >>> payload?
> >>>>>> the presence of NSH? Or should we use the control word to
> >>>>>> indicate it? Or should we reconsider the possibility of adding an
> >>>>>> explicit protocol identifier field to the MPLS encapsulation so
> >>>>>> as to solve such kind of issues
> >>>> once and for all?
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> Xiaohu
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>
> >>>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 27 Jan 2015 11:00:59 +0000

Xiaohu,

I would like to clarify my position.

1.       Application level and a dedicated ESP are two alternative options to indicate the presence of NSH in the payload of a labeled packet.

a.       A dedicated ESP could be used if association of the received packet with a specific SF instance within the processing NE can be performed based exclusively on NSH. Just one ESP label would be used (occupying 2 entries in the label stack), and it would just be treated as the NSH presence indicator. This situation is similar to using the Generic Associated Channel Label (GAL) in MPLS-TP.

b.      An application label per SF instance should be used if the NSH header is not sufficient for defining the SF instance that would handle the packet. A dedicated application label would be allocated at least per SF instance within the NE, and some suitable protocol would be used for distributing association between this label and its specific SF instance. This is similar to using PW labels in PWs and/or Application labels (distributed with their associated labeled IP-VPN routes) in L3VPN

c.       My knowledge of SFC is all but on-existent, so I cannot say which of these two alternatives is relevant.

2.       In both cases the label (be it an application label or a dedicated ESP) must be inserted by the head-end at the BoS so that it would be processed by the tail-end node of the LSP without affecting any transit nodes (which would just perform standard MPLS forwarding).

3.       In the case of SF paths:

a.       If the dedicated ESP is used, handling of the packet by the current SF must include definition of the next SF node and forwarding to this node. The forwarded packet would again include the dedicated ESP at the BoS, with the “tunnel LSP” label stack on top of that

b.      If the application label is used, the next SF node and the SF instance within this node could be inferred either from the payload or from the application label, or from their combination. In any case forwarding of the packet to the next SF would result in swapping of the application label at the BoS (similar to what is done in MS-PWs) and pushing the “tunnel LSP” label stack on top of that.

Not sure if this helps, or just adds more noise:).

Regards,

       Sasha

Mobile: 054-9266302

> Sent: Tuesday, January 27, 2015 10:59 AM

> To: Alexander Vainshtein

> > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Loa Andersson

> > Rather, you could swap these labels as the packet progresses along the

> > SFP, same as is done with MS-PWs.

> > Email: [email-masked]<mailto:[email-masked]>

> > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > > Subject: RE: [sfc] [mpls] How to indicate the presence of NSH in an

> > > MPLS packet?

> > > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > > > Subject: Re: [sfc] [mpls] How to indicate the presence of NSH in

> > > > an MPLS

> > > > > I do not follow the SFC work closely, so I would like to

> > > > > understand whether the

> > > > NSH should be captured by  transit LSRs on the LSP - or just by

> > > > the LER acting as the LSP tail-end?

> > > > > If the latter is correct, the simplest way to indicate presence

> > > > > of the NSH in the

> > > > the bottom of the label stack by the head-end LER - similar to

> > > > what is done for L2/L3VPN.  Within this approach, if label-based

> > > > I think "the latter" is correct, the only issue I see is adding

> > > > one more label stack entry to the label stack.

> > > > > If the former is correct, the process above still has to be used

> > > > > but it has to be

> > > > augmented by adding the Router Alert Label   at the top of the label

> stack.

> > > > >  From my POV these suggestions are in line with the provisions

> > > > > of Section 2.2

> > > > > From: mpls <[email-masked]<mailto:[email-masked]>> on behalf of Xuxiaohu

> > > > > <[email-masked]<mailto:[email-masked]>>

> > > > > To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > > > > The alter label itself couldn’t make the receiving LSR to

> > > > > determine the MPLS

> > > > >> To: Xuxiaohu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > > > >>> In the case where the outer encapsulation is an MPLS LSP, how

> > > > >>> to indicate the

> > > > >> Should we make each SFF to allocate a unique label for

> > > > >> indicating the presence of NSH? Or should we use the control

> > > > >> word to indicate it? Or should we reconsider the possibility of

> > > > >> adding an explicit protocol identifier field to the MPLS

> > > > >> encapsulation so as to solve such kind of issues

> > > > > [email-masked]<mailto:[email-masked]>

> > > > > [email-masked]<mailto:[email-masked]>

> > > > Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

> > > > Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 27 Jan 2015 10:36:36 -0500

I am a bit concerned by the tone of this which assumes that there is 
only one way to use MPLS as a transport for NSH.  There are several 
different MPLS-based transport architectures that will work.  As far as 
I can tell, most of them will even interoperate with each other.  But 
they do imply different things about how NSH is indicated.

As far as I can tell, all of the transport mechanisms operate on the 
assumption that forwarding devices between SFF will not see or need to 
be aware of the NSH header.  Thus, those will always interoperate.

In the MPLS case, whether one terminates the MPLS LSP at the first SFF, 
or allows to to cross several SFF affects how identification is done. 
Also, if segment routing is used then there are other options such as 
the use of dedicated local service labels for NSH delivery.  (Doing that 
with conventional MPLS is more complex, but likely can also be done.)

Yours,
Joel

---

From: David Allan I <[email-masked]>
Date: Tue, 27 Jan 2015 17:55:35 +0000

Hi folks:

Correct me if I’m wrong, but isn’t any label stack directly prepending an NSH that is composed entirely of non-reserved labels going to mean an SFC header (at least for non OAM, non critical metadata, version 1 packets) will alias as an IPv4 packet for pretty much all transit LSRs? And version 1 OAM packets will alias as IPv6 blowing out fate sharing? In either case, obtaining entropy for ECMP by transit LSRs will be overlaid on the base and service path headers (and beyond for IPv6 aliasing)….

Regards
Dave

From: mpls [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Tuesday, January 27, 2015 3:01 AM
To: Xuxiaohu
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] [sfc] How to indicate the presence of NSH in an MPLS packet?

Xiaohu,

Regards,

       Sasha

Mobile: 054-9266302

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 28 Jan 2015 02:34:09 +0000

Hi Joel,

Thanks a lot for your comments. Please see my response inline.

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Tuesday, January 27, 2015 11:37 PM
> To: Xuxiaohu; Alexander Vainshtein; [email-masked]
> I am a bit concerned by the tone of this which assumes that there is only one
> way to use MPLS as a transport for NSH.  There are several different
> MPLS-based transport architectures that will work.  As far as I can tell, most of
> them will even interoperate with each other.  But they do imply different things
> about how NSH is indicated.

Although we could use different approaches for indicating the presence of the NSH, wouldn't it be better if we could find a unified and sustainable way to address this MPLS payload type indication issue?

> As far as I can tell, all of the transport mechanisms operate on the assumption
> that forwarding devices between SFF will not see or need to be aware of the
> NSH header.  Thus, those will always interoperate.
> 
> In the MPLS case, whether one terminates the MPLS LSP at the first SFF, or
> allows to to cross several SFF affects how identification is done.
> Also, if segment routing is used then there are other options such as the use of
> dedicated local service labels for NSH delivery.  (Doing that with conventional
> MPLS is more complex, but likely can also be done.)

Did you mean using a label stack to represent an SFP by saying "if segment routing is used", If so, since each SF node along the SFP would need to know the MPLS payload type for performing the corresponding service function on the original payload, it would require SF nodes to allocate a dedicated local label per payload type for a given SF. Provided we have a unified way for indicating the MPLS payload type, SF nodes only need to allocate a single label for a given SF regardless of the payload type.

Best regards,
Xiaohu

> >> If the latter is correct, the simplest way to indicate presence of
> >> the NSH in the MPLS payload would be by allocating an "application
> >> label" indicating its presence by the tail-end LER and by inserting
> >> it at the bottom of the label stack by the head-end LER - similar to
> >> what is done for L2/L3VPN.  Within this
> >
> > If I understand it correct, the above approach is the same as option 1
> > as I mentioned in the earlier email (i.e., making each SFF to allocate a unique
> label for indicating the presence of NSH).
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 27 Jan 2015 21:39:20 -0500

If one uses service labels (as in segment routing), one would not have a 
service label per payload type but rather one per services.  Since the 
SFC services will be different from any other use of labels, those 
labels will be distinct.  Since they are local, it does not even matter 
how many there are.

The point is that the different deployments of MPLS for service chaining 
lead to different identification needs.  If the needs were identical 
then I would agree that a common identification scheme would be appropriate.

Yours,
Joel

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 28 Jan 2015 03:29:27 +0000

Hi Joel,

> Sent: Wednesday, January 28, 2015 10:39 AM
> If one uses service labels (as in segment routing), one would not have a service
> label per payload type but rather one per services.  Since the SFC services will
> be different from any other use of labels, those labels will be distinct.  Since
> they are local, it does not even matter how many there are.

Since the MPLS payload could be IPv4 packet, IPv6 packet, Ethernet frame or even NSH (as a metadata container only) in the MPLS-SPRING-based SFC approach, how could the SF or the SFC-proxy determine the MPLS payload type if one label per service is allocated.

> The point is that the different deployments of MPLS for service chaining lead to
> different identification needs.  If the needs were identical then I would agree
> that a common identification scheme would be appropriate.

IMHO, although the SFP/SFC identification needs are different, the MPLS payload type identification needs are almost the same.

Best regards,
Xiaohu

> >> different MPLS-based transport architectures that will work.  As far
> >> as I can tell, most of them will even interoperate with each other.
> >> But they do imply different things about how NSH is indicated.
> >
> > Although we could use different approaches for indicating the presence of the
> NSH, wouldn't it be better if we could find a unified and sustainable way to
> address this MPLS payload type indication issue?
> >
> >> assumption that forwarding devices between SFF will not see or need
> >> to be aware of the NSH header.  Thus, those will always interoperate.
> >>
> >> In the MPLS case, whether one terminates the MPLS LSP at the first
> >> SFF, or allows to to cross several SFF affects how identification is done.
> >> the use of dedicated local service labels for NSH delivery.  (Doing
> >> that with conventional MPLS is more complex, but likely can also be
> >> done.)
> >
> > Did you mean using a label stack to represent an SFP by saying "if segment
> routing is used", If so, since each SF node along the SFP would need to know the
> MPLS payload type for performing the corresponding service function on the
> original payload, it would require SF nodes to allocate a dedicated local label per
> payload type for a given SF. Provided we have a unified way for indicating the
> MPLS payload type, SF nodes only need to allocate a single label for a given SF
> regardless of the payload type.
> >
> > Best regards,
> > Xiaohu
> >
> >> Yours,
> >> Joel
> >>
> >>>> From: Alexander Vainshtein
> >>>> [mailto:[email-masked]]
> >>>> it at the bottom of the label stack by the head-end LER - similar
> >>>> to what is done for L2/L3VPN.  Within this
> >>>
> >>> If I understand it correct, the above approach is the same as option
> >>> 1 as I mentioned in the earlier email (i.e., making each SFF to
> >>> allocate a unique
> >>>> special purpose label from the extended special purposes label
> >>>> space as per RFC 7274, and to insert such a label (preceded by the
> >>>> Extension Label )
> >> at the BoS.
> >>>
> >>>>>                  请记住，你是独一无二的，就像其他每一个人一
> 样