Re: [mpls] Questioning the need for HxH PSD

Hi Stewart, 

Thanks for raising this discussion. Please see some thoughts inline:

> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
> Sent: Friday, August 19, 2022 6:31 PM
> To: mpls <mpls@ietf.org>
> Subject: [mpls] Questioning the need for HxH PSD
> 
> 
> Just to clarify a comment that I made yesterday on the ODT call.
> 
> I made reference to an existence proof for the need of ISD and EL.
> 
> EL is an existence proof of ISD
> To some extend so are context labels and ESPLs

I don't think the current EL can be considered as a proof of ISD we discussed for MNA. The reasons are: 

1) EL is a mechanism which has been specified and implemented long time before the concept ISD is introduced, and it works well without introducing the ISD mechanism. 

2) The format of EL complies with the MPLS LSE encoding, so that it can be processed with normal label parsing and forwarding operation. While it seems ISD will redefine the format of the label stack entries (some or all of the label, TC and TTL field).

3) EL takes effect without requiring a network node to scan the label stack to find the ELI and process the following EL. While such behavior is required by ISD.

The similar reasons also apply to the ESPLs. 

> 
> My reference to EL was not however, as some apparently thought, an
> expression of support for the EL extension proposal. I think that is in essence
> the redefinition of an existing deployed design and without an
> implementation survey to determine the behaviour of deployed systems I
> remain concerned that the change would be unsafe.

This also shows that EL and ISD are different design. 

> 
> There are other uses of  ISD (as opposed to PSD) that can be justified on the
> basis of performance:
> 
> NFRR - Mike Shand and I wanted that when we were actively developing
> various FRR strategies but gave up on the approaches because at the time we
> could see no way to get the feature in the packet.  Times have however
> moved on.

During IETF 114 meeting there was discussion about alternative approaches to achieve this function based on control plane. 

> 
> Slice identifier is another case.

There was no discussion about whether slicing related identifiers should be carried in ISD or PSD. There are proposals for both. 

> 
> Detnet might use it to avoid having to build the overlay structure that it uses
> for PREOF (whose parameters can only live BoS at the moment)
> 
> Deterministic schemes like draft-eckert-detnet-mpls-tc-tcqf-03 could also
> usefully have access to more bits as an adjunct to the label.

This depends on the requirement of specific mechanisms defined in Detnet. For some of the mechanisms, the information may be carried in ISD, while for some other mechanisms, PSD may be used. 

> We also have an existence proof of the need for E2E PSD with the ACH.
> 
> Where I think there is concern is with assuring ourselves of the need for
> hop-by-hop PSD.
> 
> Previously we had an example and that was ECMP where we gleaned the
> ECMP parameters form the payload itself, but we have been obsoleting that
> through the use of EL, and with good cause because we no longer require
> what is effectively DPI on routers for the basic load balancing function.
> 
> Now some might say “what is the problem, silicon and can do this” to which
> the answer had to be that those deep reach systems are expensive in terms of
> silicon, which means they are expensive in terms of board area, yield, port
> density and importantly in the modern world power consumption and heat
> generation.
> 
> So this takes me to the question of what are the cases where hop-by-hop PSD
> is the only solution to an important problem of economic consequence?

As shown in the above replies, PSD may also be used for several HBH applications. Another PSD application is IOAM, which can be either HBH or E2E. 

In the PALS session of IETF 114, there was discussion about when to use ISD and when to use PSD. Someone said it depends on the urgency of the data to be processed, while some other people says it depends on the size and format of the data to be carried. This discussion would need to continue.

Best regards,
Jie

> 
> - Stewart
> 
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls