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

Hi,

The plan looks solid. I support this work in whichever form it takes.

Perhaps a good idea to state the BGP-only case in section 3.

Some other minor suggestions -

- Expand on first use: SDN, PCEP, SRH, NLRI,
- Update to RFC 8174 requirement language (from RFC 2119)
- Section 3, s/to carry maximum transmission unit (MTU) messages./to carry
MTU in BGP-LS messages./
- s/BGP_LS/BGP-LS/
- Figure 2, add a bit numbering on the top otherwise the figure is not that
useful.

Thanks!
Dhruv

On Fri, Nov 13, 2020 at 12:21 AM Susan Hares <shares@ndzh.com> wrote:

> Jeff and Authors of draft-zhu-idr-bgp-ls-path-mtu:
>
>
>
> I do believe the authors agreed to renaming the draft.
>
>
>
> Does the name:   draft-xxx-idr-bgp-ls-link-mtu work for
>
> the authors and interested IDR participants.
>
>
>
> As the end of 12 days of the 14 day WG LC, this draft appears
>
> to have general consensus from the WG as a useful draft.
>
>
>
> I plan to allow 2 more days of comment, but at this point
>
> it appears the WG wishes to adopt this draft.
>
>
>
> Here’s my understanding of the best way forward:
>
>
>
> If LSR adopts a version of the draft, IDR will allow the
>
> LSR WG to be the main source as long as cross-working
>
> review occurs so the BGP-only function can be reviewed.
>
>
>
> Please continue to comment on the draft and
>
> the planned progression.
>
>
>
> Cheers,  Sue
>
>
>
> *From:* Jeff Tantsura [mailto:jefftant.ietf@gmail.com]
> *Sent:* Thursday, November 12, 2020 12:53 PM
> *To:* Susan Hares; Stephane Litkowski (slitkows); idr@ietf.org; Acee
> Lindem (acee)
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> +1 to everything Acee said
>
>
>
> Cheers,
>
> Jeff
>
> On Nov 10, 2020, 1:01 PM -0800, Acee Lindem (acee) <acee=
> 40cisco.com@dmarc.ietf.org>, wrote:
>
> Speaking as an IDR WG member:
>
>
>
> The name of the draft is wrong – the extension is for a Link MTU and not a
> path MTU.
>
>
>
> Speaking as LSR Chair:
>
>
>
> We could this in LSR as there is currently no MTU advertisement in the
> LSAs for OSPFv2 and OSPFv3. Implementations already make use of this
> information as it is used in the OSPF DBD packets and for LSA packing. Of
> course, we’d require a more accurate draft name and title.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From:* Idr <idr-bounces@ietf.org> on behalf of Susan Hares <
> shares@ndzh.com>
> *Date:* Monday, November 9, 2020 at 4:20 PM
> *To:* "'Stephane Litkowski (slitkows)'" <slitkows=
> 40cisco.com@dmarc.ietf.org>, IDR List <idr@ietf.org>
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Stephane:
>
>
>
> My second message to this thread asked a few questions about the
> technology.
>
>
>
> This information can be more than IGP information.   If SR segments
> statically defined (static or direct interfaces) tunnels and pass the
> endpoints via BGP tunnel-encaps draft with SR Policy tunnel type, this can
> just be BGP.
>
>
>
> I’ll keep this WG adoption call going until we can be sure if:  1) it
> something LSR wants to standardize, and 2) whether there is a BGP only
> case.   It is clear to me that standardizing MTU for a SR segments with
> stacked tunnel segments passed by BGP was useful.
>
>
>
> The authors should be the ones to propose this in LSR.
>
>
>
> Cheers,  Sue
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of* Stephane
> Litkowski (slitkows)
> *Sent:* Monday, November 9, 2020 4:28 AM
> *To:* Susan Hares; idr@ietf.org
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Hi Sue,
>
>
>
> > The purpose behind this mechanism is to reduce administrative work
> rather than to reduce the review on drafts.
>
>
>
> That’s exactly my point. If we don’t do OSPF extension now and in the same
> draft, we leave a gap that will require a new draft for a very very small
> extension. Just adds process overhead for nothing…
>
>
>
>
>
> Stephane
>
>
>
>
>
> *From:* Susan Hares <shares@ndzh.com>
> *Sent:* lundi 9 novembre 2020 10:10
> *To:* Stephane Litkowski (slitkows) <slitkows@cisco.com>; idr@ietf.org
> *Subject:* RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Stephane:
>
>
>
> I want to pick up on your email from two points:
>
>
>
> 1)  Why not do everything in LSR?
>
> <WG-chair hat>
>
> If the feature comes with interest in doing all 3 (ISIS, OSPF, and BGP-LS
> data gathering), then the authors may select to do everything in LSR rather
> than have 2 or 3 drafts to maintain.
>
>
>
> This is optional and the mechanism may not fit every draft.   The drafts
> may also start out adopted and vetted in LSR and IDR.    The purpose behind
> this mechanism is to reduce administrative work rather than to reduce the
> review on drafts.
>
>
>
> </wg-chair hat off>
>
>
>
>
>
> 2) TRILL implementations of IS-IS has some MTU subTLV -
>
>
>
> If you are interested in whether this has been implemented in TRILL, you
> might want to check with Donald Eastlake.   My vague and foggy recollection
> is that had some implementations or came from pre-TRILL implementations.
>
>
>
>
>
> Cheers, Susan Hares
>
>
>
>
>
>
>
> *From:* Stephane Litkowski (slitkows) [mailto:slitkows@cisco.com
> <slitkows@cisco.com>]
> *Sent:* Wednesday, November 4, 2020 3:03 AM
> *To:* Susan Hares; idr@ietf.org
> *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 <idr-bounces@ietf.org> *On Behalf Of* Susan Hares
> *Sent:* lundi 2 novembre 2020 06:04
> *To:* idr@ietf.org
> *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?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>