Re: [Bier] draft-ietf-bier-oam-requirements-00: PMTUD requirement in BIER OAM Requirements

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

Inline.

On Sun, Nov 08, 2015 at 06:04:04AM +0000, Gregory Mirsky wrote:
> If we intend to support PMTUD for BIER, it should be accordingly described, but not as an OAM operation. If it's meant as an offline OAM operation, thats a different discussion.
> GIM>> I don't know what you mean by "offline OAM". The PMTUD proposed as on-demand OAM operation that can be triggered by an operator or central controller. I don't see the need or benefit of running PMTUD as proactive OAM.

Yes, that's what i meant with the somewhat bad term "offline". Thats well in scope for OAM.
But i would really like some better use-case justification for this. How does it compare
to eg: MPLS. 


> If we ignore IP multicast and just think about end-to-end BIER, the picture changes somewhat. We do know explicitly know the set of receivers, and its < 64k. But: One key benefit of BIER is the ability to change the set of receivers WITHOUT SIGALING. If we where to do probing based PMTUD in BIER, we would loose this benefit of BIER.
> GIM>> As discussed at the meeting, one may list any subset of BFIRs in the given domain. I don't see what gets lost with such flexibility.

I was referring to the case where we would do MTUD for the application itself as
opposed to doing it purely as an OAM operation from somee operator console.
Eg: if we ever consider MTUD automatic for apps, then it should be proactive as
eg: via IGP so that a sender tht changes receiver bits does not have do do 
any signaling aat that time but immediately knows the MTU for that new receiver set.

> GIM>> AFAIK, "proactive OAM" usually identifies an operation that is continuous. Do you suggest to run the PMTUD continuously with some intervals? Haven't thought about benefit of this mode though the PMTUD method would not preclude one from using it in this manner.

I was thinking of just announcing per-link MTU into the IGP (or whatever routing protocol
BIER routing underlay relies on). Of course, the per-hop MTU could be discovered
through per-hop probing if there is reason not to simply believe interface configured MTU.

Cheers
    Toerless

> Or just calculating network-wide min-MTU from link-MTU in the IGP.
> 
> But: Use-case wise i really don't know how important this is. Ultimately, this is not a different problem to MPLS: You do not want to do fragmentation, so you want to send with a sufficiently small MTU, so well controlled networks (MPLS, BIER) will get configured with the right MTU. And applications written for IP in mind will not use MTU > 1280 anyhow.
> 
> The best case i can think of for BIER is that we get a strong use-case that shows well improved throughput for jumbo-packets, and we see sufficient benefits for auto-configuration of that jumbo-packet MTU for end-to-end BIER.
> 
> The use case Caitlin Bessler told me about might fit this profile.
> To make it reliable in a DC it would probably want to discover MTU, and to be highest throughput it might want to use jumbo packets (8192 at least).
> 
> Aka: As long as i don't see different use-case descriptions, i'd primarily be only interested in MTU > 1280 for end-to-end BIER in this DC network storage use-case environment.
> 
> Cheers
>     Toerless
> 
> On Fri, Nov 06, 2015 at 10:48:08AM +0000, Gregory Mirsky wrote:
> > Hi Toerless,
> > perhaps I wasn't clear at the mike today. PMTUD is clearly not for OAM but it is OAM service to determine OAM on particular path (the same as PMTUD in p2p, right?). I believe that the fact that PMTUD over multicast in MPLS or IPv4/IPv6 doesn't scale is another indication of advantage BIER technology presents us with.
> > I'll be glad to continue our discussion on the list.
> > 
> > 	Regards,
> > 		Greg
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Friday, November 06, 2015 1:29 PM
> > To: Gregory Mirsky
> > Cc: BIER ([e-mail])
> > Subject: draft-ietf-bier-oam-requirements-00: PMTUD requirement in 
> > BIER OAM Requirements
> > 
> > Thanks, Greg.
> > 
> > I was looking just for PMTU or MTU in the text and could not find it.
> > 
> > I do not agree to this requirement in the OAM requirement draft as of now.
> > 
> > Why is it needed for BIER ? AFAIK, there is no PMTUD for OAM in any of the prior IP multicast transport options - native IP or MPLS. True ?
> > Any reason why BIER would need this more than those prior options ?
> > Any reason why BIER would make it a lot easier  than the prior options ?
> > 
> > This should IMHO be discussed in the draft.
> > 
> > If we get PMTUD, would it only be for OAM and only for the BIER path, eg:
> > not the end-to-end path ? If so, it should be called different (BP-MTUD or the like). 
> > 
> > If someone proposes that it should be end-to-end, then this needs to go back to MBoned, because it would ask to introduce PMTUD into eg: PIM path segments.
> > 
> > Wrt. the protocols proposed in your PMTUD draft proposal: I would like to understand why we would not want to proactively signal MTU intead of probing it. There seems to have been some work in the past around this in unicast, not sure how successful.
> > 
> > Cheers
> >     Toerless
> > 
> > On Fri, Nov 06, 2015 at 01:02:10AM +0000, Gregory Mirsky wrote:
> > > Hi Toerless,
> > > I'd like to bring requirement #9 in the BIER WG document OAM Requirements for BIER<https://tools.ietf.org/html/draft-ietf-bier-oam-requirements-00>:
> > > BIER OAM MUST support Path Maximum Transmission Unit discovery.
> > > Hope that addresses your question why are we doing PMTUD.
> > > 
> > >                 Regards,
> > >                                 Greg
> 
> --
> ---
> Toerless Eckert, [e-mail]

-- 
---
Toerless Eckert, [e-mail]