Hi,
I like this proposal.
I don't think we need to put a strong requirement on the originator to withdraw
the route. This could be seen as optional OR we could say that each BGP speaker
should validate the path of the SFPR, if the path is invalid, it becomes
unusable (like an unreachable nextho
Hi,
We can't time-out an attribute, we would have to time-out the SFPR w/ which it
is associated. However, I don't think we should do that.
Rather, I think what we should do is indicate that at any point in time an SFF
selects its next hop from the intersection of the set of next hop RDs
conta
Hi Adrian,
I'm not comfortable with the time-out of controlplane informations.
How do you handle a situation where there is an unknown SFIR-RD in a hop TLV
for a valid reason (the SF is down for a while !), so you are timing out the
SFPR, and eventually the SF is restored and comes back online ?
Hi Stephane,
Thanks again for the thoroughness of your review and the time it has taken to
herd the necessary cats.
* BGP ERROR HANDLING:
I don’t see the “error handling” behavior associated with this attribute
(discard, treat-as-withdraw…)
>>>
>>> I think the errors are covered by sec
Hi Adrian,
Please find some comments inline.
Brgds
-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Wednesday, April 24, 2019 19:38
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-nsh-bgp-control-pl...@ietf.org
Cc: bess@ietf.org
Subject: RE: Shepherd's review
f.org
Cc: bess@ietf.org
Subject: Re: [bess] Shepherd's review of
draft-ietf-bess-nsh-bgp-control-plane-06
Hi Stephane,
I finally carved some time...
* NEXTHOP encoding:
>>> How is the nexthop encoded in the NLRI ?
>>
>> A bit confused about this question.
>
> [SLI
Hi Stephane,
I finally carved some time...
* NEXTHOP encoding:
>>> How is the nexthop encoded in the NLRI ?
>>
>> A bit confused about this question.
>
> [SLI] I'm talking about the nexthop field of the MP_REACH_NLRI attribute,
> you must set a nexthop field even if it is not used for forwarding
Hi Adrian,
Thanks for the v09, we are now close to the end.
Here are the remaining points:
* NEXTHOP encoding:
>>> How is the nexthop encoded in the NLRI ?
>>
>> A bit confused about this question.
>
> [SLI] I'm talking about the nexthop field of the MP_REACH_NLRI attribute,
> you must set a nex
Adrian,
(resending to everyone, not just Adrian)
>>> References:
>>>
>>> I think that the mpls-sfc and mpls-sfc-encaps should also be
>>> normative as you are defining a controlplane to use them.
>>
>>I don't mind doing that.
>
> [SLI] These two are more debatable. Let's keep them as info, and
>
Thanks again Stephane,
I think we have closure on most (but not all) of your points. I'll post another
revision now because it makes the incremental changes easier to process. But we
can have another go round if any of the unresolved issues merit it.
One thing to push back on from before was th
Hi Adrian,
Thanks for the updates. More comments inline.
I have trimmed the answers we have an agreement on and added some comments.
Brgds,
-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Friday, March 01, 2019 20:18
To: LITKOWSKI Stephane OBS/OINIS; draft-iet
Hello Stephane,
Thanks for this review. It is very thorough and has helped improve the document.
We have posted an update to the draft, and there are responses to your review,
below.
Thanks,
Adrian
> The document is globally well written with good examples that help the
> understanding.
> How
Agree
From: Andrew G. Malis [mailto:agma...@gmail.com]
Sent: Wednesday, February 27, 2019 15:21
To: LITKOWSKI Stephane OBS/OINIS
Cc: draft-ietf-bess-nsh-bgp-control-pl...@ietf.org; bess@ietf.org
Subject: Re: [bess] Shepherd's review of
draft-ietf-bess-nsh-bgp-control-plane-06
Ste
Stephane,
Responding to one of your comments - making mpls-sfc-encaps a normative
reference would be a downref, as it's an informational draft. That's OK as
long as everyone is aware of it and it's documented in the IESG writeup,
but that does have to happen. It may just be easier to keep it as an
Hi,
Here is my review of draft-ietf-bess-nsh-bgp-control-plane-06
General comment:
The document is globally well written with good examples that help the
understanding. However it requires some refinements in the normative language
used: some statement should be normative but are not using upp
15 matches
Mail list logo
