Got it, thanks.
And see my email that crossed yours on the wire, regarding where to target it,
etc.
—John
On Mar 22, 2022, at 4:57 PM, Ketan Talaulikar wrote:
Hi John,
I'll work on the proposal right after this IETF and share it with you before
posting.
Most likely it goes trivially as
Hi John,
I'll work on the proposal right after this IETF and share it with you
before posting.
Most likely it goes trivially as you suggested and in the process also
secure wider WG consensus for the naming change(s).
Thanks,
Ketan
On Wed, 23 Mar, 2022, 2:18 am John Scudder, wrote:
> On Mar
On Mar 22, 2022, at 4:39 PM, Ketan Talaulikar
mailto:ketant.i...@gmail.com>> wrote:
Please let us know if this addresses your concerns.
While I’m disappointed you’ve opted not to “leave the campsite cleaner than you
found it”, I can live with it, assuming we’ll then take up the promised
Hi John,
Thanks for those details. I agree that there shouldn't be an issue with
your bare-bones proposal. An update with this text change and [1] has just
been posted:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-14
Please let us know if this addresses your concerns.
Yes, you’re right that 9012 is another possible ref.
Regarding the option of doing it in the current spec —
- I hear you that you’re not certain you’d be capturing every relevant
reference, however I think this is a case of “best is the enemy of good”.
Listing the known references would be an
Hi John,
This point was discussed amongst some of the authors. We were not sure if
we had got all the references to the specs that do this kind of handling
for "embedded label". RFC9012 came up as another possible reference.
I was wondering if we could go about this change in a separate (AD
Hi Authors,
I’m not sure if this point was considered and rejected (in which case let’s
close it out in email please), or (more likely) just dropped?
> On Feb 18, 2022, at 4:48 PM, Robert Raszuk wrote:
>
>
> Hi John,
>
>> Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA
Hi Ketan
Responses in-line
On Thu, Mar 17, 2022 at 1:15 PM Ketan Talaulikar
wrote:
> Hi Gyan,
>
> Please check inline below for responses.
>
>
> On Wed, Mar 16, 2022 at 8:08 PM Gyan Mishra wrote:
>
>>
>> Hi Ketan
>>
>> I reviewed the updated security considerations section and the update
>>
Hi Gyan,
Please check inline below for responses.
On Wed, Mar 16, 2022 at 8:08 PM Gyan Mishra wrote:
>
> Hi Ketan
>
> I reviewed the updated security considerations section and the update
> looks good. As well section 10.3 Data plane considerations and read again
> the referenced documents
Hi Ketan
I reviewed the updated security considerations section and the update looks
good. As well section 10.3 Data plane considerations and read again the
referenced documents security considerations section of RFC 8402, RFC 8986,
RFC 8754 and RFC 8996. All looks very good.
One question I
Hi Robert
Agreed. A new SAFI for VPN and even MVPN application service encoding with
multiple transports adds quite lot of complexity.
The P2P one hop nature of MP Reach has been a Day 1 issue that has been
problematic to troubleshoot and that would be great if you have a solution
that does a
Hi Robert,
Curious to learn your proposal on this, as you mentioned earlier defining
new AFI/SAFI may be the cleanest, but as I understand there are also some
hurdles to be taken there.I think it its necessary to be able to identify
different dataplane capabilities unambiguously in some way.
Dear Yao,
The issue is not related to support or no support of a new feature
although that is also not well addressed in current BGP-4 specification.
The question is about coexistence of multiple transports and
service encoding for the same application.
I have a separate proposal on this, but
Hi Robert,
Thanks for sharing your detailed consideration on BGP capability and new NLRI.
A few comments about the BGP capability solution. Please see inline [YAO].
==
In BGP protocol any new service deployment using
Hi John,
We've just posted an update to the draft to address the comments raised and
to clarify the security considerations.
https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-12
Thanks,
Ketan
On Thu, Feb 24, 2022 at 3:42 PM Robert Raszuk wrote:
> Hi John,
>
> You have
Hi John,
You have highlighted below a very important point. It was discussed among
co-authors, but perhaps not sufficiently during the BESS process as the
issue is really not a BESS WG problem.
In BGP protocol any new service deployment using existing AFI/SAFI is not
easy. Especially when you
Hi Yao,
Thanks for bringing this up. I’ve followed up further in the main thread.
Regards,
—John
> On Feb 17, 2022, at 1:44 AM, liu.ya...@zte.com.cn wrote:
>
>
>
> Hi,
>
> Ron and John both mentioned that leveraging the existing AFI/SAFI may cause
> misunderstanding of the SRv6 service
Further to this point:
> On Feb 18, 2022, at 3:32 PM, John Scudder wrote:
>
>> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar wrote:
>>
>>> 2. One area of concern I would have hoped IDR might have looked into is, the
>>> document makes a creative use of the MPLS Label field of the NLRI to
Hi Robert,
> On Feb 16, 2022, at 5:02 PM, Robert Raszuk wrote:
>
>
> Hi John,
>
> As you have quoted my note in point #4 I feel that I need to comment on it.
Thank you for doing so!
> So yes original discussions and major contributions of this work were
> focusing on VPN use case and I
Hi Ketan,
> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar wrote:
>
>> 3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent
>> discussion turned quickly to the assertion that no, they don’t, in VPN
>> address
>> families. Let’s accept that claim for the sake of
Hi John,
Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA SAFI
> registry. Shouldn’t this be renamed? I mean, I guess it should have been
> renamed as of RFC 8365, but better late than never. I’m not sure quite what
> the name should become, but “MPLS-labeled” is manifestly
Hi Ketan,
> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar wrote:
>
>> 2. One area of concern I would have hoped IDR might have looked into is, the
>> document makes a creative use of the MPLS Label field of the NLRI to carry
>> the
>> Function part of the SID. This means the SID is effectively
ess@ietf.org> mailto:bess@ietf.org>>,
Bocci, Matthew (Nokia - GB)
mailto:matthew.bo...@nokia.com>>, Bocci, Matthew
(Nokia - GB) mailto:matthew.bo...@nokia.com>>
Subject: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with
DISCUSS and COMMENT)
John Scudder has ente
...@ietf.org
; The IESG ; bess@ietf.org
; idr-cha...@ietf.org
Subject: Re: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with
DISCUSS and COMMENT)
After sleeping on it I was too hasty in saying “water under the bridge” and
moving on.
I’d like to request that you correct the oversight
tf.org>
mailto:bess-cha...@ietf.org>>,
bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>,
Bocci, Matthew (Nokia - GB)
mailto:matthew.bo...@nokia.com>>, Bocci, Matthew
(Nokia - GB) mailto:matthew.bo...@nokia.com>>
Subject: John Scudder's Discuss on draft-iet
gt; Regards
>
> Matthew
>
> From: John Scudder via Datatracker
> Date: Wednesday, 16 February 2022 at 21:39
> To: The IESG
> Cc: draft-ietf-bess-srv6-servi...@ietf.org
> , bess-cha...@ietf.org
> , bess@ietf.org , Bocci, Matthew (Nokia
> - GB) , Bocci, Matthew (N
er via Datatracker
Date: Wednesday, 16 February 2022 at 21:39
To: The IESG
Cc: draft-ietf-bess-srv6-servi...@ietf.org
, bess-cha...@ietf.org
, bess@ietf.org , Bocci, Matthew (Nokia -
GB) , Bocci, Matthew (Nokia - GB)
Subject: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with
D
Hi Yao,
Thanks to you and your co-authors for this work.
While the implementations and deployments today use configuration knobs for
this purpose, the use of capabilities exchange is certainly another option
to consider. However, the capability exchange takes care of peering between
Hi John,
Thanks for your review and please check inline below for responses.
On Thu, Feb 17, 2022 at 3:09 AM John Scudder via Datatracker <
nore...@ietf.org> wrote:
> John Scudder has entered the following ballot position for
> draft-ietf-bess-srv6-services-11: Discuss
>
> When responding,
Hi,
Ron and John both mentioned that leveraging the existing AFI/SAFI may cause
misunderstanding of the SRv6 service routes.
We encountered this problem during implementation and submitted a draft talking
about this.
https://datatracker.ietf.org/doc/html/draft-lz-bess-srv6-service-capability-02
Hi,
Ron and John both mentioned that leveraging the existing AFI/SAFI may cause
misunderstanding of the SRv6 service routes.
We encountered this problem during implementation and submitted a draft talking
about this.
Hi John,
As you have quoted my note in point #4 I feel that I need to comment on it.
So yes original discussions and major contributions of this work were
focusing on VPN use case and I admit when carefully re- reading it to find
some text there beyond VPN use case.
So we discussed it among
John Scudder has entered the following ballot position for
draft-ietf-bess-srv6-services-11: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
33 matches
Mail list logo
