Subject: Re: [Idr] [Lsr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu
(11/1/2020 to 11/16/2020)
I support WG adoption and agree Ketan’s doc is good start.
On Mon, Nov 16, 2020 at 5:38 AM Jeff Tantsura
mailto:jefftant.i...@gmail.com>> wrote:
Sue,
Ketan’s draft would be a great starting
I support WG adoption and agree Ketan’s doc is good start.
On Mon, Nov 16, 2020 at 5:38 AM Jeff Tantsura
wrote:
> Sue,
>
> Ketan’s draft would be a great starting point.
>
> Regards,
> Jeff
>
> On Nov 16, 2020, at 00:04, Ketan Talaulikar (ketant)
> wrote:
>
>
>
> Hi Sue,
>
>
>
> I was
Sue,
Ketan’s draft would be a great starting point.
Regards,
Jeff
> On Nov 16, 2020, at 00:04, Ketan Talaulikar (ketant) 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
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
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
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
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.
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:idr-boun...@ietf.org] On Behalf Of Jeff
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
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)
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
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
12 matches
Mail list logo
