Subject: [pim] Comment on draft-lts-pim-hello-mtu?

From: Tina TSOU <[email-masked]>
Date: Thu, 5 Apr 2012 20:44:54 +0000

Dear all,
May the author of draft-lts-pim-hello-mtu ask people to read the draft and provide comments?

http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/

Thank you in advance.

Best Regards,
Tina TSOU

---

From: Stig Venaas <[email-masked]>
Date: Mon, 09 Apr 2012 11:01:39 -0700

> http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/

See the minutes I just posted if you like.

My main comment is that MTU is important for other protocols too,
and also for traffic/data, so I'm wondering if it would be better
to do it with some more general protocol. Maybe BFD or in the IGP?
For IPv6 one could perhaps use RAs?

Stig

>
>
> Best Regards,
> Tina TSOU
>
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Tina TSOU <[email-masked]>
Date: Mon, 9 Apr 2012 18:17:11 +0000

Tina

> -----Original Message-----
> From: Stig Venaas [mailto:[email-masked]]
> Sent: Monday, April 09, 2012 11:02 AM
> To: Tina TSOU
> Cc: [email-masked]
> Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu?
> 
> My main comment is that MTU is important for other protocols too, and
> also for traffic/data, so I'm wondering if it would be better to do it
> with some more general protocol. Maybe BFD or in the IGP?
Which WG does IGP belong to?

---

From: Liuhui <[email-masked]>
Date: Tue, 10 Apr 2012 11:06:30 +0000

Hi Stig,

Thanks for the comments. I also introduce the points in minutes below for discussion.

Thanks,
Liu Hui

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stig Venaas
> Sent: Tuesday, April 10, 2012 2:02 AM
> To: Tina TSOU
> Cc: [email-masked]

> See the minutes I just posted if you like.

"Stig: Useful if there are msiconfigurations or asymmetric MTUs for routers on a link. But not just a PIM problem."
[LH] Agree. E.g. OSPF also has MTU option carried in its Database Description packet. 
 
"Bill: If you are using MTU for control packets you may be able to send good control packets but if the data packets are still too big, this could be a bad thing. We need to make sure that this isn't a bad thing and explain it"

[LH] Accepted. Could we explain it in this way: the control and data plane are run independently. The control plane makes sure that forwarding paths are setup even though there exists asymmetric MTUs. Even though some data packets exceeding MTU limitation of some point of paths cannot be processed properly, other packets in scope will be normally forwarded and delivered. And it's up to first-hop or head- end to determine the length of a data packet, with other measures such as PMTU.

"Dino: Population count helps because you can drop the packets at the first hop router."
[LH]Pop count is a PMTU-like method, which should deal with data packet.

> My main comment is that MTU is important for other protocols too,

[LH] It's important for protocol between its adjacent peers when they have to exchange volumes of data, such as PIM Join with large amounts of group states, and OSPF Database Description carrying all link-states during initialization.

> and also for traffic/data, 
[LH] I suppose PMTU-like methods are more applicable for traffic/data, while for PIM and OSPF the key issue is between two adjacent hops where messages often having to be segmented. They are for different purpose and should use different measures

> so I'm wondering if it would be better

[LH] Good points. Please see my considerations:
    For per-hop MTU here there are two steps implied, i.e., how PIM acquires its peer MTU info, and how it uses it. The first step has the possibility to be generalized, and the second is somewhat protocol specific
    Then does this 'generalization' mean BFD or IGP or RA? As PIM is protocol independent, we cannot assume it always run with IGP. So IGP might be not a good option for generalization. 
    RA has already had MTU option there, but it's for use for the nodes not the routers. Even if the router takes the role of a node, there are no explicit peer and one common MTU is taken for all nodes in RA case, which is different from the PIM one. And RA is applicable to only IPv6 network.
    BFD is more general. Should it be extended as here to cover most protocols? It is not impossible, but the precondition is every protocol expects the same information from the common structure maintained by BFD. It deserves it if the number of protocols having this control message segmenting requirement is not small.
    PIM extension is proposed because there is no common structure available right now, and promoted by resolving the current network issues. It can be applied to both IPv4 and IPv6 networks, and doesn't mind whether IGP or BFD is running or not.

---

From: Chiranjeevi Ramana Rao <[email-masked]>
Date: Tue, 17 Apr 2012 08:32:05 +0200

Hello 
  I second Stig on this, MTU problem mentioned here is general problem. This draft is proposing solution for PIM. IGMPv3 also will have same problem right?
  It is not good idea to solve MTU problem per protocol. It will be nice, if a general solution is found for this problem.
Thanks
Chiranjeevi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Liuhui
Sent: Tuesday, April 10, 2012 4:37 PM
To: Stig Venaas; Tina TSOU
Cc: [email-masked]; [email-masked]
Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu?

Hi Stig,

Thanks,
Liu Hui

> > May the author of draft-lts-pim-hello-mtu ask people to read the 
> > draft
> and provide comments?
> >

---

From: Liuhui <[email-masked]>
Date: Tue, 17 Apr 2012 10:03:14 +0000

Hi,

For IGMPv3, do you mean when it is running between a host and a router? Then it is quite different from what is resolved by this draft.

PIM specific processing also has its benefits, as explained below. General solution is not impossible, but it's better we collect enough use cases before we decide to turn to that direction.

Thanks,
Liu Hui

> 
> Hello
>   I second Stig on this, MTU problem mentioned here is general problem.
> This draft is proposing solution for PIM. IGMPv3 also will have same
> problem right?
>   It is not good idea to solve MTU problem per protocol. It will be nice, if a
> general solution is found for this problem.
> Thanks
> Chiranjeevi
> 
> 
> Liuhui
> "Bill: If you are using MTU for control packets you may be able to send good
> control packets but if the data packets are still too big, this could be a bad
> thing. We need to make sure that this isn't a bad thing and explain it"
> 
> [LH] Accepted. Could we explain it in this way: the control and data plane
> are run independently. The control plane makes sure that forwarding paths
> are setup even though there exists asymmetric MTUs. Even though some
> data packets exceeding MTU limitation of some point of paths cannot be
> processed properly, other packets in scope will be normally forwarded and
> delivered. And it's up to first-hop or head- end to determine the length of a
> data packet, with other measures such as PMTU.
> 
> [LH] It's important for protocol between its adjacent peers when they have
> to exchange volumes of data, such as PIM Join with large amounts of group
> states, and OSPF Database Description carrying all link-states during
> initialization.
> 
> [LH] I suppose PMTU-like methods are more applicable for traffic/data,
> while for PIM and OSPF the key issue is between two adjacent hops where
> messages often having to be segmented. They are for different purpose and
> should use different measures
> 
>     For per-hop MTU here there are two steps implied, i.e., how PIM
> acquires its peer MTU info, and how it uses it. The first step has the
> possibility to be generalized, and the second is somewhat protocol specific
>     Then does this 'generalization' mean BFD or IGP or RA? As PIM is
> protocol independent, we cannot assume it always run with IGP. So IGP
> might be not a good option for generalization.
>     RA has already had MTU option there, but it's for use for the nodes not
> the routers. Even if the router takes the role of a node, there are no explicit
> peer and one common MTU is taken for all nodes in RA case, which is
> different from the PIM one. And RA is applicable to only IPv6 network.
>     BFD is more general. Should it be extended as here to cover most
> protocols? It is not impossible, but the precondition is every protocol
> expects the same information from the common structure maintained by
> BFD. It deserves it if the number of protocols having this control message
> segmenting requirement is not small.
>     PIM extension is proposed because there is no common structure
> available right now, and promoted by resolving the current network issues.
> It can be applied to both IPv4 and IPv6 networks, and doesn't mind whether
> IGP or BFD is running or not.
> 
> >
> > Stig
> >
> > >
> > >
> > > Best Regards,
> > > Tina TSOU
> > >
> > >