Re: [mpls] Concerns about ISD

[John E Drake <[e-mail]>]

Hi,

Comment inline below.

Yours Irrespectively,

John



Juniper Business Use Only
From: Tianran Zhou <[e-mail]>
Sent: Thursday, May 5, 2022 8:34 PM
To: John E Drake <[e-mail]>
Cc: John E Drake <jdrake=[e-mail]>; Tony Li <[e-mail]>; mpls <[e-mail]>
Subject: RE: [mpls] Concerns about ISD

[External Email. Be cautious of content]

Sure, obviously they are for different purposes.
Can we combine multiple existing components for one goal?
Say we have A and B, can we use A+B for something?
Or we must create C to replace A+B?

[JD]  To recap this extended discussion:

1)  A is binding SID, which is optional and which makes SR label stacks smaller but not necessarily small

2)  B is NAS.

3)  Even with A, SR label stacks may be large

4)  Because of 3),  a transit node may not be able to find the bottom of stack

5)  Because of 4), there need to be multiple copies of a NAS within a stack

6)  A network action may have ancillary data and that ancillary data may be in-stack or post-stack

7)  Because of 4), a network action related to forwarding which has ancillary data should specify that it is in-stack

Tianran

From: John E Drake [mailto:[e-mail]]
Sent: Thursday, May 5, 2022 9:02 PM
To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Cc: John E Drake <jdrake=[e-mail]<mailto:jdrake=[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: RE: [mpls] Concerns about ISD

BSID and NAS are for completely different purposes.  The former is for stack compression and the latter is for network actions.

Yours Irrespectively,

John



Juniper Business Use Only
From: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, May 4, 2022 8:43 PM
To: John E Drake <[e-mail]<mailto:[e-mail]>>
Cc: John E Drake <jdrake=[e-mail]<mailto:jdrake=[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: RE: [mpls] Concerns about ISD

[External Email. Be cautious of content]

Hi,
It does not make sense to me to create a new mechanism as ISD in operators’ network, while not using existing mature BSID.
There is no sign the reinvented wheel could be better.

Tianran

From: John E Drake [mailto:[e-mail]]
Sent: Saturday, April 30, 2022 12:05 AM
To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Cc: John E Drake <jdrake=[e-mail]<mailto:jdrake=[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Concerns about ISD

Comment inline
Sent from my iPhone

On Apr 29, 2022, at 11:17 AM, Tianran Zhou <[e-mail]<mailto:[e-mail]>> wrote:

[External Email. Be cautious of content]

Hi,
Comments inline.

Tianran

>
> Hi John,
>
>  If we want to reuse this for consistent design (easy for interop), how do you
> want to encode it to ISD?
>
> [JD]  That's up to a given solution to propose, but probably two LSEs
>
> ZTR> It would be interesting to know your proposal.

[JD]  As I said, the size of an NRP ID needs to be decided and any MNA solution needs propose how it is to be
encoded

ZTR> Ok, so any solution need to demonstrate how it works.

>
>
> 2. If we really worry about the MSD of SR, why not use BSID as a direct way to
> reduce the stack?
>
> [JD]  Because it can't be mandated
>
> ZTR> I am sorry, I do not understand why BSID is not applicable. What's the "
> mandated " mean here?

[JD]  MNA cannot require the use of BSIDs

ZTR> Is this an agreed requirement? In the requirement draft? I still can’t understand. On one hand, you worry about low stack depth. On the other hand, you don’t want to use an easy way to solve this problem.
[JD]  I don’t think it’s realistic to tell a network operator that they have to deploy BSID in order to deploy MNA.  Also, I don’t think it’s a good solution became a label stack of BSIDs may still be too large and the node advertising the BSID is going to expand the the label stack with the path SIDS so the nodes on the path will have to deal with a large label stack.


>
> Tianran