Re: [mpls] MPLS-RT review of draft-hegde-mpls-spring-epe-oam

[Shraddha Hegde <[e-mail]>]

Hi Bocci,

Thanks for the review and comments.

-----Original Message-----
From: Bocci, Matthew (Nokia - GB) <[e-mail]> 
Sent: Monday, March 2, 2020 3:48 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Hello

I have been selected as an MPLS Review Team reviewer for this draft.

I found the document to be clear, well-written and coherent. It does address a problem that needs to be solved.

One technical comment that I have is that the document relies on the ingress LER launching the LSP Ping/Trace knowing the type of every SID along the path of the LSP in order to use the correct TLV in the target FEC stack. This presents a challenge for SR Policy because the path is just a list of SID labels with no type explicitly provided in the definition of the policy. 
<Shraddha> head-end node can also use BGP-LS with ASBR to learn the EPE-SIDs and the FEC can be built .
"Theory of operation" section talks about this.
I will add absence of the SID details in PCEP and BGP-SR-TE extensions and that being out of scope of this draft. 

This is slightly less of a problem in the case of RFC8287 because the head end node at least knows the details of the top SID.  In the case of EPE SIDs, a controller may learn these downstream SIDs though BGP-LS, 

but they are not learned directly by the head end node. 

<shraddha> head-end can also learn via BGP-LS sessions to ASBRs.

The controller may or may not provide SID types to the node, but it is not clear what mechanism is available to do this. The draft rather side steps this issue and only provides the following guidance in section 2: "The node initiating the data plane monitoring may acquire the details of EPE-SIDs through BGP-LS advertisements...".  This statement should contain more detail about how this works (given that it is the controller that learns though BGP-LS), and what alternatives exist if the controller does not provide the SID types to the initiating node e.g. use of a NIL FEC type. An alternative would be to be more explicit that this is a gap which is out of scope of this draft and explicitly state that the mechanism that the initiating node learns the details of the EPE SIDs is out of scope. 
<shraddha> I'll add text that other mechanisms of learning SID details from controller may be used and it is out of scope for this draft.

Best regards

Matthew


 
[e-mail] <[e-mail]>

On 14/02/2020, 04:52, "Loa Andersson" <[e-mail]> wrote:

    Mathew, Sam, Sasha and Italo,
    
    You have be selected as MPLS-RT reviewers for
    draft-hegde-mpls-spring-epe-oam.
    
    Note to authors: You have been CC'd on this email so that you can know
    that this review is going on. However, please do not review your own
    document.
    
    Reviews should comment on whether the document is coherent, is it
    useful (ie, is it likely to be actually useful in operational
    networks), and is the document technically sound?  We are interested
    in knowing whether the document is ready to be considered for WG
    adoption (ie, it doesn't have to be perfect at this point, but should be
    a good start).
    
    Reviews should be sent to the document authors, WG co-chairs and
    WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
    may be sent privately to only the WG chairs.
    
    If you have technical comments you should try to be explicit about what
    *really* need to be resolved before adopting it as a working group
    document, and what can wait until the document is a working group
    document and the working group has the revision control.
    
    Are you able to review this draft by Feb 28, 2020? Please respond in a
    timely fashion.
    
    
    Thanks, Loa
    (as MPLS WG chair)
    -- 
    -- 
    
    
    Loa Andersson                        email: [e-mail]
    Senior MPLS Expert
    Bronze Dragon Consulting             phone: [phone]