Subject: Re: [Bier] Call For Adoption: draft-venaas-bier-mtud

From: Stig Venaas <[email-masked]>
Date: Tue, 12 Feb 2019 09:29:04 -0800

Hi Senthil, please see comments inline.

On Mon, Jan 28, 2019 at 2:34 AM Senthil Dhanaraj
<[email-masked]> wrote:
>
> Few concerns on, whether the proposed solution by the draft can address different scenario's and if this is the best way to go.
> Request authors to have a look.
>
> 1.  The draft already explains that the selected MTU for a path might not be the best MTU, rather a conservative one.
> Adding to that,
>
> As per the draft, the advertised MTU indicates the size of the largest BIER packet including the BIER header.
> But the size of the BIER header itself varies based on the selected BSL.
>
> If there exists a node which only supports lower BSL, say BSL=64 and advertises MTU considering BSL=64, then we force all the other nodes in the same SD which may support/choose to use bigger BSL, say BSL=256 to operate with even lesser MTU.
>
> Makes me wonder, if we should discover MTU per SD/BSL (or) advertise link MTU irrespective of L3 overhead SR/BIER.

I'm not sure if I get you. The latest version is the MTU before BIER
encap (the largest possible BIER packet including the BIER header).
Hence a router supporting only BSL 64 might advertise say 1480 because
that is the largest BIER packet that can be sent (including the BIER
header). The largest packet IP this router would send out one of those
links would be 1480 - BSL64-overhead. Another router supporting say
BSL 256, would learn about the 1480 MTU advertised, so the largest IP
packet that router would send would then be 1480 - BSL256 overhead.

> 2. How do we address below scenario,
>
> BFIR  -- BFR1 -- Non-BIER-Node -- BFR2 -- BFER
>                  <=== MPLS//SR tunnel ===>
>
> BFR1 may use a MPLS/SR tunnel to bypass the Non-BIER-Node.
> Note that,
>  - the IGP (BIER) adjacency is between (BFR1, Non-Bier-Node) and (Non-BIER-Node, BFR2).
>  - there is no IGP adjacency over the MPLS/SR tunnel used to bypass non-bier-capable-node.

Yes, this is probably something we should solve. I don't have an
answer at this point, but I'm wondering how one might find out the MTU
of this tunnel.

> 3. It is not clear , how the BIER MTU is discovered across IGP area's ?

My understanding is that with both OSPF and IS-IS BIER sub-TLVs can be
(it doesn't seem mandatory, but the text differs in the draft) can
leak between areas/levels. Whether this is done or not is regardless
of this draft. But when the BIER sub-TLVs are leaked, the MTU TLV
would be included. Which I think makes sense. The BFRs you receive
BIER TLVs from are the routers that you may encapsulate and send BIER
packets to, and for which you want to know the MTU.

Thanks,
Stig

> Thanks,
> Senthil
>
> On Fri, Jan 25, 2019 at 11:38 PM Greg Shepherd <[email-masked]> wrote:
>>
>> Please read and reply to this thread with your vote for/against adoption of:
>>
>> https://datatracker.ietf.org/doc/draft-venaas-bier-mtud/
>>
>> ..as a BIER WG document.
>>
>> This starts a two week counter.
>>
>> Thanks,
>> Chairs
>> (Shep)
>> _______________________________________________
>> BIER mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/bier
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 12 Feb 2019 09:55:25 -0800

Solid support and a good discussion.

Authors,
Please resubmit with the WG.

Thanks,
Chairs
(Shep)

On Tue, Feb 12, 2019 at 9:29 AM Stig Venaas <[email-masked]> wrote:

> > Few concerns on, whether the proposed solution by the draft can address
> different scenario's and if this is the best way to go.
> > 1.  The draft already explains that the selected MTU for a path might
> not be the best MTU, rather a conservative one.
> > Adding to that,
> >
> > If there exists a node which only supports lower BSL, say BSL=64 and
> advertises MTU considering BSL=64, then we force all the other nodes in the
> same SD which may support/choose to use bigger BSL, say BSL=256 to operate
> with even lesser MTU.
> >
> > Makes me wonder, if we should discover MTU per SD/BSL (or) advertise
> link MTU irrespective of L3 overhead SR/BIER.
>

---

From: Senthil Dhanaraj <[email-masked]>
Date: Wed, 13 Feb 2019 12:27:53 +0530

Hi Stig,

Thanks for the explanations !
My comments inline marked with Senthil//

Thanks,
Senthil

On Tue, Feb 12, 2019 at 10:59 PM Stig Venaas <[email-masked]> wrote:

> Senthil// Got you! So the BFIR needs to locally calculate the MTU to be
used for each imposition BSL using the formula (Min-SD-MTU -
FixedBierHeaderLen - BSL). Suggest consider adding text reg this to the
draft. I suppose that the BFIR also needs to consider the encapsulation
type as well during the MTU calculation. Good for now, as we have only two
encapsulation - MPLS and Non-MPLS (ETH) with both requiring the same (bier)
overhead size.

> answer at this point, but I'm wondering how one might find out the MTU

Senthil// Right. We shall discuss further on this, as it is very important
to ensure that the calculated MTU works for all the scenario's / BAR
values's.

> Senthil// Cool. Just a thought - Another way is to let the ABR advertises
the minimum MTU value of the SD (across all the area's connected to self)
as its local MTU. This might reduce some overhead (packet size, DB size,
computation).

---

From: <[email-masked]>
Date: Thu, 14 Feb 2019 10:55:14 +0800 (CST)

Hi,

It seems like I missed the adoption mail.
I support the adoption of this draft.
And I have some comments:
1, I agree with Senthil, the ABR/ASBR should advertise the MTU by BGP to ensure the correct across-area/as flow encapsulation.
2, I agree with Jingrong, a default value/behavor should be specified in the draft. If a router doesn't advertise the sub-TLV, what should other routers do?
3, In section 4/5, "The Sub-sub-TLV MUST be ignored if it is included multiple times." I am not sure I get the mean of this sentence. Does it mean that the whole sub-TLV will be ignored if more than one sub-TLV are taken? Or only the first one/ the smallest one will be used and other will be ignored?

Thanks,
Sandy

------------------原始邮件------------------
发件人：SenthilDhanaraj <[email-masked]>
收件人：Stig Venaas <[email-masked]>;
抄送人：Greg Shepherd <[email-masked]>;BIER WG <[email-masked]>;
日 期 ：2019年02月13日 16:37
主 题 ：Re: [Bier] Call For Adoption: draft-venaas-bier-mtud
_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

Hi Stig,

Thanks,
Senthil

Senthil// Got you! So the BFIR needs to locally calculate the MTU to be used for each imposition BSL using the formula (Min-SD-MTU - FixedBierHeaderLen - BSL). Suggest consider adding text reg this to the draft. I suppose that the BFIR also needs to consider the encapsulation type as well during the MTU calculation. Good for now, as we have only two encapsulation - MPLS and Non-MPLS (ETH) with both requiring the same (bier) overhead size.

Senthil// Right. We shall discuss further on this, as it is very important to ensure that the calculated MTU works for all the scenario's / BAR values's.

Senthil// Cool. Just a thought - Another way is to let the ABR advertises the minimum MTU value of the SD (across all the area's connected to self) as its local MTU. This might reduce some overhead (packet size, DB size, computation).

Thanks,
Stig
>> .as a BIER WG document.