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

[[e-mail]]

Hi Deborah,


Thank you very much for your help.
Please see inline.

Original


From: BRUNGARD,DEBORAHA <[e-mail]>
To: 肖敏10093570;[e-mail] <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年09月06日 23:33
Subject: RE: [mpls] Re: John Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)



Hi,
 
Looking at John’s operational concerns and other ADs concerns with this document being targeted as Historic, a couple of comments based on some earlier process experience.
 
As Eric says, I don’t recall a document having a sentence “it is agreed that this document will be made Historic”. One could ask “who has agreed”? IESG? Making a document historic has a procedure, RFC2026. There’s been a lot of discussion (drafts) on the interpretation of “superseded” and “obsolete” in RFC2026 to make Historic. No agreement. There was some criteria proposed in section 3.2:
ietf.org/archive/id/draft-alvestrand-newtrk-historical-00.txt
 
I’m not sure any of these criteria apply to this document. My caution is that while the working group has used the term “historic” in their discussions to scope this work, it is not necessarily procedurally correct. Especially as it seems the rationale for doing this document is that it is implemented.
 
I’d suggest it would be more helpful if this sentence troubling Eric would clarify operationally why MNA will be a better solution (to provide a hint to vendors/operators of a new capability under development) and not simply say MNA can do the same thing.  And not say there is agreement on Historic when no one knows what will be decided.
 
Suggest:
can also be achieved by MNA encapsulation, it is agreed .will be made Historic/s/can also be achieved by MNA encapsulation and, in addition, MNA will provide a broader use case applicability. The MNA encapsulation will provide an alternative, more advanced solution, when published as an RFC.
[XM]>>> The text you suggested looks good to me. As an editor of this document, I'll let the ADs and MPLS WG chairs to comment before using your text in the next revision.
 
Also - not sure if this nit was already identified – this paragraph refers to mna-fwk. Mna-fwk is listed in the references, but the references also list RFC9613, which is not cited in the document. I’d suggest switching the reference in this paragraph to RFC9613 and deleting the reference to mna-fwk.
[XM]>>> Considering RFC9613 is the first and only RFC on MNA till now, I think your suggestion is reasonable.

Cheers,
Xiao Min

Best regards,
Deborah
 
 

From: [e-mail] <[e-mail]> 
 Sent: Thursday, September 5, 2024 11:20 PM
 To: [e-mail]
 Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
 Subject: [mpls] Re: John Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)


 

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



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