I support WG adoption and agree Ketan’s doc is good start. On Mon, Nov 16, 2020 at 5:38 AM Jeff Tantsura <[email protected]> wrote:
> Sue, > > Ketan’s draft would be a great starting point. > > Regards, > Jeff > > On Nov 16, 2020, at 00:04, Ketan Talaulikar (ketant) <[email protected]> > wrote: > > > > Hi Sue, > > > > I was referring to > https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ > > > > Seeing the interest in the WG to progress BGP-LS advertisements in > BGP-only networks, I would request for the WG to consider adoption of the > above draft. I believe the problem statement of the draft is clear and > acknowledge that it needs updates. So I will leave it to the chairs’ > judgement if it is in a good enough state for adoption 😊 > > > > Thanks, > > Ketan > > > > *From:* Susan Hares <[email protected]> > *Sent:* 16 November 2020 11:40 > *To:* 'Jeff Tantsura' <[email protected]>; Les Ginsberg (ginsberg) < > [email protected]> > *Cc:* Ketan Talaulikar (ketant) <[email protected]>; Stephane Litkowski > (slitkows) <[email protected]>; [email protected]; Acee Lindem (acee) < > [email protected]>; [email protected] > *Subject:* RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu > (11/1/2020 to 11/16/2020) > > > > Jeff: > > > > I agree your BGP-LS only deployment in the MSD document were not well > defined. > > > > Starting a new set of work to define BGP-LS use in BGP-only is important. > If this document start the process to refine how BGP-only works, this will > help defined this usage. I stand by the agreement that the BGP-LS that > exposes the OSPF/ISIS Link MTU proposal can be adopted in LSR. However, > this discussion has confirmed that the BGP-LS support for BGP-only needs > some BGP focus. > > > > If there are other drafts on this topic, it would be good to suggest this > drafts on the list. Ketan suggested he had one. > > > > Cheers, Sue > > > > > > *From:* Jeff Tantsura [mailto:[email protected] > <[email protected]>] > *Sent:* Friday, November 13, 2020 8:52 PM > *To:* Les Ginsberg (ginsberg) > *Cc:* Ketan Talaulikar (ketant); Susan Hares; Stephane Litkowski > (slitkows); [email protected]; Acee Lindem (acee); [email protected] > *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu > (11/1/2020 to 11/16/2020) > > > > To add to Les’s point of BGP only scenario, during MSD IESG reviews, > BGP-LS only deployment was found not well characterized and had been > removed from the draft. It will require much better discussion to have it > included. > > Regards, > > Jeff > > > > On Nov 13, 2020, at 15:57, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > > > The points which Ketan has made regarding the use of MTU advertisements > defined in RFC 7176 are very valid. Indeed, the contents of the sub-TLV > defined in https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend > upon the TRILL specific MTU-probe/MTU-ack procedures defined in > https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures > are not currently applicable to non-TRILL environments. > > > > So, there are no existing IGP advertisements defined which can support the > goals of this draft. > > > > As Ketan has also indicated, there is no discussion in the draft of how a > BGP only network (for example) could provide the information of interest. > > > > From my perspective, WG adoption of this draft in ANY WG is premature. > > This might be a useful functionality to have – but at the moment we simply > have an idea with no definition of how to implement/deploy it. > > > > So I therefore oppose WG adoption of this draft by IDR. > > > > Continuing the discussion is certainly useful – and I would encourage the > current authors to investigate and propose relevant mechanisms in all the > protocols of interest in some future version of the draft. > > At that point we could then have a far more meaningful WG adoption call. > > > > Les > > > > > > *From:* Idr <[email protected]> *On Behalf Of *Ketan Talaulikar > (ketant) > *Sent:* Friday, November 13, 2020 1:35 AM > *To:* Susan Hares <[email protected]>; 'Jeff Tantsura' < > [email protected]>; 'Stephane Litkowski (slitkows)' < > [email protected]>; [email protected]; 'Acee Lindem (acee)' < > [email protected]> > *Cc:* [email protected] > *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu > (11/1/2020 to 11/16/2020) > > > > Hi Authors, > > > > I believe this work is useful and should be taken up. It has value in > providing the link MTU as part of the topology information via BGP-LS. > However, as pointed out by others on this thread, the draft should remain > scoped to just that – i.e. providing link MTU information. The discussion > related to Path MTU and applicability to SR networks are best left outside > the scope of this standards track draft. > > > > Hi Sue, > > > > I would support the points made by Acee for not taking up this draft in > IDR WG and instead doing this in LSR. > > > > Besides the missing coverage for OSPFv2/v3, there are also issues with how > this would work with ISIS. The reference to the ISIS Trill specification > points to this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if > you see, there is more here than just the MTU value. What is more critical > is the ISIS procedures (in non-Trill deployments) on how this value is > determined. Please do not mix the following : > > > > The MTU sub-TLV is used to optionally announce the MTU of a link as > > specified in [RFC6325], Section 4.2.4.4 > <https://tools.ietf.org/html/rfc6325#section-4.2.4.4>. > > > > Are the authors trying to specify that these Trill procedures for testing > MTU need to be adopted for regular ISIS deployments. > > > > My take is that while the ISIS TLV defined for Trill may be re-used in > normal ISIS deployments, its usage and procedures need to be specified. > Copying the LSR WG so that I may be corrected if I am wrong here. > > > > Coming to the point of BGP-only networks, the draft has zero text related > to that scenario. Moreover, the procedures for BGP-LS advertisements in BGP > only fabric need to be specified as a base. The > https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ > was my attempt to specify those procedures and it would be great if the IDR > WG could review and provide feedback to this document and consider for > adoption so we can cover the BGP-only networks. > > > > I would also like to offer support/help to the authors in adding the > necessary OSPFv2/v3 support for the same in an LSR draft where we could > tackle both the IGPs and BGP-LS encoding and procedures together. > > > > Thanks, > > Ketan > > > > *From:* Idr <[email protected]> *On Behalf Of *Susan Hares > *Sent:* 13 November 2020 00:20 > *To:* 'Jeff Tantsura' <[email protected]>; 'Stephane Litkowski > (slitkows)' <[email protected]>; [email protected]; 'Acee > Lindem (acee)' <[email protected]> > *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu > (11/1/2020 to 11/16/2020) > > > > 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:[email protected] > <[email protected]>] > *Sent:* Thursday, November 12, 2020 12:53 PM > *To:* Susan Hares; Stephane Litkowski (slitkows); [email protected]; 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) < > [email protected]>, 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 <[email protected]> on behalf of Susan Hares < > [email protected]> > *Date:* Monday, November 9, 2020 at 4:20 PM > *To:* "'Stephane Litkowski (slitkows)'" < > [email protected]>, IDR List <[email protected]> > *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:[email protected] <[email protected]>] *On > Behalf Of* Stephane Litkowski (slitkows) > *Sent:* Monday, November 9, 2020 4:28 AM > *To:* Susan Hares; [email protected] > *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 <[email protected]> > *Sent:* lundi 9 novembre 2020 10:10 > *To:* Stephane Litkowski (slitkows) <[email protected]>; [email protected] > *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:[email protected] > <[email protected]>] > *Sent:* Wednesday, November 4, 2020 3:03 AM > *To:* Susan Hares; [email protected] > *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 <[email protected]> *On Behalf Of* Susan Hares > *Sent:* lundi 2 novembre 2020 06:04 > *To:* [email protected] > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
