[mpls] Re: John Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)

[[e-mail]]

Hi John,

Thank you for the prompt reply.
I've posted version -16 to address your comments. Link as below.
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-inband-pm-encapsulation-16 
Please see inline for the detailed responses.

Original


From: JohnScudder <[e-mail]>
To: 肖敏10093570;
Cc: The IESG <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;Tony Li <[e-mail]>;
Date: 2024年09月06日 00:32
Subject: Re: John Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)

Hi Xiao Min,
 
Trimmed for brevity.
 
> On Sep 3, 2024, at 3:55 AM, [e-mail] wrote:
 
[…]
 
> ### Number of flows vs. ECMP
>  
> Section 3 says,
>  
>    The Flow-ID Label (FL) is used as an MPLS flow identification
>    [RFC8372].  Its value MUST be unique within the administrative
>    domain.
>  
> So, there can be at most 2^20 flows per administrative domain. That seems
> small, but I guess it's OK if I think of the number of instrumented flows as
> being a small fraction of the total flows that exist. But then later, Section 7
> says,
>  
>    Analogous to what's described in Section 5 of [RFC8957], under
>    conditions of Equal-Cost Multipath (ECMP), the introduction of the FL
>    may lead to the same problem as caused by the Synonymous Flow Label
>    (SFL).  The two solutions proposed for SFL would also apply here.
>    Specifically, adding FL to an existing flow may cause that flow to
>    take a different path.  If the operator expects to resolve this
>    problem, they can choose to apply entropy labels [RFC6790] **or add FL
>    to all flows**.
>  
> (Emphasis added.)
>  
> When I add these up, it seems to me that the operator of a large network has
> some unpleasant options.
>  
> - They can accept that the use of FL may perturb the path taken by the flow.
> But that seems unacceptable for a technology whose purpose is performance
> measurement.
>  
> - They can use entropy label.
>  
> - They can add FL to all flows, but this means they have to instrument every
> flow, so they really are restricted to 2^20 total flows in their network. That
> is a rather small number, probably too small for a significant deployment..
>  
> The conclusion I arrive at is that any deployment at scale has to use entropy
> label. Is that correct? If so it seems to me it would be better to be more
> up-front about it. If I'm mistaken (e.g. there's some realistic use case where
> it's fine to accept the observer effect perturbing the selected path, or where
> 2^20 flows is more than enough) I'd appreciate some help seeing it.
> [XM]>>> I checked it with my colleague who has implemented this feature in ZTE. The takeaway is that "adding FL to an existing flow may cause that flow to take a different path" doesn't apply to our implementation. There are two ways for ECMP hash, one way is the entropy label, and the other way is the inner IP header, so the SPL and the FL won't affect the ECMP at all
 
Got it. So if I understand correctly, you’re saying my analysis isn’t quite right, because in some implementations FL won’t perturb the flow and the observer effect won’t exist. OK.  
 [XM]>>> Thank you for your understanding. :-)


> ### Penultimate hop popping creates a conflict
>  
> Section 4 has,
>  
>    *  The processing node MUST pop the XL, FLI and FL from the MPLS
>       label stack when it needs to pop the preceding forwarding label.
>       The egress node MUST pop the whole MPLS label stack, and this
>       document doesn't introduce any new process to the decapsulated
>       packet.
>  
> But Section 3.1 said,
>  
>    Note that here if the penultimate hop popping (PHP) is in use, the
>    PHP LSR that recognizes the cSPL MUST NOT pop the cSPL and the
>    following Flow-ID label, otherwise the egress LSR would be excluded
>    from the performance measurement.
>  
> As far as I can tell, these two are in conflict, and there's no way to comply
> with both other than by disabling PHP. That's OK I guess, but if so you should
> just say PHP isn't allowed.
> [XM]>>> Yes, you're correct. Propose to change the text in Section 3.1 as below.
> OLD
>    Note that here if the penultimate hop popping (PHP) is in use, the
>    PHP LSR that recognizes the cSPL MUST NOT pop the cSPL and the
>    following Flow-ID label, otherwise the egress LSR would be excluded
>    from the performance measurement.
> NEW
>    Note that here if the penultimate hop popping (PHP) is in use, the
>    PHP LSR that recognizes the cSPL should not pop the cSPL and the
>    following Flow-ID label, otherwise the egress LSR would be excluded
>    from the performance measurement. So the PHP should be disabled, unless it's acceptable to exclude the egress LSR.
 
That’s better although I think it still risks confusing the reader since it doesn’t make the reasoning explicit. Maybe something like,
 
NEW:
   With penultimate hop popping (PHP, Section 3.16 of [RFC3031]) the top
   label is "popped at the penultimate LSR of the LSP, rather than at
   the LSP Egress”. Since [Section 4] of the present document, final
   bullet, requires that "The processing node MUST pop the XL, FLI and
   FL from the MPLS label stack when it needs to pop the preceding
   forwarding label”, this implies that the penultimate LSR needs to
   support this specification in order to follow the requirement of
   Section 4. If this is done, the egress LSR would be excluded from the
   performance measurement. Therefore, when this specification is in use
   PHP should be disabled, unless the penultimate LSR is known to have
   the necessary support, and unless it’s acceptable to exclude the
   egress LSR.
 [XM]>>> As always, your text is better. I used your text in version -16 with one small tweak, s/support this specification in order to follow the requirement of Section 4/follow the requirement of Section 4 in order to support this specification.

Cheers,
Xiao Min


Thanks,
 
—John