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

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:
> 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.)

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.

>
> 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. 
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.

>
> 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?
>
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
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls