Re: [mpls] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

Bruno,


> On Apr 1, 2022, at 11:06 AM, <[email protected]> <[email protected]> wrote:
> 
> Extending your proposal to support in-stack data effectively puts us at draft-jags-mpls-ext-hdr-00, with the backward compatibility issues that we’ve discussed. That is, IMHO, no longer in the realm of acceptable risk.
> [Bruno] Extending the proposal to add LSE requires signaling that the Egress support that capability. Solutions requiring a new SPL requires a similar signaling. In both cases, I don’t think that this may be called a backward compatibility issue, if but so, I think the statement equally applies to other proposals defining a new SPL


If you add LSE and use signaling to avoid incapable nodes, then signaling must identify every node that could potentially pop the EL sub-stack. If EL has been populated multiple times, that is potentially more than the Egress node. 

Yes, requiring a new SPL requires exactly the same signaling. This is the point that we’ve been making: there is no advantage to reusing ELI. It becomes the same. Other proposals are not claiming backward compatibility.

Tony

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals