Subject: [sfc] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 19 Jun 2018 11:14:02 -0400

I’ve just uploaded https://tools.ietf.org/html/draft-malis-mpls-sfc-
encapsulation-00 . It’s a short draft that discusses how to carry SFC
packets that include the NSH over MPLS from one SFF to the next, so that
SFFs that support the NSH can be connected via MPLS. It also includes the
ability for MPLS nodes to support more than one SFF. Comments are
appreciated!

Thanks,
Andy

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 24 Jun 2018 15:29:40 +0000

Andy and all,
I’ve read the draft and I have a question regarding position of the SFF label in the label stack.
The draft states the SFF label is located at the bottom of the stack and immediately followed by the NSH header.

I wonder if it is possible to have some special purpose labels to follow the SFF label. The relevant example could be GAL (RFC 5586) followed by the GACH for OAM purposes.
RFC 7708 has allowed this for PW labels which originally also have been defined as BoS only

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: mpls [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Tuesday, June 19, 2018 6:14 PM
To: [email-masked]; [email-masked]
Subject: [mpls] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt

I’ve just uploaded https://tools.ietf.org/html/draft-malis-mpls-sfc-encapsulation-00 . It’s a short draft that discusses how to carry SFC packets that include the NSH over MPLS from one SFF to the next, so that SFFs that support the NSH can be connected via MPLS. It also includes the ability for MPLS nodes to support more than one SFF. Comments are appreciated!

Thanks,
Andy

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 24 Jun 2018 12:29:27 -0400

Sasha,

Yes, thanks for asking, we can add that to the next revision. The intent is
that the NSH label operates similar to a PW or VPN label, so whatever
applies to them should apply to the NSH label as well.

And thanks for reading the draft!

Cheers,
Andy

On Sun, Jun 24, 2018 at 11:29 AM, Alexander Vainshtein <
[email-masked]> wrote:

> I wonder if it is possible to have some special purpose labels to follow
> the SFF label. The relevant example could be GAL (RFC 5586) followed by the
> GACH for OAM purposes.
>
> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Andrew G. Malis
> *Sent:* Tuesday, June 19, 2018 6:14 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* [mpls] Request for comments on draft-malis-mpls-sfc-
> encapsulation-00.txt
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 25 Jun 2018 17:55:51 +0100

Andy,

NSH has an OAM mechanism which you would use for OAM at that level.

The only time you would want to use a GAL is OAM to the SFF itself.

If we think that it is useful to apply OAM between an SFF pair we could 
use a GAL.

If we think that it is useful to do ECMP, we might also put an EL/ELI at 
BoS. We could also do it with a FAT label. I am not sure what is better.

Best regards

Stewart

On 24/06/2018 17:29, Andrew G. Malis wrote:
> Sasha,
>
> Yes, thanks for asking, we can add that to the next revision. The 
> intent is that the NSH label operates similar to a PW or VPN label, so 
> whatever applies to them should apply to the NSH label as well.
>
> On Sun, Jun 24, 2018 at 11:29 AM, Alexander Vainshtein 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Andy and all,
>
>     The draft states the SFF label is located at the bottom of the
>     stack and immediately followed by the NSH header.
>
>     I wonder if it is possible to have some special purpose labels to
>     follow the SFF label. The relevant example could be GAL (RFC 5586)
>     followed by the GACH for OAM purposes.
>
>     <mailto:[email-masked]>
>
>     *From:*mpls [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Andrew G. Malis
>     *To:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* [mpls] Request for comments on
>     draft-malis-mpls-sfc-encapsulation-00.txt
>
>     I’ve just uploaded
>     https://tools.ietf.org/html/draft-malis-mpls-sfc-encapsulation-00
>     <https://tools.ietf.org/html/draft-malis-mpls-sfc-encapsulation-00> .
>     It’s a short draft that discusses how to carry SFC packets that
>     include the NSH over MPLS from one SFF to the next, so that SFFs
>     that support the NSH can be connected via MPLS. It also includes
>     the ability for MPLS nodes to support more than one SFF. Comments
>     are appreciated!
>
>     Thanks,
>
>     Andy
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 25 Jun 2018 13:34:17 -0400

It's always a bit tricky to specify the precise rules for creating a 
label stack.  I think the rules for creating the label stack atop an NSH 
packet are probably something like the following.  Suppose one has an 
NSH packet, and one has chosen a target node on the network, where that 
target node is (or contains) the SFF that next needs to receive the NSH 
packet (the target SFF).  Then create the label stack as follows:

- Push on zero or more labels that are to be interpreted by the target 
SFF.  (I guess the GAL label could be an example here.)

- Push on the SFF label.  (A label that, at the target node, is 
associated with the target SFF.)

- Push on zero or more additional labels such that (a) the resulting 
label stack will cause the packet to be transported to the target node, 
and (b) when the packet arrives at the target node, either:

   * the SFF label will be at the top of the label stack, or

   * the SFF label will rise to the top of the label stack before the 
packet is forwarded to another node and before the packet is dispatched 
to a higher layer.

It's probably best to also state that PHP MUST NOT be applied to the SFF 
label.  (I realize that the control plane is out of scope here, but 
whatever the control plane is, it needs to set up the PHP appropriately.)

It would be good to say what the SFF is supposed to do if it gets an 
MPLS packet rather than an NSH packet (i.e., if the SFF label is not 
BoS).  The SFF might or might not understand the label following the SFF 
label.  Also, if the following label is v4-explicit-null or 
v6-explicit-null, does that convey any semantics?  Frankly, I wonder if 
it's a bit dangerous to allow labels below the SFF label, as this will 
cause problems if the SFF label is programmed to cause a dispatch of the 
remaining packet to a procedure that does not understand MPLS at all and 
is expecting to see an NSH packet.

It would be good to say where something like the entropy label would 
appear in the stack.  Before the SFF label?  Or after?  Or either?

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 25 Jun 2018 19:58:09 +0100

Hi Eric

Your description is what I would expect to happen.

The question is always  what should you leave unsaid as it is obvious to 
those skilled in the art, and creates maximum flexibility to allow 
innovation, and what should you say to resolve ambiguity and prevent an 
unnecessary infinity of functional combinations?

On 25/06/2018 18:34, Eric C Rosen wrote:
> label stack.  I think the rules for creating the label stack atop an 
> NSH packet are probably something like the following.  Suppose one has 
> an NSH packet, and one has chosen a target node on the network, where 
> that target node is (or contains) the SFF that next needs to receive 
> the NSH packet (the target SFF).  Then create the label stack as follows:
>
> label stack will cause the packet to be transported to the target 
> node, and (b) when the packet arrives at the target node, either:
>
> packet is forwarded to another node and before the packet is 
> dispatched to a higher layer.
>
> It's probably best to also state that PHP MUST NOT be applied to the 
> SFF label.  (I realize that the control plane is out of scope here, 
> but whatever the control plane is, it needs to set up the PHP 
> appropriately.)

For that to happen you would need to pop two labels which can only 
happen by error, which is something we can mitigate against, but never 
completely avoid.

> BoS).  The SFF might or might not understand the label following the 
> SFF label. 
I imagine that would be a parameter of the SFF label. You would 
certainly need to know which type the packet was to get the MAC layer right.

> Also, if the following label is v4-explicit-null or v6-explicit-null, 
> does that convey any semantics? 
Probably which ethernet type to use if going to the SF over a LAN.

> Frankly, I wonder if it's a bit dangerous to allow labels below the 
> SFF label, as this will cause problems if the SFF label is programmed 
> to cause a dispatch of the remaining packet to a procedure that does 
> not understand MPLS at all and is expecting to see an NSH packet.

It depends how the packet gets from the SFF to the SF. If it is pure 
internal processing on the SFF and no further checking that would be a 
problem, although you could prevent it with an SFF rule, but in any case 
where the packet was sent across a network the MAC type ought to be MPLS 
in which case the SFF would bin the packet as unknown/unexpected type.

> appear in the stack.  Before the SFF label?  Or after?  Or either?
Certainly before, but there is a case for both else we will end up also 
needing FAT labels.

Thanks for your thoughts, we will reflect them in the next version.

- Stewart

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