Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

["Stephane Litkowski (slitkows)" <[e-mail]>]

Well, why not doing everything in LSR and address all IGPs (OSPF only in this case) + BGP-LS ? so we ensure that there is no gap.



From: Pengshuping (Peng Shuping) <[e-mail]>
Sent: mercredi 4 novembre 2020 15:23
To: Stephane Litkowski (slitkows) <[e-mail]>; Susan Hares <[e-mail]>; [e-mail]
Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Hi Stephane,

It has been included in this draft that "[RFC7176] specifies the ISIS mechanism and extensions for link MTU Sub-TLV" which can feed BGP-LS. This was actually suggested by the LSR WG.

Regarding OSPF, people can post corresponding draft to LSR if there is a need. There could be other ways too as you mentioned.

Best regards,
Shuping

From: Idr [mailto:[e-mail]] On Behalf Of Stephane Litkowski (slitkows)
Sent: Wednesday, November 4, 2020 4:03 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Hi,

"a) Are there ways to pass IGP link MTUs in
the IGPs?  If so, is this needed in BGP-LS"

This is a valid point, most of the time BGP-LS is feeded by IGP LSDBs (of course there are other ways too). While I see that IS-IS has some MTU subTLV coming from TRILL RFC7176 (possibly never been implemented), I don't see anything for OSPF (I'm not an OSPF expert, so I may have missed it).
Shouldn't this be checked and validated with LSR WG before adopting ?


Stephane


From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Susan Hares
Sent: lundi 2 novembre 2020 06:04
To: [e-mail]<mailto:[e-mail]>
Subject: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

This begins a 2 week WG adoption call for
draft-zhu-idr-bgp-ls-path-mtu-04.txt (11/1 - 11/16/2020).

The authors should send in an IPR statement for this draft
by 11/5 so the WG can include the IPR status in their decision.

You can access the draft at:
https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/

Since this draft is reference by an existing IDR draft
I've included a bit of background below to help you place
this draft into the larger context of the SR additions to BGP-LS
and the draft-ietf-idr-tunnel-encaps-19.txt.

This draft does continue BGP-LS additions.  if you
are opposed to any BGP-LS additions rather than
this specific addition, please make that clear in your
comment in this discussion.

The authors requested a WG adoption at IETF 108.
The IDR co-chairs thank the authors for their patience.
This draft has been delayed by process of having a
new document shepherd (Sue Hares) come up to speed
on draft-ietf-idr-tunnel-encapsulation.

Cheers, Sue

Background
===========
Segment Routing technology creates SR tunnels that are
directly overlaid on MPLS or SRv6.  While existing MPLS technology
(LDP and RSV-TE) provides mechanisms to negotiate path MTU
based on individual link MTU limits, the Segment Routing (SR)
on BGP-LS Link Attribute does not pass information on
MTU size per link.

draft-ietf-idr-sr-policy-path-mtu-02.txt sends PATH MTU
information in the tunnel-encapsulation attribute for the tunnel type
SR-Policy that handles segment routing (SR) paths.
However, it lacks the information to create a reasonable
Path size since the BGP-LS Link Attribute does distribute
this information.

The draft proposes adding a new sub-TLV for MTU size
to the BGP-LS Link Attribute TLV, and
draft-ietf-idr-sr-policy-path-mtu-02.txt mentions this
draft as one possible way to distribute the per link
MTU.

Questions for the authors might be:
a) Are there ways to pass IGP link MTUs in
the IGPs?  If so, is this needed in BGP-LS

b) What other mechanisms pass link MTU?