Subject: Re: [mpls] Comment on draft-gandhi-mpls-ioam-sr-05

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 18 Feb 2021 18:45:23 -0500

Hi Xiao, Loa,
FYI:
I believe the latest revision (06) addresses this comment.
https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-06

Thanks for your review.
Regards,
Rakesh

On Mon, Jan 18, 2021 at 9:15 AM Rakesh Gandhi <[email-masked]>
wrote:

> Hi Loa, Xiao,
>
> Please see reply inline with <RG>..
>
> On Mon, Jan 18, 2021 at 3:44 AM <[email-masked]> wrote:
>
>> Hi Loa,
>>
>> Please see inline my responses with <XM>.
>>
>> Best Regards,
>> Xiao Min
>> 原始邮件
>> *发件人：*LoaAndersson
>> *收件人：*肖敏10093570;
>> *抄送人：[email-masked];
>> *日 期 ：*2021年01月18日 16:01
>> *主 题 ：**Re: [mpls] Comment on draft-gandhi-mpls-ioam-sr-05*
>> Xiao,
>>
>> I have not been active in any OAM work, and not in the iOAM development,
>>
>> so I'm on a learning curve. So one more question.
>> <XM> It's my pleasure if I can help here.
>>
>> Inline please
>>
>>
>> On 18/01/2021 10:00, [email-masked] wrote:
>> > If I understand this correctly that is what is done by Hop-by-Hop IOAM.
>> > <XM> Per IOAM itself, the Edge-to-Edge IOAM and Hop-by-Hop IOAM are
>> > independent of each other, they use different IOAM Option-Type. Per MPLS
>>
>> > indicator label, I agree with you that Hop-by-Hop IOAM indicator label
>> > can be reused here, but IMHO the current text in this draft is not clear
>>
>> > on it.
>>
>> Let us assume that a packet arrive to an egress node with (1) with an
>> e-2-e iOAM indicator and another packet (2) arrive with the hop-by-hop
>> indicator.
>>
>> Is there a difference t0 what the egress node do to (1) and what it does
>>
>> to (2)?
>> <XM> As I understand it, there is no difference. Here the only function
>> of iOAM indicator is for the egress node to know there exists IOAM header
>> below the MPLS label stack, and how to process the IOAM data fields within
>> the IOAM header depends on IOAM Option-Type.
>>
>
> <RG> Yes, this is my understanding as well.
>
> Thanks,
> Rakesh
>
>
>
>>
>>
>> /Loa
>>
>> --
>>
>> Loa Andersson                        email: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Bronze Dragon Consulting             phone: +46 739 81 21 64
>>
>>
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 18 Feb 2021 18:55:25 -0500

Hi Stewart,
FYI:
I believe Section 7 in latest revision (06) addresses this comment. Welcome
your feedback on that.
https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-06

Thanks for your review.
Regards,
Rakesh

On Tue, Jan 12, 2021 at 9:24 AM Stewart Bryant <[email-masked]>
wrote:

> There are three problems, how you encode the action and where you place
> the metadata, and how you accommodate anything else after BoS.
>
> This is getting very messy and we need to solve this holistically or we
> will damage the future of the MPLS protocol.
>
> The best place to indicate HxH is at ToS since this is looked at by every
> hop with minimum effort.
>
> This could be via a FEC or an SPL. However I do not like the SPL approach
> because you probably need the EL to neutralise ECMP and that is four labels
> in the stack  before you even get to specify the destination. That is as
> many labels as some LSRs can cope with. You could I suppose have an iOAM
> SPL that specifies the ECMP behaviour but we are loosing our generality if
> we go down that route.
>
> The best place to indicate E2E is at BoS since this is where you handle
> the E2E iOAM. That can be an ordinary label, and since you have to
> advertise E2E iOAM capability it is not much more to specify which label
> you expect to see BoS to indicate its presence.
>
> Now you have two choices to advertise both, - the ToS stuff which you do
> not PHP + the BoS, or one of two different BoS labels. The use of two
> different BoS labels is far less problematic since that is only 2 out of
> million available labels and you need the label in place to indicate that
> the packet carries E2E iOAM and not just plain IP … except that it may not
> carry plain IP...
>
> Now here is what worries me.
>
> What if the LSP is carrying a PW, or is DetNet? What if it is a MS-PW? In
> all these cases there is a CW immediately after BoS. Then there is the
> universal fragmentation idea that is floating about that also wants to
> follow BoS.
>
> How do we fit in 2, possibly 3 or 4 sets of descriptor data after the BoS.
> This has the possibility to get very messy very quickly.
>
> So we need to go up a level and consider how we generalise this, because
> iOAM needs to live with the rest of the MPLS ecosystem, and will not be the
> only candidate for BoS meta data. That is not to say that I have anything I
> want to put there that I am being quiet about, instead it is to point out
> that once the first genie is out of the bottle a whole bunch of their
> friends will soon follow behind. So we have to solve this elegantly such
> that we can deal with the MPLS extensions we have not yet thought of and
> not be tempted to just hack something in that works for the immediate case
> in hand.
>
> - Stewart
>
>