Sold!
Cheers,
Jeff
On 4/6/18, 14:45, "Acee Lindem (acee)" wrote:
Good point - we will expand to:
-lsr-ospf- - OSPF Specific
drafts pertaining to both OSPFv2 and OSPFv3
-lsr-ospfv2- - OSPFv2 only Specific
drafts
-lsr-ospfv3- - OSPFv3 only Specific
dra
Good point - we will expand to:
-lsr-ospf- - OSPF Specific drafts
pertaining to both OSPFv2 and OSPFv3
-lsr-ospfv2- - OSPFv2 only Specific
drafts
-lsr-ospfv3- - OSPFv3 only Specific
drafts
-lsr-isis-- IS-IS Specific drafts
-lsr- - Drafts c
Acee,
What about ospfv2 vs ospfv3 specifics?
We keep it as before - eg “ospf” covers either or ospfv2, “ospfv3” is for
ospfv3 only?
Regards,
Jeff
> On Apr 6, 2018, at 12:25, Acee Lindem (acee) wrote:
>
> I'm fine with the proposed naming conventions for new drafts. Formally:
>
>-lsr-os
+1
Regards,
Jeff
> On Apr 6, 2018, at 12:25, Acee Lindem (acee) wrote:
>
> I'm fine with the proposed naming conventions for new drafts. Formally:
>
>-lsr-ospf- - OSPF Specific drafts
>-lsr-isis- - IS-IS Specific drafts
>-lsr- - Drafts covering both
> protocol
I think this discussion has already gone much too far in the direction of
customized flooding optimizations. Such is the nature of the engineering mind –
give us a problem to solve and we’ll come up with a plethora of solutions.
The right perspective (for me anyway) is this:
IGPs have been pop
I'm fine with the proposed naming conventions for new drafts. Formally:
-lsr-ospf- - OSPF Specific drafts
-lsr-isis- - IS-IS Specific drafts
-lsr- - Drafts covering both
protocols.
Anyone strongly disagree?
Thanks,
Acee
On 4/6/18, 1:57 PM, "
Dear lsr WG:
draft-ietf-ospf-link-overload [1] defines a new BGP-LS
Graceful-Link-Shutdown TLV. When an early allocation was requested, it was
mistakenly requested from the "BGP-LS NLRI-Types" registry [2], not from
the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TL
I agree with Rob & Tony.
Converging on single algorithm across zoo of vendors is not going to happen
bearing in mind that every single change to such algorithm will require a
massive 1000s nodes software upgrade each time.
Note that even if IETF converges industry may not and that is a practical
Hi Acee,
I’m aware of the IPR and it has been disclosed in compliance with IETF IPR
rules.
https://datatracker.ietf.org/ipr/3040/
Thanks!
Cheers,
Jeff
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, April 5, 2018 at 18:22
To: "draft-ietf-ospf-segment-routing-msd...@ietf.
Tom -
Thanx for the support.
It occurs to me that your filter still needs adjustment however - since there
will be cases when a common document is used for all protocols - and in such a
case you can only expect "-lsr-" to be in the title.
My point is there should be a straightforward way to id
Peter,
How do we transition between algorithms in the approach that you suggest?
Do all non-stub devices need to be upgraded to support the new algorithm
before such time as we can use it? (I think so, because otherwise some
non-stub device cannot be guaranteed to flood to its downstream stub
devi
Hi Tony,
if we start with a single standardized algorithm, that is easy to
implement and deploy. We can leave the door open for additional
algorithms to be defined later together with the selection mechanism.
I have the feeling that the dependency of the "flooding topology" on the
flooded da
Hi Peter,
Thank you for your comments.
> while I appreciate the flexibility associated with the centralized
> computation of the flooding topology, it has some drawbacks as well:
>
> 1. "flooding topology" must be flooded. This makes the flooding dependent on
> the flooded data itself.
Abso
Hi Tony,
while I appreciate the flexibility associated with the centralized
computation of the flooding topology, it has some drawbacks as well:
1. "flooding topology" must be flooded. This makes the flooding
dependent on the flooded data itself.
2. The extra flooding of "flooding topology"
Hi Acee,
my answers below (I didn't vet them with other authors, so they may
express different opinions).
> 1. Have you considered a shorter name for the RFC? For example: “OSPF
> Cross Address Family Traffic Engineering Tunnels”?
Your proposed variant drops two pieces: "Routing
- Original Message -
From: "Les Ginsberg (ginsberg)"
Sent: Thursday, April 05, 2018 5:26 PM
> Chris -
>
> > -Original Message-
> > From: Christian Hopps
> > Sent: Thursday, April 05, 2018 7:32 AM
> >
> > I think that the only time we should include the protocol (in
addition to '-
16 matches
Mail list logo
