Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Gyan Mishra <[e-mail]>]

Hi Robert

Welcome!

Responses in-line

On Thu, Apr 28, 2022 at 3:44 AM Robert Raszuk <[e-mail]> wrote:

> Hi Gyan,
>
> Many thx for your review.
>
> Comments inline.
>
>
>> How would in-situ IOAM work as the OAM data needs to be carried in the
>> packet and not encoded and flooded via the IGP Extension?
>>
>
> Nope .. not IGP. As I mentioned on this thread postcard mode works with
> RAF as is. Embedding data in the packets itself may require some container
> behind the stack. But if ever we figure out precision clock sync in WAN to
> be suitable for OAM then a separate draft can address it.
>

    Gyan> Postcard based telemetry is a  good start. I think it would be
good to have the ability to embedd the OAM data in ISD or PSD stack.

>
>
> Control plane extension in section 5 is very vague as to what Is encoded
>> in the TLVs and is it just RFA Network Actions and forwarding instructions
>> or is the data also carried in the TLV encoding which I am guessing so?
>>
>
> As mentioned control plane or management plane is not described in this
> draft. I added illustrations to how it can look like in general as this has
> impact on scaling properties of the idea.
>
>
     Gyan> Ack

>
> The RFV identifies the set of actions for a given packet but also is not
>> the IOAM data for example and sounds more like instructions similar to
>> section 5 IGP extension TLV encoding of Network Actions and Forwarding
>> instructions.
>>
>> I think the overall idea sounds good as far as intentions but still need
>> clarity on where the IOAM data is carried and is it in the RFV.  If it’s
>> not in the RFV and distributed in the control plane then I am not sure how
>> the hop by hop forwarding actions are carried out for an IOAM trace.
>>
>
> As noted by Greg one mode of trace is to generate postcard like responses.
> I would use that approach to start with.
>

       Gyan> Agreed


> As we are following similar SR IGP extension semantics could we think of
>> the label as similar to how the adjacency SID is flooded by the IGP so the
>> IOAM data encoded in a label example is similarly flooded in the IGP to all
>> nodes.
>>
>> Section 3 encoding
>>
>> LSE immediately preceding label stack entry
>> containing RFV is called Reference Forwarding Indicator.
>>
>>
>> I think you mean {TL,RFI,RFV}
>>
>>
>> NEW
>>
>>
>> LSE immediately preceding the RFV is called the Reference Forwarding Indicator.
>>
>>
> ok
>
>
>
>> RFI and RFV tuple is always of fixed size of 8 octets.  It also
>> should occur only once in a given packet.
>>
>>
>> Should that be a MUST or it would defeat the purpose of the draft to have
>> many indicators and bSPL.
>>
>
> ok
>
>
>> Section 4 processing
>>
>> Any network element can insert, delete or modify RFV or RFI-RFV tuple
>>
>> if instructed to do so by special action instructions.
>>
>>
>> That is the special action instructions distributed by the IGP or is it
>> encoded in the RFV?
>>
>
> Could be distributed by control or mgmt plane or may be a result of local
> action execution.
>
> Will clarify.
>

Gyan> Thanks
>
>
>>    If a network element understands RFI and recognizes based on the top
>>
>>    most lable value special handling requirement it MAY direct packet
>>    for special processing.  MAY or MUST processing of all requested
>>    actions (or subset of those actions) really depend on the special
>>    action instructions.
>>
>>
>> You mention that if the node understood RFI based on the topmost
>>
>> label value - do you mean RFV value proceeding  the RFI ?
>>
>>
> Nope. Here I alluded to yet one more optimization in fact applicable to
> both MNA and RAF. Top most label can give the LSR a hint to look deeper or
> not. Nothing to do with RFV or ISD.
>
> We discussed it on the list before. Perhaps I can also clarify this
> further,.
>

   Gyan>  Clarification would help. Thanks

>
>
>
>>    [Discussion point for WG: Should nodes inserting additional labels on
>>
>>    the stack for example during FRR should copy the RFI/RFV to enable it
>>    to be executed on the repair path or not ?].
>>
>>
>>        I think the PLR node at the ingress of the FRR bypass loop to the
>> MP should copy the labels so the special handle can still occur along the
>> FRR bypass path.
>>
>
> That's a valid option. Up to WG to decide if we agree to proceed fwd with
> this proposal.
>

    Gyan> Ack

>
> Thank you !
> Robert
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*