Re: [mpls] Concerns about ISD

Tianran, Tony, and Jie,
thank you for a lively and helpful discussion. I believe it is good to lay
our assumptions on the table, check what is real and what is not so much.
To me, both ISD and PSD are essential elements of MNA. I expect that there
will be lots of considerations, discussions and arguments around where a
particular MNA will have its associated data - ISD or PSD. And, as the case
with ELI/EL, there will come necessary extensions to routing protocols and
corresponding YANG data models. In my view, the new MPLS data plane must be
accompanied with extensions in the control and management plane.
To summarize my position, it seems that constrains of available today HW
must be considered but should not prevent us from defining a more powerful,
flexible new MPLS architecture. As our common experience has demonstrated
again and again - HW advances faster than we can standardize protocols. I
view architectural optional capabilities as an opportunity to realize a new
functionality, for example on-path telemetry like IOAM, but only when when
that does not affect the main goal of the network - efficiently forward
data flows. that seems as an obvious, and I believe that the MNA framework
and requirements documents express it clearly. We only need to follow them.

Regards,
Greg

On Mon, Apr 11, 2022 at 7:08 PM Tianran Zhou <zhoutianran=
40huawei.com@dmarc.ietf.org> wrote:

> Hi Tony,
>
>
>
> Please see in line.
>
>
>
> Best,
>
> Tianran
>
>
>
> *From:* Tony Li [mailto:tony1athome@gmail.com] *On Behalf Of *Tony Li
> *Sent:* Monday, April 11, 2022 11:35 PM
> *To:* Tianran Zhou <zhoutianran@huawei.com>
> *Cc:* mpls@ietf.org
> *Subject:* Re: [mpls] Concerns about ISD
>
>
>
>
>
> Hi Tianran,
>
>
>
>
>
> Please see RFC 9088 and 9089.
>
> While hardware continues to evolve, as we’ve discussed previously, we
> really want to try to maximize the value of the hardware that’s already in
> the field. That’s in  the operator’s best interests and thus in ours as
> well.
>
>
>
> ZTR> I quickly go over this two RFCs. I did not see any limits on the
> number of readable labels. On the contrast, it allows devices with
> different capabilities. By using the flooding and notification mechanism,
> the controller or so knows the capability of each device, hence easy to
> program the stack on the head node.
>
>
>
>
>
> Exactly.  This exists because there is a need to understand the readable
> label stack depth (RLSD) and operate within it.  RLSD is important for
> interoperability and pushing everything to PSD would hinder
> interoperability. People did things this way for a reason. It makes sense
> for us to continue to do so.
>
>
>
> ZTR2> PSD can work with RLSD, I cannot see how it will hinder the
> interoperability.
>
> I see hard coding an ASIC as a poor choice. But I’ve only been saying that
> since 1996. :)  All of the silicon that I’ve had a hand in has been
> microcoded for exactly this reason, with very little penalty.
>
>
>
> ZTR> I disagree. New chips are combination of AICS part and microcode
> part. Microcode is for changes and flexibility. But ASIC is for performance.
>
>
>
> Ok, clearly we operate with different silicon technology.
>
>
>
> In a related matter, it does occur to me that if you dislike ISD, you are
> free to take any sub-stacks that you want to inject and push them to the
> bottom of the label stack. This would effectively push all of your ISD just
> above PSD, effectively doing the same thing as doing everything in PSD.  Of
> course, this would minimize your interoperability.  Other devices would be
> able to use MNA through your device, but you would not be able to send MNA
> through them. If this is what you want, we won’t stop you.
>
>
>
> ZTR2> Of course I would not put ISD just above PSD. As PSD can provide all
> the functionalities, I do not see the reason why we need ISD anymore.
> Entropy label is a simple one, community chose to implement the in stack
> operation <optionally> as in RFC 6790. For ISD, I would not expect it to
> split the community effort. You can implement any fascinating ISD design
> privately, we won’t stop you. But I do not think we need any IETF standard
> on ISD.
>
>
>
> Regards,
>
> Tony
>
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>