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
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.
I have followed your advice: "there already is a per link MTU
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.
> On Nov 13, 2020, at 15:57, Les Ginsberg (ginsberg)
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
Dear Peter Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Zhibo Hu:
An IPR disclosure that pertains to your Internet-Draft entitled "IS-IS
Extension to Support Segment Routing over IPv6 Dataplane"
(draft-ietf-lsr-isis-srv6-extensions) was submitted to the IETF Secretariat
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