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

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 13 Nov 2020 09:34:46 +0000

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-masked]> On Behalf Of Susan Hares
Sent: 13 November 2020 00:20
To: 'Jeff Tantsura' <[email-masked]>; 'Stephane Litkowski (slitkows)' <slitkows=[email-masked]>; [email-masked]; 'Acee Lindem (acee)' <acee=[email-masked]>
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-masked]]
Sent: Thursday, November 12, 2020 12:53 PM
To: Susan Hares; Stephane Litkowski (slitkows); [email-masked]<mailto:[email-masked]>; 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=[email-masked]<mailto:acee=[email-masked]>>, 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-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 9, 2020 at 4:20 PM
To: "'Stephane Litkowski (slitkows)'" <slitkows=[email-masked]<mailto:slitkows=[email-masked]>>, IDR List <[email-masked]<mailto:[email-masked]>>
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-masked]] On Behalf Of Stephane Litkowski (slitkows)
Sent: Monday, November 9, 2020 4:28 AM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>>
Sent: lundi 9 novembre 2020 10:10
To: Stephane Litkowski (slitkows) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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-masked]]
Sent: Wednesday, November 4, 2020 3:03 AM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>> On Behalf Of Susan Hares
Sent: lundi 2 novembre 2020 06:04
To: [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 13 Nov 2020 23:57:47 +0000

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-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'Stephane Litkowski (slitkows)' <slitkows=[email-masked]>; [email-masked]; 'Acee Lindem (acee)' <acee=[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Hi Authors,

Hi Sue,

Thanks,
Ketan

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Susan Hares
Sent: 13 November 2020 00:20
To: 'Jeff Tantsura' <[email-masked]<mailto:[email-masked]>>; 'Stephane Litkowski (slitkows)' <slitkows=[email-masked]<mailto:slitkows=[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Acee Lindem (acee)' <acee=[email-masked]<mailto:acee=[email-masked]>>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Cheers,  Sue

Cheers,
Jeff

Speaking as LSR Chair:

Thanks,
Acee

Stephane:

Cheers,  Sue

Hi Sue,

Stephane

Stephane:

</wg-chair hat off>

Cheers, Susan Hares

Hi,

Stephane

Cheers, Sue

Background
===========

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 13 Nov 2020 17:52:10 -0800

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-masked]> wrote:
> 
> 
>    specified in [RFC6325], Section 4.2.4.4.
>  
> To: Susan Hares; Stephane Litkowski (slitkows); [email-masked]; Acee Lindem (acee)
> On Nov 10, 2020, 1:01 PM -0800, Acee Lindem (acee) <acee=[email-masked]>, wrote:
> 
> From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
> To: "'Stephane Litkowski (slitkows)'" <slitkows=[email-masked]>, IDR List <[email-masked]>
> To: Susan Hares; [email-masked]
> From: Susan Hares <[email-masked]>
> To: Stephane Litkowski (slitkows) <[email-masked]>; [email-masked]
> To: Susan Hares; [email-masked]
> To: [email-masked]
> [email-masked]

---

From: Huzhibo <[email-masked]>
Date: Sat, 14 Nov 2020 03:19:38 +0000

Hi Les, Acee:

Actually we have already discussed about this and reached agreements about two years ago. You may have forgotten. Please find the archives below.

https://mailarchive.ietf.org/arch/msg/lsr/C2bhd2ff2UJf4e_Gr-7j2W0g-SU/

I have followed your advice: "there already is a per link MTU sub-TLV defined by RFC 7176 ... in which case the existing sub-TLV is a perfect fit ...  IS-IS already has what is needed and therefore does not need any additional protocol extension". So we let our draft on ISIS extensions for MTU expired, i.e. draft-hu-lsr-isis-path-mtu. To be honest, I am a bit surprised when I saw your comments.

In this draft we focused on the extensions of BGP_LS for MTU only, which does not have to be feed by IGP LSDB. This draft has been discussed and revised a few rounds, based on the feedbacks both on ietf meetings and mail list, this document has good maturity to move forward.

Thanks
Zhibo

发件人: Idr [mailto:[email-masked]] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年11月14日 7:58
收件人: Ketan Talaulikar (ketant) <ketant=[email-masked]>; Susan Hares <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'Stephane Litkowski (slitkows)' <slitkows=[email-masked]>; [email-masked]; 'Acee Lindem (acee)' <acee=[email-masked]>
抄送: [email-masked]
主题: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

   Les

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; 'Jeff Tantsura' <[email-masked]<mailto:[email-masked]>>; 'Stephane Litkowski (slitkows)' <slitkows=[email-masked]<mailto:slitkows=[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Acee Lindem (acee)' <acee=[email-masked]<mailto:acee=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Hi Authors,

Hi Sue,

Thanks,
Ketan

Cheers,  Sue

Cheers,
Jeff

Speaking as LSR Chair:

Thanks,
Acee

Stephane:

Cheers,  Sue

Hi Sue,

Stephane

Stephane:

</wg-chair hat off>

Cheers, Susan Hares

Hi,

Stephane

Cheers, Sue

Background
===========

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 14 Nov 2020 03:35:38 +0000

Hi Zhibo,

I agree with everything that was discussed and concluded on that thread which you referred to.

It was about re-using existing sub-TLV for link MTU defined for Trill in ISIS. We are still saying the same thing! There is still the work required for the base ISIS procedures to be defined for the same.

Note that I did ask about the ISIS procedures for MTU during the last IETF online where the draft was presented. I was referred to the Trill spec at that time. But as we can clearly see those procedures are not applicable for normal ISIS.

Perhaps there was a misunderstanding somewhere in the middle that resulted in the approach that the authors took (i.e. assuming everything else was done and only BGP-LS remained) ?

In the thread the authors also spoke about OSPF but that seemed to have been dropped. As mentioned in my feedback, I am happy to help with if required.

Finally, I don’t see any opposition to the work itself or for it to be adopted (in due course). The discussion is on the “missing pieces” for this proposal to work and where this work is better accomplished.

Thanks,
Ketan

From: Huzhibo <[email-masked]>
Sent: 14 November 2020 08:50
To: Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Susan Hares <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; Stephane Litkowski (slitkows) <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]
Subject: 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Hi Les, Acee:

Thanks
Zhibo

发件人: Idr [mailto:[email-masked]] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年11月14日 7:58
收件人: Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; 'Jeff Tantsura' <[email-masked]<mailto:[email-masked]>>; 'Stephane Litkowski (slitkows)' <slitkows=[email-masked]<mailto:slitkows=[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Acee Lindem (acee)' <acee=[email-masked]<mailto:acee=[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

   Les

Hi Authors,

Hi Sue,

Thanks,
Ketan

Cheers,  Sue

Cheers,
Jeff

Speaking as LSR Chair:

Thanks,
Acee

Stephane:

Cheers,  Sue

Hi Sue,

Stephane

Stephane:

</wg-chair hat off>

Cheers, Susan Hares

Hi,

Stephane

Cheers, Sue

Background
===========

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Sat, 14 Nov 2020 10:06:05 +0000

Hi Les,

         Inter-AS E2E sr-policy scenario also need this. The inter-as link info will be collected by BGP EPE.
       The MTU is link’s attribute, so we need independent attribute TLV for all protools’ link NLRI.

Regards,
Haibo

From: Idr [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Saturday, November 14, 2020 9:52 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; Ketan Talaulikar (ketant) <ketant=[email-masked]>; Stephane Litkowski (slitkows) <slitkows=[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; Susan Hares <[email-masked]>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

On Nov 13, 2020, at 15:57, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

   Les

Hi Authors,

Hi Sue,

Thanks,
Ketan

Cheers,  Sue

Cheers,
Jeff

Speaking as LSR Chair:

Thanks,
Acee

Stephane:

Cheers,  Sue

Hi Sue,

Stephane

Stephane:

</wg-chair hat off>

Cheers, Susan Hares

Hi,

Stephane

Cheers, Sue

Background
===========

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 14 Nov 2020 11:13:38 +0100

Hi Huzhibo,

I would like to highlight another aspect of this draft independent in which
(if any) WG it will end up with.

Many network operators today to interconnect their routers purchase
circuits. However those circuits in vast majority use brilliant technology
of VPWS, L2VPN, EVPN ... you name it. So effectively the circuit is just an
illusion and what is really sold is an emulated circuit running as IP
encapsulated L2 packets on someone IP backbone.

And here comes the crux of the issue - depending on the time of the day,
state and events in the carrier's underlay real MTU changes. And today what
is worse routers have no good way to even detect it. Some attempts pop up
here and there (like stuff BFD to 1500 or so), but the point is that what
could be promised, sold and configured on the interface may not be what is
really under the hood.

Things get even more colorful when only some discrete packet sizes fail
while smaller and bigger go through just fine - Swiss-MTU if you will :)

Sure your proposal just uses static MTU like any other mentioned in your
draft consumer of that information but I am bringing it here for two
reasons:

A) Draft needs to consider this problem and discuss dynamics related to
real MTU changes

B) A discussion needs to be started if it would not be much more effective
to simply detect MTU at the data plane between the src and dst in an end to
end fashion rather then using it in control plane as a atomic piece of
assumed truth used to make any path calculation.

Kind regards,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 14 Nov 2020 17:28:54 +0000

Zhibo –

It is good of you to “keep me honest” as regards my past comments.

In reviewing the relevant material, the best I can say as regards my comments from 2 years ago is that they were made with insufficient diligence. Apologies for any resulting confusion.

https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 clearly indicates that the advertised value is dependent on the results of MTU-probe testing as specified in https://www.rfc-editor.org/rfc/rfc6325#section-4.3.2 .

Particularly relevant is the statement:

“o  MTU: This field is set to the largest successfully tested MTU size
      for this link or zero if it has not been tested, as specified in
      Section 4.3.2 of [RFC6325].”

So, as currently defined, IS-IS is not allowed to advertise a non-zero MTU value unless MTU-probes/acks have been exchanged.

https://www.rfc-editor.org/rfc/rfc7177#section-5 further clarifies that:

“The purpose of MTU testing is to ensure that the links used in the
   campus topology can pass TRILL IS-IS packets, particularly LSP PDUs,
   at the TRILL campus MTU.”

So the stated purpose of the TRILL definitions is NOT to provide assurances of data packet MTU, but more specifically to ensure that the IS-IS protocol can function correctly.

Could the MTU sub-TLV be repurposed to meet the requirements being discussed in the context of draft-zhu-idr-bgp-ls-path-mtu? Yes – I think that is possible - but it requires further  work.

draft-hu-lsr-isis-path-mtu was published over two years ago to define IS-IS extensions to advertise MTU. As you have noted, you received feedback from both Acee and myself which suggested that the TRILL defined MTU sub-TLV might be a better choice than the node property you had proposed. It seems based on that feedback you abandoned draft-hu-lsr-isis-path-mtu and focused only on draft-zhu-idr-bgp-ls-path-mtu. But as others have also noted, there is a gap regarding IGP support. OSPF has no ability to support MTU advertisement currently and – as this thread explains – even in IS-IS there is work to be done.

I would like to restate that I am – like others – supportive of this work – but I think WG adoption at this stage (in ANY WG) is premature.

   Les

From: Huzhibo <[email-masked]>
Sent: Friday, November 13, 2020 7:20 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Susan Hares <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; Stephane Litkowski (slitkows) <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]
Subject: 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Hi Les, Acee:

Thanks
Zhibo

   Les

Hi Authors,

Hi Sue,

Thanks,
Ketan

Cheers,  Sue

Cheers,
Jeff

Speaking as LSR Chair:

Thanks,
Acee

Stephane:

Cheers,  Sue

Hi Sue,

Stephane

Stephane:

</wg-chair hat off>

Cheers, Susan Hares

Hi,

Stephane

Cheers, Sue

Background
===========

---

From: Huzhibo <[email-masked]>
Date: Sun, 15 Nov 2020 13:26:25 +0000

Hi les:
I agree with you that IGP still has work to do. I think we can leave the work to LSR to complete it, which does not affect the current BGP work.

Thank you.
Zhibo
发件人: Les Ginsberg (ginsberg) [mailto:[email-masked]]
发送时间: 2020年11月15日 1:29
收件人: Huzhibo <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Susan Hares <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; Stephane Litkowski (slitkows) <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>
抄送: [email-masked]
主题: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Zhibo –

   Les

From: Huzhibo <[email-masked]<mailto:[email-masked]>>
Sent: Friday, November 13, 2020 7:20 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; 'Jeff Tantsura' <[email-masked]<mailto:[email-masked]>>; Stephane Litkowski (slitkows) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Hi Les, Acee:

Thanks
Zhibo

   Les

Hi Authors,

Hi Sue,

Thanks,
Ketan

Cheers,  Sue

Cheers,
Jeff

Speaking as LSR Chair:

Thanks,
Acee

Stephane:

Cheers,  Sue

Hi Sue,

Stephane

Stephane:

</wg-chair hat off>

Cheers, Susan Hares

Hi,

Stephane

Cheers, Sue

Background
===========

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 16 Nov 2020 01:00:43 -0500

Les: 

As you know, part of the chair’s duty is to determine if the authors have missed mentioning something in their draft proposal.  My questions were about the BGP-only features since it seemed obvious to me after working with the draft-ietf-idr-tunnel-encaps as a shepherd.   BGP has had direct routes since BGP-v3.  

There is appears to be interest in working on the BGP-only network and this topic.   The authors plan to resubmit the draft with a different name and details on BGP-only.  

One way to accomplish the evaluation of the “BGP only” service is to extend this WG Adoption call 1 week to allow discussion of that the revision that contains that information.   

Cheerily, Susan Hares 

 

 

From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Friday, November 13, 2020 6:58 PM
To: Ketan Talaulikar (ketant); Susan Hares; 'Jeff Tantsura'; 'Stephane Litkowski (slitkows)'; [email-masked]; 'Acee Lindem (acee)'
Cc: [email-masked]
Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

   Les

Hi Authors,

Hi Sue,

   specified in [RFC6325], Section <https://tools.ietf.org/html/rfc6325#section-4.2.4.4>  4.2.4.4.

Thanks,

Ketan

the planned progression. 

Cheers,  Sue 

Cheers, 

Jeff

Speaking as LSR Chair:

Thanks,

Acee

Stephane:

Cheers,  Sue

Hi Sue,

 

Stephane

Stephane:

<WG-chair hat>

</wg-chair hat off>

 

Cheers, Susan Hares

Hi,

 

Stephane

Cheers, Sue

Background

===========

MTU size per link.   

this information.

MTU.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 16 Nov 2020 01:09:50 -0500

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-masked]] 
Sent: Friday, November 13, 2020 8:52 PM
To: Les Ginsberg (ginsberg)
Cc: Ketan Talaulikar (ketant); Susan Hares; Stephane Litkowski (slitkows); [email-masked]; Acee Lindem (acee); [email-masked]
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Regards,

Jeff

   Les

Hi Authors,

Hi Sue,

Thanks,

Ketan

the planned progression. 

Cheers,  Sue 

Cheers, 

Jeff

Speaking as LSR Chair:

Thanks,

Acee

Stephane:

Cheers,  Sue

Hi Sue,

 

Stephane

Stephane:

<WG-chair hat>

</wg-chair hat off>

 

Cheers, Susan Hares

Hi,

 

Stephane

Cheers, Sue

Background

===========

MTU size per link.   

this information.

MTU.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 16 Nov 2020 08:04:12 +0000

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-masked]>
Sent: 16 November 2020 11:40
To: 'Jeff Tantsura' <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>
Cc: Ketan Talaulikar (ketant) <[email-masked]>; Stephane Litkowski (slitkows) <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Jeff:

Cheers, Sue

Cc: Ketan Talaulikar (ketant); Susan Hares; Stephane Litkowski (slitkows); [email-masked]<mailto:[email-masked]>; Acee Lindem (acee); [email-masked]<mailto:[email-masked]>

   Les

Hi Authors,

Hi Sue,

Thanks,
Ketan

Cheers,  Sue

Cheers,
Jeff

Speaking as LSR Chair:

Thanks,
Acee

Stephane:

Cheers,  Sue

Hi Sue,

Stephane

Stephane:

</wg-chair hat off>

Cheers, Susan Hares

Hi,

Stephane

Cheers, Sue

Background
===========

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 16 Nov 2020 02:38:25 -0800

Sue,

Ketan’s draft would be a great starting point.

Regards,
Jeff

> On Nov 16, 2020, at 00:04, Ketan Talaulikar (ketant) <[email-masked]> wrote:
> 
> 
> Hi Sue,
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 16 Nov 2020 09:00:09 -0500

I support WG adoption and agree Ketan’s doc is good start.

On Mon, Nov 16, 2020 at 5:38 AM Jeff Tantsura <[email-masked]>
wrote:

> 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-masked]>
> *Sent:* 16 November 2020 11:40
> *To:* 'Jeff Tantsura' <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>
> *Cc:* Ketan Talaulikar (ketant) <[email-masked]>; Stephane Litkowski
> (slitkows) <[email-masked]>; [email-masked]; Acee Lindem (acee) <
> [email-masked]>; [email-masked]
> *Subject:* RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Jeff:
>
>
>
> 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-masked]
> <[email-masked]>]
> *Sent:* Friday, November 13, 2020 8:52 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Ketan Talaulikar (ketant); Susan Hares; Stephane Litkowski
> (slitkows); [email-masked]; Acee Lindem (acee); [email-masked]
> *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
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
> *From:* Idr <[email-masked]> *On Behalf Of *Ketan Talaulikar
> (ketant)
> *Sent:* Friday, November 13, 2020 1:35 AM
> *To:* Susan Hares <[email-masked]>; 'Jeff Tantsura' <
> [email-masked]>; 'Stephane Litkowski (slitkows)' <
> slitkows=[email-masked]>; [email-masked]; 'Acee Lindem (acee)' <
> acee=[email-masked]>
> *Cc:* [email-masked]
> *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,
>
>
>
> 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 :
>
>
>
>    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-masked]> *On Behalf Of *Susan Hares
> *Sent:* 13 November 2020 00:20
> *To:* 'Jeff Tantsura' <[email-masked]>; 'Stephane Litkowski
> (slitkows)' <slitkows=[email-masked]>; [email-masked]; 'Acee
> Lindem (acee)' <acee=[email-masked]>
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> *From:* Jeff Tantsura [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Thursday, November 12, 2020 12:53 PM
> *To:* Susan Hares; Stephane Litkowski (slitkows); [email-masked]; Acee
> Lindem (acee)
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> 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-masked]> on behalf of Susan Hares <
> [email-masked]>
> *Date:* Monday, November 9, 2020 at 4:20 PM
> *To:* "'Stephane Litkowski (slitkows)'" <
> slitkows=[email-masked]>, IDR List <[email-masked]>
> *Subject:* Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Stephane:
>
>
>
> 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.
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of* Stephane Litkowski (slitkows)
> *Sent:* Monday, November 9, 2020 4:28 AM
> *To:* Susan Hares; [email-masked]
> *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-masked]>
> *Sent:* lundi 9 novembre 2020 10:10
> *To:* Stephane Litkowski (slitkows) <[email-masked]>; [email-masked]
> *Subject:* RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Stephane:
>
>
>
> 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>
>
>
>
>
>
> 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-masked]
> <[email-masked]>]
> *Sent:* Wednesday, November 4, 2020 3:03 AM
> *To:* Susan Hares; [email-masked]
> *Subject:* RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
> (11/1/2020 to 11/16/2020)
>
>
>
> Hi,
>
>
>
> 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).
>
> *From:* Idr <[email-masked]> *On Behalf Of* Susan Hares
> *Sent:* lundi 2 novembre 2020 06:04
> *To:* [email-masked]
> *Subject:* [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020
> to 11/16/2020)
>
>
>
> Lsr mailing list
> [email-masked]
> 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

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 16 Nov 2020 14:15:47 +0000

+1. PMTU info can be collected in Non-IGP scenarios, we can do the work in parallel.

Cheng

From: Idr [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Monday, November 16, 2020 10:00 PM
To: Jeff Tantsura <[email-masked]>
Cc: [email-masked]; Stephane Litkowski (slitkows) <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>
Subject: Re: [Idr] [Lsr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

On Mon, Nov 16, 2020 at 5:38 AM Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:
Sue,

On Nov 16, 2020, at 00:04, Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sue,

Thanks,
Ketan

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Sent: 16 November 2020 11:40
To: 'Jeff Tantsura' <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Stephane Litkowski (slitkows) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Jeff:

Cheers, Sue

   Les

Hi Authors,

Hi Sue,

Thanks,
Ketan

Cheers,  Sue

Cheers,
Jeff

Speaking as LSR Chair:

Thanks,
Acee

Stephane:

Cheers,  Sue

Hi Sue,

Stephane

Stephane:

</wg-chair hat off>

Cheers, Susan Hares

Hi,

Stephane

Cheers, Sue

Background
===========

[email-masked]<mailto:[email-masked]>

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD