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 protected]] On Behalf Of Jeff Tantsura
Sent: Saturday, November 14, 2020 9:52 AM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: [email protected]; Ketan Talaulikar (ketant)
<[email protected]>; Stephane Litkowski (slitkows)
<[email protected]>; Acee Lindem (acee)
<[email protected]>; [email protected]; Susan Hares <[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]<mailto:[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]<mailto:[email protected]>> On Behalf Of
Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares <[email protected]<mailto:[email protected]>>; 'Jeff Tantsura'
<[email protected]<mailto:[email protected]>>; 'Stephane Litkowski
(slitkows)'
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; 'Acee Lindem (acee)'
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[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]<mailto:[email protected]>> On Behalf Of
Susan Hares
Sent: 13 November 2020 00:20
To: 'Jeff Tantsura' <[email protected]<mailto:[email protected]>>;
'Stephane Litkowski (slitkows)'
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; 'Acee Lindem (acee)'
<[email protected]<mailto:[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]]
Sent: Thursday, November 12, 2020 12:53 PM
To: Susan Hares; Stephane Litkowski (slitkows);
[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> on behalf of
Susan Hares <[email protected]<mailto:[email protected]>>
Date: Monday, November 9, 2020 at 4:20 PM
To: "'Stephane Litkowski (slitkows)'"
<[email protected]<mailto:[email protected]>>,
IDR List <[email protected]<mailto:[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]] On Behalf Of Stephane Litkowski
(slitkows)
Sent: Monday, November 9, 2020 4:28 AM
To: Susan Hares; [email protected]<mailto:[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]<mailto:[email protected]>>
Sent: lundi 9 novembre 2020 10:10
To: Stephane Litkowski (slitkows)
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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]]
Sent: Wednesday, November 4, 2020 3:03 AM
To: Susan Hares; [email protected]<mailto:[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]<mailto:[email protected]>> On Behalf Of
Susan Hares
Sent: lundi 2 novembre 2020 06:04
To: [email protected]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
