Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Ketan Talaulikar]

Hi Alvaro,

Thanks for your quick response and please see further inline below.

We will include these changes in the next update of the draft.


On Fri, Feb 18, 2022 at 12:30 AM Alvaro Retana 
wrote:

> On February 16, 2022 at 1:28:43 PM, Ketan Talaulikar wrote:
>
>
> Ketan:
>
> Hi!
>
>
> > > --
> > > DISCUSS:
> > > --
> > >
> > > I am balloting DISCUSS because the document underspecifies the use of
> > > Endpoint Behaviors. As a result, it is unclear when they should be
> checked,
> > > enforced, or needed. Details follow.
> > >
> > >
> > > The descriptions of the TLVs in §2 say (twice) that the "SRv6 Endpoint
> > > behaviors which MAY be encoded, but not limited to, are...etc."
> > >
> > > The text above ends with "etc." which means there are other possible
> > > behaviors. That's not a great use of normative language, even if
> optional.
> >
> > KT> Agree. We have removed the "etc".
>
> Ok.  Given the rest of the text, I think that "MAY" is just expressing
> a fact, not a normative action: s/MAY/may
>

KT> Ack


>
>
> > > My initial instinct was to ask you to be specific, BUT...
> > >
> > > The description of the SRv6 SID Information Sub-TLV (§3.1) says that
> "an
> > > unrecognized endpoint behavior MUST NOT be considered invalid", which
> seems
> > > to mean that any behavior is ok, AND...
> > >
> > > There's no validation specified, except for the description of the
> SRv6 SID
> > > Structure Sub-Sub-TLV (§3.2.1), where it says that the "Argument length
> > > MUST be set to 0 for SIDs where the Argument is not applicable". AND...
> > >
> > > Several of the service descriptions in §5/§6 say that "The SRv6
> Endpoint
> > > behavior of the SRv6 SID is entirely up to the originator of the
> > > advertisement. In practice, the SRv6 Endpoint behavior is..."
> > >
> > >
> > > The result is that any endpoint behavior (even unrecognized) can be
> used,
> > > while also requiring a specific setting for the argument length in some
> > > cases.
> > >
> > > How can the argument length be validated if the endpoint behavior is
> > > unknown?
> >
> > KT> The argument length cannot be validated unless the endpoint behavior
> is
> > known. The ingress PE needs to actually write the ARG part of the SID
> into
> > the SRv6 SID advertised by the egress PE when sending packets for that
> > service to the egress PE. Therefore, knowing that the behavior involves
> > argument and validating the argument length is important. We have
> clarified
> > this in the text.
>
> I see that the text in -11 now says this:
>
>Arguments may be generally applicable for SIDs of only specific SRv6
>Endpoint behaviors (e.g., End.DT2M) and therefore the Argument length
>MUST be set to 0 for SIDs where the Argument is not applicable.  A
>receiver is unable to validate the applicability of arguments for
>SRv6 Endpoint behaviors that are unknown to it and hence MUST ignore
>SRv6 SIDs with arguments (indicated by non-zero argument length) with
>unknown endpoint behaviors.
>
> That works for me.  It addresses the cases when the Behavior is
> unknown -- the questions below are about known and expected Behaviors.
>

KT> Thanks


>
>
>
> > > Clearly (from looking at rfc8986), not all endpoint behaviors apply to
> the
> > > services defined in this document. Should a receiver accept any
> endpoint
> > > behavior? What should a receiver do if a known but unrelated behavior
> (End,
> > > for example) is received?
> > >
> > > What should the receiver do if the endpoint behavior is known and
> > > applicable, but the attribute length is not set correctly?
> >
> > KT> Could you clarify which attribute length you are referring to?
>
> Sorry, I meant the argument... :-(
>

KT> The behavior definition may or may not specify requirements of argument
lengths - the currently defined ones do not pose any limitation and so the
draft talks about zero or non-zero. We can clarify by saying something on
the lines that for behaviors where arguments apply, the argument length's
consistency must be verified against the behavior definition. Would that
address your comment?


>
>
> > > For any specific service (IPv4 VPN Over SRv6 Core, for example, to pick
> > > one), should the behaviors used "in practice" be enforced? What if
> > > different behavior is advertised? Can it safely be ignored?
>
>
>
> ...
> > > --
> > > COMMENT:
> > > --
> ...
>
> Just one comment:
>
>
> ...
> > > (8) §5:
> > >
> > > The SRv6 Service SID SHOULD be routable within the AS of the egress
> > > PE and serves the dual purpose of providing reachability between
> > > ingress PE and egress PE while also encoding the SRv6 Endpoint
> > > behavior.
> > >
> > > Is it ever ok for the SID to not be routable? 

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[John Scudder]

Thanks, Matthew. I didn’t think of searching for it under the individual 
submission name; when I read “cross-reviewed” I interpreted that as WGLC, not 
WG adoption. 

It looks to me as though there was no reply to the notification message you 
reference, do you agree? (Of course there might have been people who commented 
on the BESS list, but I don’t see anything cc’d to IDR.)

It does seem to me as though, considering the unusually close association 
between this spec and an active IDR draft, it would have made sense to 
cross-WGLC it, including a specific pointer to the overlap. I mean, I 
acknowledge that might have come to nothing since there’s considerable overlap 
between the groups — but it’s not universal overlap. Anyway, it’s water under 
the bridge now.

I’ve added the IDR chairs to the cc just in case any of them want to comment. 

Regards,

—John

> On Feb 17, 2022, at 5:52 AM, Bocci, Matthew (Nokia - GB) 
>  wrote:
> 
> 
> 
> Hi John
>  
> Regarding comment (1), we sent a notice to the IDR WG at WG Adoption time:
>  
> [Idr] FW: [bess] WG adoption and IPR poll for 
> draft-dawra-bess-srv6-services-02 (ietf.org)
>  
>  
> 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 (Nokia - GB) 
> 
> Subject: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with 
> DISCUSS and COMMENT)
> 
> 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 https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> 1. The shepherd writeup for this document says “It also received an RTG DIR
> review and cross-reviewed with the IDR working group”. Searching in my IDR
> inbox and the IDR mailing list archives, I don’t find any sign of the
> cross-review — can you please point me to it?
> 
> 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 split across the
> NLRI and the Prefix-SID attribute. What are the potential error modes if the
> Prefix-SID attribute should be lost from the route, while the NLRI is 
> retained?
> 
> (An obvious way of addressing this particular concern would be to define a new
> NLRI type with the desired semantics, instead of creatively repurposing fields
> within an existing NLRI type contrary to their definitions. Such an NLRI type
> would, for example, presumably state in its specification that if it was
> received without an accompanying Prefix-SID attribute, that would constitute 
> an
> error.)
> 
> 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 conversation. It’s still the
> case that sometimes (often?) routes are distributed from VPN address families
> into the Global Internet table. When this is done, by default, all the path
> attributes come along for the ride. Anyone who thinks this is just a
> hypothetical case might want to look back to (for example) significant network
> outages that were caused around a decade ago by leakage of BGP Attribute 128
> (ATTR_SET, RFC 6368) into the global Internet.
> 
> The SIDs contained in these if-they-were-to-leak routes potentially give an
> attacker a means of directing packets into a VPN customer’s internal network.
> 
> 4. Speaking of Warren’s DISCUSS, the shepherd’s writeup indicates “solid [WG]
> consensus”; however, there doesn’t seem to be consensus even amongst the
> authors as to whether Sections 5.3 and 5.4 are appropriate. This is a fairly
> fundamental disagreement! An illustration of the disagreement is
> https://mailarchive.ietf.org/arch/msg/bess/K1JKxGn19BXALs3rUzUAaGTZi0Y/:
> 
> “So I can see why some people may have thought oh since transport in SRv6 
> comes
> for free let's load it with services in an attribute and be done. Yes I can 
> see
> that flattening this make it potentially easier (one less SAFI to enable), 
> *but
> I am not sure we have reached a broad agreement here.* This comes as a
> consequence of moving service prefixes from 

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Alvaro Retana]

On February 16, 2022 at 1:28:43 PM, Ketan Talaulikar wrote:


Ketan:

Hi!


> > --
> > DISCUSS:
> > --
> >
> > I am balloting DISCUSS because the document underspecifies the use of
> > Endpoint Behaviors. As a result, it is unclear when they should be checked,
> > enforced, or needed. Details follow.
> >
> >
> > The descriptions of the TLVs in §2 say (twice) that the "SRv6 Endpoint
> > behaviors which MAY be encoded, but not limited to, are...etc."
> >
> > The text above ends with "etc." which means there are other possible
> > behaviors. That's not a great use of normative language, even if optional.
>
> KT> Agree. We have removed the "etc".

Ok.  Given the rest of the text, I think that "MAY" is just expressing
a fact, not a normative action: s/MAY/may


> > My initial instinct was to ask you to be specific, BUT...
> >
> > The description of the SRv6 SID Information Sub-TLV (§3.1) says that "an
> > unrecognized endpoint behavior MUST NOT be considered invalid", which seems
> > to mean that any behavior is ok, AND...
> >
> > There's no validation specified, except for the description of the SRv6 SID
> > Structure Sub-Sub-TLV (§3.2.1), where it says that the "Argument length
> > MUST be set to 0 for SIDs where the Argument is not applicable". AND...
> >
> > Several of the service descriptions in §5/§6 say that "The SRv6 Endpoint
> > behavior of the SRv6 SID is entirely up to the originator of the
> > advertisement. In practice, the SRv6 Endpoint behavior is..."
> >
> >
> > The result is that any endpoint behavior (even unrecognized) can be used,
> > while also requiring a specific setting for the argument length in some
> > cases.
> >
> > How can the argument length be validated if the endpoint behavior is
> > unknown?
>
> KT> The argument length cannot be validated unless the endpoint behavior is
> known. The ingress PE needs to actually write the ARG part of the SID into
> the SRv6 SID advertised by the egress PE when sending packets for that
> service to the egress PE. Therefore, knowing that the behavior involves
> argument and validating the argument length is important. We have clarified
> this in the text.

I see that the text in -11 now says this:

   Arguments may be generally applicable for SIDs of only specific SRv6
   Endpoint behaviors (e.g., End.DT2M) and therefore the Argument length
   MUST be set to 0 for SIDs where the Argument is not applicable.  A
   receiver is unable to validate the applicability of arguments for
   SRv6 Endpoint behaviors that are unknown to it and hence MUST ignore
   SRv6 SIDs with arguments (indicated by non-zero argument length) with
   unknown endpoint behaviors.

That works for me.  It addresses the cases when the Behavior is
unknown -- the questions below are about known and expected Behaviors.



> > Clearly (from looking at rfc8986), not all endpoint behaviors apply to the
> > services defined in this document. Should a receiver accept any endpoint
> > behavior? What should a receiver do if a known but unrelated behavior (End,
> > for example) is received?
> >
> > What should the receiver do if the endpoint behavior is known and
> > applicable, but the attribute length is not set correctly?
>
> KT> Could you clarify which attribute length you are referring to?

Sorry, I meant the argument... :-(


> > For any specific service (IPv4 VPN Over SRv6 Core, for example, to pick
> > one), should the behaviors used "in practice" be enforced? What if
> > different behavior is advertised? Can it safely be ignored?



...
> > --
> > COMMENT:
> > --
...

Just one comment:


...
> > (8) §5:
> >
> > The SRv6 Service SID SHOULD be routable within the AS of the egress
> > PE and serves the dual purpose of providing reachability between
> > ingress PE and egress PE while also encoding the SRv6 Endpoint
> > behavior.
> >
> > Is it ever ok for the SID to not be routable? If so, when? The "purpose of
> > providing reachability" requires the SID to be routable. IOW, why is this
> > behavior recommended and not required?
>
> KT> An SRv6 SID may not be routable across multiple IGP domains within a
> provider network when routes are not leaked. There can be other mechanisms
> like SR Policies (or other forms of tunneling) that provide reachability. In
> other scenarios, due to local policy, the resolution may be desired over an
> SR Policy instead of the best-effort reachability provided by IGPs.

If there's a route over a tunnel/SR Policy/whatever, I consider that
routable. I am not just thinking about IGP-learned routes.  The case
that concerns me is when the ingress PE doesn't have a route at all
(which is possible with the SHOULD).  If a route should always exist
(from any source) then it looks like the text 

Re: [bess] Erik Kline's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS)

[Ketan Talaulikar]

Hi Tony,

Indeed, perhaps you might have lost the thread here ;-)

Things are pretty simple (unless one wants to over-complicate) and covered
in the base SRv6 standards-track RFC8754. Let me put it down here:

   1.  Any packet entering the SR domain and destined to a SID within
   the SR domain is dropped.  This may be realized with the
   following logic.  Other methods with equivalent outcome are
   considered compliant:

   *  Allocate all the SIDs from a block S/s

   *  Configure each external interface of each edge node of the
  domain with an inbound infrastructure access list (IACL) that
  drops any incoming packet with a destination address in S/s

   *  Failure to implement this method of ingress filtering exposes
  the SR domain to source-routing attacks, as described and
  referenced in [RFC5095
]


I can understand the argument that someone that is doing this manually on
router CLIs today could miss this on some interface. But with the
templates, automation, and other tools available today, I find it hard to
agree when this filtering is called "complex", "not possible" and
"handwaving". Especially, when operators have already done this in their
deployments.

@Erik Kline 
In any case, none of this is being newly introduced in the document under
discussion nor changed by it.

Thanks,
Ketan


On Thu, Feb 17, 2022 at 4:19 PM Tony Przygienda  wrote:

> Ketan, yepp, 5.1.2 is roughly the CUG via ACL, add to it per service
> protection (as in some external A can talk to service X but external B
> cannot which now starts to push you into fragment the SRv6 "prefix" into
> "per service space" if you want to aggregate), multiply that by the
> downstream-upstream if you want to cross providers AFAIS (as in BGP
> flowspec up/down shorewalling) and you have a pretty nice combinatorial
> space. And BTW, source address is easily spoofed given the lack of BCP
> implementations in the real world and with source routing technology one
> can land those packets in unexpected places via unexpected routes. All that
> looks to me like nothing comparable to a leaked internal loopback today
> which was my whole point as in fallacy by  faulty analogy.
>
> Unless I lost the thread completely which, given the amount of machinery
> fielded by now ;-) could be excusable ...
>
> -- tony
>
>
> On Thu, Feb 17, 2022 at 11:37 AM Ketan Talaulikar 
> wrote:
>
>> Hi Tony,
>>
>> My apologies, but I am not able to understand your emails entirely. I
>> wonder if this text below helps explain:
>> https://datatracker.ietf.org/doc/html/rfc8754#section-5.1
>>
>> Thanks,
>> Ketan
>>
>>
>> On Thu, Feb 17, 2022 at 3:40 PM Tony Przygienda 
>> wrote:
>>
>>>
>>>
>>>

> But I'm prepared to learn why this wouldn't work or would be somehow
> worse.
>

 KT> It isn't necessary nor required because SRv6 locators are just IPv6
 prefixes that are already covered by IGP/BGP extensions for IPv6 routing. A
 provider that uses global IPv6 addresses in their infrastructure (e.g. for
 their BGP and other routing sessions, on their router links and loopback,
 for DHCP, AAA, etc.) already do routing for those prefixes via IGP/BGP.
 These are not advertised (nor leaked) out into the Internet since doing so
 can result in attacks on their internal network and infrastructure. They
 are protected via BGP configuration to stop leaks and then again by ACLs at
 Internet Border Routers to prevent attacks via the data path. This still
 remains the case to be done for SRv6 locators - they are similarly the
 service provider's "internal" infrastructure.


>>> I'm confounded by the recent line of reasoning  of SRv6 proponents.  An
>>> IPv6 address is NOT a service access point, it's a routable address,
>>> history shows us that we can protect against services on the device being
>>> attacked through that (though it took some work like proper ICMP handling).
>>> SRv6 endpoints here are really service endpoints, unless we have a CUG
>>> security architecture in place, how do we protect services here without
>>> having CUG style filters on the whole edge?  with SRv6 services giving
>>> people a service access point and a tunneling technology where someone via
>>> v6 routing can built a tunnel to hit the service is a different beast
>>> altogether than protecting reachability (routable addresses) and I fear
>>> pretty soon we're looking @ routers going very, very deep into the "IPv6"
>>> packet to make sure there aren't some magic options on the packet
>>> source-routing it in funky ways towards service endpoints that will accept
>>> the packet.
>>>
>>> --- tony
>>>
>>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Robert Raszuk]

Joel,

There was a lot of effort by various vendors put in place to help automate
protection of the domain from getting any external packet to the
infrastructure addresses.

Typically I have seen two models in SPs:

* automatic ACL protection at the data plane for all infra targets
(sometimes with exceptions of ICMP)

* putting Internet into a VPN itself hence limiting to what comes from
Internet stays in the special VPN dedicated for it.

I have not seen much individual protection done at the L2 or L3 VPNs PEs to
selectively decapsulate. But it could be done too.

However all of this is about transport layer, while this draft is mainly
about service layer so to me this is out of topic if you see the layer
decoupling.

BESS :),
Robert.


On Thu, Feb 17, 2022 at 5:11 PM Joel M. Halpern  wrote:

> I would have to dig for it, but there is general guidance that nodes
> should not decapsulate IP tunnels that they don't know about.  (There
> are exceptions, such as LISP.  But neither GRE nor MPLS in UDP have such
> exceptions.)  Conceptually, SRv6 introduces a generic exception for SRv6
> SIDs within the limited domain.  But still says to check that the packet
> you are receiving at least claims to be from within the limited domain.
>
> This has nothing to do with sr-policy.
>
> Yours,
> Joel
>
> On 2/17/2022 11:06 AM, Robert Raszuk wrote:
> > Joel,
> >
> > But we are back to per src policy then right ?
> >
> > Frankly I never saw such a policy on egress PEs and I did see L3VPNs or
> > L2VPNs running over IP. The protection is applied on ingress you your
> > domain.
> >
> > Thx,
> > R.
> >
> >
> > On Thu, Feb 17, 2022 at 5:03 PM Joel M. Halpern  > > wrote:
> >
> > I would presume that the general policy (which does not apply to
> SRv6)
> > that nodes should not decapsulate  tunnel packets without
> configuration
> > or special exemption would mean that an arbitrary MPLS node will not
> > decapsualte a GRE packet and process its MPLS content.  Otherwise,
> all
> > tunnels become major security risks.
> >
> > Yours,
> > Joel
> >
> > On 2/17/2022 10:41 AM, Zhuangshunwan wrote:
> >  > Hi all,
> >  >
> >  > +1 for Robert.
> >  >
> >  > Yes, especially when MPLS in GRE or MPLS in UDP is deployed,
> packets
> >  > carrying MPLS labels can traverse all IP-reachable networks and
> > reach
> >  > remote PEs.
> >  >
> >  > BR,
> >  >
> >  > Shunwan
>
>  >
> >  > *From:*Robert Raszuk [mailto:rob...@raszuk.net
> > ]
> >  > *Sent:* Thursday, February 17, 2022 11:28 PM
> >  > *To:* Warren Kumari mailto:war...@kumari.net
> >>
> >  > *Cc:* Ketan Talaulikar  > >; Andrew - IETF
> >  > ; Bocci, Matthew (Nokia - GB)
> >  > mailto:matthew.bo...@nokia.com>>;
> > draft-ietf-bess-srv6-servi...@ietf.org
> > ;
> >  > bess-cha...@ietf.org ; The IESG
> > mailto:i...@ietf.org>>; BESS  > >
> >  > *Subject:* Re: Warren Kumari's Discuss on
> >  > draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
> >  >
> >  > Hi Warren,
> >  >
> >  > I am very sorry but I see folks are completely mixing transport
> > layer
> >  > and service layer.
> >  >
> >  > In RFC4364 you can use MPLS label for service demux and IP
> > transport to
> >  > get to remote egress PE via any IP network including Internet.
> >  >
> >  > There is nothing in L3VPNs like enabling MPLS on interface as
> > mandatory
> >  > prerequisite. Yes many folks are confused about this and I see
> > the same
> >  > confusion here. The service plane is completely separate from
> > transport
> >  > layer from day one.
> >  >
> >  > Kind regards,
> >  >
> >  > Robert
> >  >
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Joel M. Halpern]

I would have to dig for it, but there is general guidance that nodes 
should not decapsulate IP tunnels that they don't know about.  (There 
are exceptions, such as LISP.  But neither GRE nor MPLS in UDP have such 
exceptions.)  Conceptually, SRv6 introduces a generic exception for SRv6 
SIDs within the limited domain.  But still says to check that the packet 
you are receiving at least claims to be from within the limited domain.


This has nothing to do with sr-policy.

Yours,
Joel

On 2/17/2022 11:06 AM, Robert Raszuk wrote:

Joel,

But we are back to per src policy then right ?

Frankly I never saw such a policy on egress PEs and I did see L3VPNs or 
L2VPNs running over IP. The protection is applied on ingress you your 
domain.


Thx,
R.


On Thu, Feb 17, 2022 at 5:03 PM Joel M. Halpern > wrote:


I would presume that the general policy (which does not apply to SRv6)
that nodes should not decapsulate  tunnel packets without configuration
or special exemption would mean that an arbitrary MPLS node will not
decapsualte a GRE packet and process its MPLS content.  Otherwise, all
tunnels become major security risks.

Yours,
Joel

On 2/17/2022 10:41 AM, Zhuangshunwan wrote:
 > Hi all,
 >
 > +1 for Robert.
 >
 > Yes, especially when MPLS in GRE or MPLS in UDP is deployed, packets
 > carrying MPLS labels can traverse all IP-reachable networks and
reach
 > remote PEs.
 >
 > BR,
 >
 > Shunwan
 >
 > *From:*Robert Raszuk [mailto:rob...@raszuk.net
]
 > *Sent:* Thursday, February 17, 2022 11:28 PM
 > *To:* Warren Kumari mailto:war...@kumari.net>>
 > *Cc:* Ketan Talaulikar mailto:ketant.i...@gmail.com>>; Andrew - IETF
 > ; Bocci, Matthew (Nokia - GB)
 > mailto:matthew.bo...@nokia.com>>;
draft-ietf-bess-srv6-servi...@ietf.org
;
 > bess-cha...@ietf.org ; The IESG
mailto:i...@ietf.org>>; BESS mailto:bess@ietf.org>>
 > *Subject:* Re: Warren Kumari's Discuss on
 > draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
 >
 > Hi Warren,
 >
 > I am very sorry but I see folks are completely mixing transport
layer
 > and service layer.
 >
 > In RFC4364 you can use MPLS label for service demux and IP
transport to
 > get to remote egress PE via any IP network including Internet.
 >
 > There is nothing in L3VPNs like enabling MPLS on interface as
mandatory
 > prerequisite. Yes many folks are confused about this and I see
the same
 > confusion here. The service plane is completely separate from
transport
 > layer from day one.
 >
 > Kind regards,
 >
 > Robert
 >
 > On Thu, Feb 17, 2022 at 4:14 PM Warren Kumari mailto:war...@kumari.net>
 > >> wrote:
 >
 >     On Sun, Feb 13, 2022 at 11:54 PM Ketan Talaulikar
 >     mailto:ketant.i...@gmail.com>
>> wrote:
 >
 >         Hi Warren/All,
 >
 >         This draft specifies broadly two types of BGP Services
over SRv6:
 >
 >         A) VPN Services (L3VPN & EVPN) - Sec 5.1, 5.2 & 6
 >
 >         B) Global Internet Services - Sec 5.3, 5.4
 >
 >         As explained by my co-author Robert, the operations and
 >         mechanisms for VPN services are similar to what we've had
with
 >         MPLS. I believe we are all on the same page on this one
based on
 >         the discussions between Andrew and Robert and that there
is no
 >         new concern as far as (A).
 >
 >     Actually, no, I don't think that we are -- if I, as an attacker,
 >     somehow know that VPN x uses MPLS labels Y, that's
interesting, but
 >     not particularly valuable -- because of the "fail closed"
nature of
 >     MPLS (it's a different protocol, and needs explicit and
intentional
 >     action to enable on an interface)  it's really hard for me to
 >     "inject" an MPLS packet and route it into your network. With
SRv6,
 >     if the SIDs leak, I can construct a normal v6 packet and route it
 >     towards you. Yes, handwave handwave the RFCs say that you MUST
 >     filter at your edges and that the filtering MUST always be
perfect
 >     handwave limited domain handwave -- but it's putting a large
amount
 >     of faith in operator perfection.
 >
 >     Also, if I, as an attacker get access to a "server" in the
provider
 >     network (noc workstation, billing machine, random admin PC, etc),
 >     with MPLS it's very unlikely to be part of the MPLS domain,
but  an
 >     SRv6 domain is much more likely to be "squishy" and more
likely to
 >  

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Joel M. Halpern]

I would presume that the general policy (which does not apply to SRv6) 
that nodes should not decapsulate  tunnel packets without configuration 
or special exemption would mean that an arbitrary MPLS node will not 
decapsualte a GRE packet and process its MPLS content.  Otherwise, all 
tunnels become major security risks.


Yours,
Joel

On 2/17/2022 10:41 AM, Zhuangshunwan wrote:

Hi all,

+1 for Robert.

Yes, especially when MPLS in GRE or MPLS in UDP is deployed, packets 
carrying MPLS labels can traverse all IP-reachable networks and reach 
remote PEs.


BR,

Shunwan

*From:*Robert Raszuk [mailto:rob...@raszuk.net]
*Sent:* Thursday, February 17, 2022 11:28 PM
*To:* Warren Kumari 
*Cc:* Ketan Talaulikar ; Andrew - IETF 
; Bocci, Matthew (Nokia - GB) 
; draft-ietf-bess-srv6-servi...@ietf.org; 
bess-cha...@ietf.org; The IESG ; BESS 
*Subject:* Re: Warren Kumari's Discuss on 
draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)


Hi Warren,

I am very sorry but I see folks are completely mixing transport layer 
and service layer.


In RFC4364 you can use MPLS label for service demux and IP transport to 
get to remote egress PE via any IP network including Internet.


There is nothing in L3VPNs like enabling MPLS on interface as mandatory 
prerequisite. Yes many folks are confused about this and I see the same 
confusion here. The service plane is completely separate from transport 
layer from day one.


Kind regards,

Robert

On Thu, Feb 17, 2022 at 4:14 PM Warren Kumari > wrote:


On Sun, Feb 13, 2022 at 11:54 PM Ketan Talaulikar
mailto:ketant.i...@gmail.com>> wrote:

Hi Warren/All,

This draft specifies broadly two types of BGP Services over SRv6:

A) VPN Services (L3VPN & EVPN) - Sec 5.1, 5.2 & 6

B) Global Internet Services - Sec 5.3, 5.4

As explained by my co-author Robert, the operations and
mechanisms for VPN services are similar to what we've had with
MPLS. I believe we are all on the same page on this one based on
the discussions between Andrew and Robert and that there is no
new concern as far as (A).

Actually, no, I don't think that we are -- if I, as an attacker,
somehow know that VPN x uses MPLS labels Y, that's interesting, but
not particularly valuable -- because of the "fail closed" nature of
MPLS (it's a different protocol, and needs explicit and intentional
action to enable on an interface)  it's really hard for me to
"inject" an MPLS packet and route it into your network. With SRv6,
if the SIDs leak, I can construct a normal v6 packet and route it
towards you. Yes, handwave handwave the RFCs say that you MUST
filter at your edges and that the filtering MUST always be perfect
handwave limited domain handwave -- but it's putting a large amount
of faith in operator perfection.

Also, if I, as an attacker get access to a "server" in the provider
network (noc workstation, billing machine, random admin PC, etc),
with MPLS it's very unlikely to be part of the MPLS domain, but  an
SRv6 domain is much more likely to be "squishy" and more likely to
encompass parts of the "enterprise" type systems.

W

Now (B) does bring in filtering aspects (as mentioned in the
security considerations) to ensure that the SRv6 block that is
meant for use internal to the operator's network (i.e. SR
domain) does not get leaked/advertised out from the default
table on the Internet Border Router (IBR) over to an eBGP peer.
This is similar to the precautions that operators take today to
prevent their infrastructure addresses from being leaked to the
Internet. The filters in BGP are also accompanied by ACLs at the
IBRs to prevent traffic destined for those infrastructure IPs
from entering into the operator network. This is the same in the
case of SRv6 as well.

I hope that clarifies and we can update the text to convey these
aspects better.

Thanks,

Ketan

On Sun, Feb 13, 2022 at 12:21 AM Andrew - IETF
mailto:andrew-i...@liquid.tech>> wrote:

Hi Robert,

5.3 Also opens the door to SAFI 1 – since you can v6 over v4
using AFI  1  / SAFI 1 using what is defined in RFC8950, in
fact, it is explicit.

Section 5.3 is titled Global IPv4 over SRv6 core – this
correlates with the example in section 6.1 of RFC8950 –
which states:

    The extensions defined in this document may be used as
discussed in

    [RFC5565
] for the
interconnection of IPv4 islands over an IPv6

    backbone.  In this application, Address Family Border
Routers (AFBRs;

    as defined in [RFC4925

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Zhuangshunwan]

Hi all,

+1 for Robert.
Yes, especially when MPLS in GRE or MPLS in UDP is deployed, packets carrying 
MPLS labels can traverse all IP-reachable networks and reach remote PEs.

BR,
Shunwan

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Thursday, February 17, 2022 11:28 PM
To: Warren Kumari 
Cc: Ketan Talaulikar ; Andrew - IETF 
; Bocci, Matthew (Nokia - GB) 
; draft-ietf-bess-srv6-servi...@ietf.org; 
bess-cha...@ietf.org; The IESG ; BESS 
Subject: Re: Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with 
DISCUSS and COMMENT)

Hi Warren,

I am very sorry but I see folks are completely mixing transport layer and 
service layer.

In RFC4364 you can use MPLS label for service demux and IP transport to get to 
remote egress PE via any IP network including Internet.

There is nothing in L3VPNs like enabling MPLS on interface as mandatory 
prerequisite. Yes many folks are confused about this and I see the same 
confusion here. The service plane is completely separate from transport layer 
from day one.

Kind regards,
Robert








On Thu, Feb 17, 2022 at 4:14 PM Warren Kumari 
mailto:war...@kumari.net>> wrote:


On Sun, Feb 13, 2022 at 11:54 PM Ketan Talaulikar 
mailto:ketant.i...@gmail.com>> wrote:
Hi Warren/All,

This draft specifies broadly two types of BGP Services over SRv6:

A) VPN Services (L3VPN & EVPN) - Sec 5.1, 5.2 & 6
B) Global Internet Services - Sec 5.3, 5.4

As explained by my co-author Robert, the operations and mechanisms for VPN 
services are similar to what we've had with MPLS. I believe we are all on the 
same page on this one based on the discussions between Andrew and Robert and 
that there is no new concern as far as (A).

Actually, no, I don't think that we are -- if I, as an attacker, somehow know 
that VPN x uses MPLS labels Y, that's interesting, but not particularly 
valuable -- because of the "fail closed" nature of MPLS (it's a different 
protocol, and needs explicit and intentional action to enable on an interface)  
it's really hard for me to "inject" an MPLS packet and route it into your 
network. With SRv6, if the SIDs leak, I can construct a normal v6 packet and 
route it towards you. Yes, handwave handwave the RFCs say that you MUST filter 
at your edges and that the filtering MUST always be perfect handwave limited 
domain handwave -- but it's putting a large amount of faith in operator 
perfection.

Also, if I, as an attacker get access to a "server" in the provider network 
(noc workstation, billing machine, random admin PC, etc), with MPLS it's very 
unlikely to be part of the MPLS domain, but  an SRv6 domain is much more likely 
to be "squishy" and more likely to encompass parts of the "enterprise" type 
systems.

W


Now (B) does bring in filtering aspects (as mentioned in the security 
considerations) to ensure that the SRv6 block that is meant for use internal to 
the operator's network (i.e. SR domain) does not get leaked/advertised out from 
the default table on the Internet Border Router (IBR) over to an eBGP peer. 
This is similar to the precautions that operators take today to prevent their 
infrastructure addresses from being leaked to the Internet. The filters in BGP 
are also accompanied by ACLs at the IBRs to prevent traffic destined for those 
infrastructure IPs from entering into the operator network. This is the same in 
the case of SRv6 as well.

I hope that clarifies and we can update the text to convey these aspects better.

Thanks,
Ketan


On Sun, Feb 13, 2022 at 12:21 AM Andrew - IETF 
mailto:andrew-i...@liquid.tech>> wrote:
Hi Robert,

5.3 Also opens the door to SAFI 1 – since you can v6 over v4 using AFI  1  / 
SAFI 1 using what is defined in RFC8950, in fact, it is explicit.

Section 5.3 is titled Global IPv4 over SRv6 core – this correlates with the 
example in section 6.1 of RFC8950 – which states:



   The extensions defined in this document may be used as discussed in

   [RFC5565] for the 
interconnection of IPv4 islands over an IPv6

   backbone.  In this application, Address Family Border Routers (AFBRs;

   as defined in [RFC4925]) 
advertise IPv4 NLRI in the MP_REACH_NLRI

   along with an IPv6 next hop.



   The MP_REACH_NLRI is encoded with:



   *  AFI = 1



   *  SAFI = 1



   *  Length of Next Hop Address field = 16 (or 32)



   *  Next Hop Address = IPv6 address of the next hop



   *  NLRI = IPv4 routes



   During BGP Capability Advertisement, the PE routers would include the

   following fields in the Capabilities Optional Parameter:



   *  Capability Code set to "Extended Next Hop Encoding"



   *  Capability Value containing 

As I say, if you were to remove the references to global and 5.3/5.4 which 
explicitly reference it and bring SAFI 1 into play – there would be far less 
concern from my side, I can’t speak for anyone else, but that would be my 
feeling

Thanks

Andrew



From: Robert Raszuk 

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Robert Raszuk]

Hi Warren,

I am very sorry but I see folks are completely mixing transport layer and
service layer.

In RFC4364 you can use MPLS label for service demux and IP transport to get
to remote egress PE via any IP network including Internet.

There is nothing in L3VPNs like enabling MPLS on interface as mandatory
prerequisite. Yes many folks are confused about this and I see the same
confusion here. The service plane is completely separate from transport
layer from day one.

Kind regards,
Robert








On Thu, Feb 17, 2022 at 4:14 PM Warren Kumari  wrote:

>
>
> On Sun, Feb 13, 2022 at 11:54 PM Ketan Talaulikar 
> wrote:
>
>> Hi Warren/All,
>>
>> This draft specifies broadly two types of BGP Services over SRv6:
>>
>> A) VPN Services (L3VPN & EVPN) - Sec 5.1, 5.2 & 6
>> B) Global Internet Services - Sec 5.3, 5.4
>>
>> As explained by my co-author Robert, the operations and mechanisms for
>> VPN services are similar to what we've had with MPLS. I believe we are all
>> on the same page on this one based on the discussions between Andrew and
>> Robert and that there is no new concern as far as (A).
>>
>
> Actually, no, I don't think that we are -- if I, as an attacker, somehow
> know that VPN x uses MPLS labels Y, that's interesting, but not
> particularly valuable -- because of the "fail closed" nature of MPLS (it's
> a different protocol, and needs explicit and intentional action to enable
> on an interface)  it's really hard for me to "inject" an MPLS packet and
> route it into your network. With SRv6, if the SIDs leak, I can construct a
> normal v6 packet and route it towards you. Yes, handwave handwave the RFCs
> say that you MUST filter at your edges and that the filtering MUST always
> be perfect handwave limited domain handwave -- but it's putting a large
> amount of faith in operator perfection.
>
> Also, if I, as an attacker get access to a "server" in the provider
> network (noc workstation, billing machine, random admin PC, etc), with MPLS
> it's very unlikely to be part of the MPLS domain, but  an SRv6 domain is
> much more likely to be "squishy" and more likely to encompass parts of the
> "enterprise" type systems.
>
> W
>
>
>>
>> Now (B) does bring in filtering aspects (as mentioned in the security
>> considerations) to ensure that the SRv6 block that is meant for use
>> internal to the operator's network (i.e. SR domain) does not get
>> leaked/advertised out from the default table on the Internet Border Router
>> (IBR) over to an eBGP peer. This is similar to the precautions that
>> operators take today to prevent their infrastructure addresses from being
>> leaked to the Internet. The filters in BGP are also accompanied by ACLs at
>> the IBRs to prevent traffic destined for those infrastructure IPs from
>> entering into the operator network. This is the same in the case of SRv6 as
>> well.
>>
>> I hope that clarifies and we can update the text to convey these aspects
>> better.
>>
>> Thanks,
>> Ketan
>>
>>
>> On Sun, Feb 13, 2022 at 12:21 AM Andrew - IETF 
>> wrote:
>>
>>> Hi Robert,
>>>
>>>
>>>
>>> 5.3 Also opens the door to SAFI 1 – since you can v6 over v4 using AFI
>>>  1  / SAFI 1 using what is defined in RFC8950, in fact, it is explicit.
>>>
>>>
>>>
>>> Section 5.3 is titled Global IPv4 over SRv6 core – this correlates with
>>> the example in section 6.1 of RFC8950 – which states:
>>>
>>>
>>>
>>>
>>>
>>>The extensions defined in this document may be used as discussed in
>>>
>>>[RFC5565 ] for the 
>>> interconnection of IPv4 islands over an IPv6
>>>
>>>backbone.  In this application, Address Family Border Routers (AFBRs;
>>>
>>>as defined in [RFC4925 ]) 
>>> advertise IPv4 NLRI in the MP_REACH_NLRI
>>>
>>>along with an IPv6 next hop.
>>>
>>>
>>>
>>>The MP_REACH_NLRI is encoded with:
>>>
>>>
>>>
>>>*  AFI = 1
>>>
>>>
>>>
>>>*  SAFI = 1
>>>
>>>
>>>
>>>*  Length of Next Hop Address field = 16 (or 32)
>>>
>>>
>>>
>>>*  Next Hop Address = IPv6 address of the next hop
>>>
>>>
>>>
>>>*  NLRI = IPv4 routes
>>>
>>>
>>>
>>>During BGP Capability Advertisement, the PE routers would include the
>>>
>>>following fields in the Capabilities Optional Parameter:
>>>
>>>
>>>
>>>*  Capability Code set to "Extended Next Hop Encoding"
>>>
>>>
>>>
>>>*  Capability Value containing >>
>>>   AFI=2>
>>>
>>>
>>>
>>> As I say, if you were to remove the references to global and 5.3/5.4
>>> which explicitly reference it and bring SAFI 1 into play – there would be
>>> far less concern from my side, I can’t speak for anyone else, but that
>>> would be my feeling
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Andrew
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Robert Raszuk 
>>> *Sent:* Saturday, February 12, 2022 9:37 PM
>>> *To:* Andrew - IETF 
>>> *Cc:* Warren Kumari ; Bocci, Matthew (Nokia - GB) <
>>> matthew.bo...@nokia.com>; draft-ietf-bess-srv6-servi...@ietf.org;
>>> 

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Warren Kumari]

On Sun, Feb 13, 2022 at 11:54 PM Ketan Talaulikar 
wrote:

> Hi Warren/All,
>
> This draft specifies broadly two types of BGP Services over SRv6:
>
> A) VPN Services (L3VPN & EVPN) - Sec 5.1, 5.2 & 6
> B) Global Internet Services - Sec 5.3, 5.4
>
> As explained by my co-author Robert, the operations and mechanisms for VPN
> services are similar to what we've had with MPLS. I believe we are all on
> the same page on this one based on the discussions between Andrew and
> Robert and that there is no new concern as far as (A).
>

Actually, no, I don't think that we are -- if I, as an attacker, somehow
know that VPN x uses MPLS labels Y, that's interesting, but not
particularly valuable -- because of the "fail closed" nature of MPLS (it's
a different protocol, and needs explicit and intentional action to enable
on an interface)  it's really hard for me to "inject" an MPLS packet and
route it into your network. With SRv6, if the SIDs leak, I can construct a
normal v6 packet and route it towards you. Yes, handwave handwave the RFCs
say that you MUST filter at your edges and that the filtering MUST always
be perfect handwave limited domain handwave -- but it's putting a large
amount of faith in operator perfection.

Also, if I, as an attacker get access to a "server" in the provider network
(noc workstation, billing machine, random admin PC, etc), with MPLS it's
very unlikely to be part of the MPLS domain, but  an SRv6 domain is much
more likely to be "squishy" and more likely to encompass parts of the
"enterprise" type systems.

W


>
> Now (B) does bring in filtering aspects (as mentioned in the security
> considerations) to ensure that the SRv6 block that is meant for use
> internal to the operator's network (i.e. SR domain) does not get
> leaked/advertised out from the default table on the Internet Border Router
> (IBR) over to an eBGP peer. This is similar to the precautions that
> operators take today to prevent their infrastructure addresses from being
> leaked to the Internet. The filters in BGP are also accompanied by ACLs at
> the IBRs to prevent traffic destined for those infrastructure IPs from
> entering into the operator network. This is the same in the case of SRv6 as
> well.
>
> I hope that clarifies and we can update the text to convey these aspects
> better.
>
> Thanks,
> Ketan
>
>
> On Sun, Feb 13, 2022 at 12:21 AM Andrew - IETF 
> wrote:
>
>> Hi Robert,
>>
>>
>>
>> 5.3 Also opens the door to SAFI 1 – since you can v6 over v4 using AFI  1
>>  / SAFI 1 using what is defined in RFC8950, in fact, it is explicit.
>>
>>
>>
>> Section 5.3 is titled Global IPv4 over SRv6 core – this correlates with
>> the example in section 6.1 of RFC8950 – which states:
>>
>>
>>
>>
>>
>>The extensions defined in this document may be used as discussed in
>>
>>[RFC5565 ] for the 
>> interconnection of IPv4 islands over an IPv6
>>
>>backbone.  In this application, Address Family Border Routers (AFBRs;
>>
>>as defined in [RFC4925 ]) 
>> advertise IPv4 NLRI in the MP_REACH_NLRI
>>
>>along with an IPv6 next hop.
>>
>>
>>
>>The MP_REACH_NLRI is encoded with:
>>
>>
>>
>>*  AFI = 1
>>
>>
>>
>>*  SAFI = 1
>>
>>
>>
>>*  Length of Next Hop Address field = 16 (or 32)
>>
>>
>>
>>*  Next Hop Address = IPv6 address of the next hop
>>
>>
>>
>>*  NLRI = IPv4 routes
>>
>>
>>
>>During BGP Capability Advertisement, the PE routers would include the
>>
>>following fields in the Capabilities Optional Parameter:
>>
>>
>>
>>*  Capability Code set to "Extended Next Hop Encoding"
>>
>>
>>
>>*  Capability Value containing >
>>   AFI=2>
>>
>>
>>
>> As I say, if you were to remove the references to global and 5.3/5.4
>> which explicitly reference it and bring SAFI 1 into play – there would be
>> far less concern from my side, I can’t speak for anyone else, but that
>> would be my feeling
>>
>>
>>
>> Thanks
>>
>>
>>
>> Andrew
>>
>>
>>
>>
>>
>>
>>
>> *From:* Robert Raszuk 
>> *Sent:* Saturday, February 12, 2022 9:37 PM
>> *To:* Andrew - IETF 
>> *Cc:* Warren Kumari ; Bocci, Matthew (Nokia - GB) <
>> matthew.bo...@nokia.com>; draft-ietf-bess-srv6-servi...@ietf.org;
>> bess-cha...@ietf.org; The IESG ; BESS 
>> *Subject:* Re: Warren Kumari's Discuss on
>> draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
>>
>>
>>
>> Hi Andrew,
>>
>>
>>
>> When I read Warren's note Iooked at this text from section 2 which says:
>>
>>
>>
>> - - -
>>
>>
>>
>>The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix-
>>SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2
>>services.
>>
>>o  SRv6 L3 Service TLV: This TLV encodes Service SID information for
>>   SRv6 based L3 services.  It corresponds to the equivalent
>>   functionality provided by an MPLS Label when received with a Layer
>>   3 service route as defined in [RFC4364] [RFC4659] [RFC8950]
>>   

Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-srv6-services-11: (with COMMENT)

[Murray S. Kucherawy]

Hi Ketan,

On Thu, Feb 17, 2022 at 12:19 AM Ketan Talaulikar 
wrote:

> This document covers several BGP services and has received contributions
> from several people over the past 5 years. The authors will discuss and get
> back on the trimming of the front page list.
>

The limit of 5 is not a hard limit, but we do encourage people to stick to
it.  Mostly I'm just checking in with Martin here to ensure this is seen as
a necessary exception.

-MSK
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Bocci, Matthew (Nokia - GB)]

Hi John

Regarding comment (1), we sent a notice to the IDR WG at WG Adoption time:

[Idr] FW: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02 
(ietf.org)


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 (Nokia - GB) 

Subject: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with 
DISCUSS and COMMENT)
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 https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/



--
DISCUSS:
--

1. The shepherd writeup for this document says “It also received an RTG DIR
review and cross-reviewed with the IDR working group”. Searching in my IDR
inbox and the IDR mailing list archives, I don’t find any sign of the
cross-review — can you please point me to it?

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 split across the
NLRI and the Prefix-SID attribute. What are the potential error modes if the
Prefix-SID attribute should be lost from the route, while the NLRI is retained?

(An obvious way of addressing this particular concern would be to define a new
NLRI type with the desired semantics, instead of creatively repurposing fields
within an existing NLRI type contrary to their definitions. Such an NLRI type
would, for example, presumably state in its specification that if it was
received without an accompanying Prefix-SID attribute, that would constitute an
error.)

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 conversation. It’s still the
case that sometimes (often?) routes are distributed from VPN address families
into the Global Internet table. When this is done, by default, all the path
attributes come along for the ride. Anyone who thinks this is just a
hypothetical case might want to look back to (for example) significant network
outages that were caused around a decade ago by leakage of BGP Attribute 128
(ATTR_SET, RFC 6368) into the global Internet.

The SIDs contained in these if-they-were-to-leak routes potentially give an
attacker a means of directing packets into a VPN customer’s internal network.

4. Speaking of Warren’s DISCUSS, the shepherd’s writeup indicates “solid [WG]
consensus”; however, there doesn’t seem to be consensus even amongst the
authors as to whether Sections 5.3 and 5.4 are appropriate. This is a fairly
fundamental disagreement! An illustration of the disagreement is
https://mailarchive.ietf.org/arch/msg/bess/K1JKxGn19BXALs3rUzUAaGTZi0Y/:

“So I can see why some people may have thought oh since transport in SRv6 comes
for free let's load it with services in an attribute and be done. Yes I can see
that flattening this make it potentially easier (one less SAFI to enable), *but
I am not sure we have reached a broad agreement here.* This comes as a
consequence of moving service prefixes from MP_REACH_NLRI (perhaps new format
and new SAFI) to an attribute.”

(Emphasis added.)

It's of course possible for an author to be in the rough as regards consensus,
just as any other WG contributor, but it's a little unusual, and this
disagreement doesn't even seem to have been previously aired. For this reason,
I have to question the strength of the consensus behind this document, and ask
the WG chairs to weigh in regarding whether consensus on at least this point
needs to be checked before we proceed forward.

5. Finally, I have to question the length of the author list. As I’m sure you
know, the guidance is to limit author lists to no more than five, other than
under unusual circumstances. I would have expected to find an explanation of
the circumstances around the author list of this document in the shepherd
writeup; there is none. (It’s a specific check item in Guidelines to Authors of
Internet-Drafts, https://www.ietf.org/how/ids/guidelines/)

The easiest way to resolve this would be to trim the author list per the
suggestions in RFC 7322 §4.1.1, of course.

Re: [bess] Erik Kline's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS)

[Tony Przygienda]

Ketan, yepp, 5.1.2 is roughly the CUG via ACL, add to it per service
protection (as in some external A can talk to service X but external B
cannot which now starts to push you into fragment the SRv6 "prefix" into
"per service space" if you want to aggregate), multiply that by the
downstream-upstream if you want to cross providers AFAIS (as in BGP
flowspec up/down shorewalling) and you have a pretty nice combinatorial
space. And BTW, source address is easily spoofed given the lack of BCP
implementations in the real world and with source routing technology one
can land those packets in unexpected places via unexpected routes. All that
looks to me like nothing comparable to a leaked internal loopback today
which was my whole point as in fallacy by  faulty analogy.

Unless I lost the thread completely which, given the amount of machinery
fielded by now ;-) could be excusable ...

-- tony


On Thu, Feb 17, 2022 at 11:37 AM Ketan Talaulikar 
wrote:

> Hi Tony,
>
> My apologies, but I am not able to understand your emails entirely. I
> wonder if this text below helps explain:
> https://datatracker.ietf.org/doc/html/rfc8754#section-5.1
>
> Thanks,
> Ketan
>
>
> On Thu, Feb 17, 2022 at 3:40 PM Tony Przygienda 
> wrote:
>
>>
>>
>>
>>>
 But I'm prepared to learn why this wouldn't work or would be somehow
 worse.

>>>
>>> KT> It isn't necessary nor required because SRv6 locators are just IPv6
>>> prefixes that are already covered by IGP/BGP extensions for IPv6 routing. A
>>> provider that uses global IPv6 addresses in their infrastructure (e.g. for
>>> their BGP and other routing sessions, on their router links and loopback,
>>> for DHCP, AAA, etc.) already do routing for those prefixes via IGP/BGP.
>>> These are not advertised (nor leaked) out into the Internet since doing so
>>> can result in attacks on their internal network and infrastructure. They
>>> are protected via BGP configuration to stop leaks and then again by ACLs at
>>> Internet Border Routers to prevent attacks via the data path. This still
>>> remains the case to be done for SRv6 locators - they are similarly the
>>> service provider's "internal" infrastructure.
>>>
>>>
>> I'm confounded by the recent line of reasoning  of SRv6 proponents.  An
>> IPv6 address is NOT a service access point, it's a routable address,
>> history shows us that we can protect against services on the device being
>> attacked through that (though it took some work like proper ICMP handling).
>> SRv6 endpoints here are really service endpoints, unless we have a CUG
>> security architecture in place, how do we protect services here without
>> having CUG style filters on the whole edge?  with SRv6 services giving
>> people a service access point and a tunneling technology where someone via
>> v6 routing can built a tunnel to hit the service is a different beast
>> altogether than protecting reachability (routable addresses) and I fear
>> pretty soon we're looking @ routers going very, very deep into the "IPv6"
>> packet to make sure there aren't some magic options on the packet
>> source-routing it in funky ways towards service endpoints that will accept
>> the packet.
>>
>> --- tony
>>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Erik Kline's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS)

[Ketan Talaulikar]

Hi Tony,

My apologies, but I am not able to understand your emails entirely. I
wonder if this text below helps explain:
https://datatracker.ietf.org/doc/html/rfc8754#section-5.1

Thanks,
Ketan


On Thu, Feb 17, 2022 at 3:40 PM Tony Przygienda  wrote:

>
>
>
>>
>>> But I'm prepared to learn why this wouldn't work or would be somehow
>>> worse.
>>>
>>
>> KT> It isn't necessary nor required because SRv6 locators are just IPv6
>> prefixes that are already covered by IGP/BGP extensions for IPv6 routing. A
>> provider that uses global IPv6 addresses in their infrastructure (e.g. for
>> their BGP and other routing sessions, on their router links and loopback,
>> for DHCP, AAA, etc.) already do routing for those prefixes via IGP/BGP.
>> These are not advertised (nor leaked) out into the Internet since doing so
>> can result in attacks on their internal network and infrastructure. They
>> are protected via BGP configuration to stop leaks and then again by ACLs at
>> Internet Border Routers to prevent attacks via the data path. This still
>> remains the case to be done for SRv6 locators - they are similarly the
>> service provider's "internal" infrastructure.
>>
>>
> I'm confounded by the recent line of reasoning  of SRv6 proponents.  An
> IPv6 address is NOT a service access point, it's a routable address,
> history shows us that we can protect against services on the device being
> attacked through that (though it took some work like proper ICMP handling).
> SRv6 endpoints here are really service endpoints, unless we have a CUG
> security architecture in place, how do we protect services here without
> having CUG style filters on the whole edge?  with SRv6 services giving
> people a service access point and a tunneling technology where someone via
> v6 routing can built a tunnel to hit the service is a different beast
> altogether than protecting reachability (routable addresses) and I fear
> pretty soon we're looking @ routers going very, very deep into the "IPv6"
> packet to make sure there aren't some magic options on the packet
> source-routing it in funky ways towards service endpoints that will accept
> the packet.
>
> --- tony
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Erik Kline's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS)

[Tony Przygienda]

>
>> But I'm prepared to learn why this wouldn't work or would be somehow
>> worse.
>>
>
> KT> It isn't necessary nor required because SRv6 locators are just IPv6
> prefixes that are already covered by IGP/BGP extensions for IPv6 routing. A
> provider that uses global IPv6 addresses in their infrastructure (e.g. for
> their BGP and other routing sessions, on their router links and loopback,
> for DHCP, AAA, etc.) already do routing for those prefixes via IGP/BGP.
> These are not advertised (nor leaked) out into the Internet since doing so
> can result in attacks on their internal network and infrastructure. They
> are protected via BGP configuration to stop leaks and then again by ACLs at
> Internet Border Routers to prevent attacks via the data path. This still
> remains the case to be done for SRv6 locators - they are similarly the
> service provider's "internal" infrastructure.
>
>
I'm confounded by the recent line of reasoning  of SRv6 proponents.  An
IPv6 address is NOT a service access point, it's a routable address,
history shows us that we can protect against services on the device being
attacked through that (though it took some work like proper ICMP handling).
SRv6 endpoints here are really service endpoints, unless we have a CUG
security architecture in place, how do we protect services here without
having CUG style filters on the whole edge?  with SRv6 services giving
people a service access point and a tunneling technology where someone via
v6 routing can built a tunnel to hit the service is a different beast
altogether than protecting reachability (routable addresses) and I fear
pretty soon we're looking @ routers going very, very deep into the "IPv6"
packet to make sure there aren't some magic options on the packet
source-routing it in funky ways towards service endpoints that will accept
the packet.

--- tony
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10

[Zhuangshunwan]

Hi all,

I agree with Vasilenko and Ketan.

The meaning of the label is given by the encapsulation. According to 
RFC8365[https://datatracker.ietf.org/doc/html/rfc8365], there are already a 
precedent for using the label field to carry VNI and without the new AFI/SAFI, 
and there are a large number of implementations and deployments that prove this 
scheme is feasible.

Thanks,
Shunwan

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, February 17, 2022 4:20 PM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) 
Cc: int-...@ietf.org; Vasilenko Eduard ; Ron 
Bonica ; last-c...@ietf.org; Warren Kumari 
; bess@ietf.org; draft-ietf-bess-srv6-services@ietf.org
Subject: Re: [bess] [Last-Call] Intdir telechat review of 
draft-ietf-bess-srv6-services-10

+1


On Thu, Feb 17, 2022 at 1:11 PM Rabadan, Jorge (Nokia - US/Sunnyvale) 
mailto:jorge.raba...@nokia.com>> wrote:
I agree with Vasilenko.

The meaning of the label is given by the encapsulation, e.g. for the EVPN 
family, label=VNI if the bgp encapsulation extended community indicates VXLAN, 
and label=MPLS-label if the encapsulation indicates MPLS.

In this document, the label is a transposed function if the encapsulation 
indicates SRv6 (given by the SRv6 Services TLV). So it is consistent with the 
approach used by SAFIs that support different identifiers in the label field.

Thanks.
Jorge

From: Vasilenko Eduard 
mailto:vasilenko.edu...@huawei.com>>
Date: Thursday, February 17, 2022 at 8:30 AM
To: Warren Kumari mailto:war...@kumari.net>>, Ron Bonica 
mailto:rbon...@juniper.net>>
Cc: 
draft-ietf-bess-srv6-services@ietf.org
 
mailto:draft-ietf-bess-srv6-services@ietf.org>>,
 last-c...@ietf.org 
mailto:last-c...@ietf.org>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
int-...@ietf.org 
mailto:int-...@ietf.org>>
Subject: RE: [bess] [Last-Call] Intdir telechat review of 
draft-ietf-bess-srv6-services-10
Hi all,
About this point:
1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This
is surprising because MPLS appears nowhere in the forwarding plane. Maybe we
shouldn't advertise an MPLS label?

I have seen in some BESS documents that this field is called “Service Label”, 
not “MPLS label”.
Because MPLS does not exist in VxLAN too, but the same label is used.
Hence, 1) is easy to resolve. It is just a terminology correction that makes 
sense in principle for all BESS documents.
Eduard
From: BESS [mailto:bess-boun...@ietf.org] On 
Behalf Of Warren Kumari
Sent: Thursday, February 17, 2022 4:37 AM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: 
draft-ietf-bess-srv6-services@ietf.org;
 last-c...@ietf.org; 
bess@ietf.org; int-...@ietf.org
Subject: Re: [bess] [Last-Call] Intdir telechat review of 
draft-ietf-bess-srv6-services-10



On Mon, Feb 14, 2022 at 11:20 AM Ron Bonica via Datatracker 
mailto:nore...@ietf.org>> wrote:
Reviewer: Ron Bonica
Review result: Not Ready

I am an assigned INT directorate reviewer for draft-ietf-bess-srv6-services.txt.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
.

Major issues:

1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This
is surprising because MPLS appears nowhere in the forwarding plane. Maybe we
shouldn't advertise an MPLS label?

2) In Section 3.2.1 the draft says:

  BGP speakers that do not support this specification may misinterpret,
   on the reception of an SRv6-based BGP service route update, the part
   of the SRv6 SID encoded in MPLS label field(s) as MPLS label values
   for MPLS-based services.  Implementations supporting this
   specification SHOULD provide a mechanism to control the advertisement
   of SRv6-based BGP service routes on a per-neighbor and per-service
   basis.  The details of deployment designs and implementation options
   are outside the scope of this document.

Much thanks to Ron for this OpsDir review -- I'd completely missed the above 
points, and they are important to address.

W


s/BGP speakers that do not support this specification/Legacy BGP implementations

It seems that this isn't backwards compatible unless either:

- the SHOULD becomes a MUST
- the mechanism is described in this document

3) I concur with Warren Kumari's DISCUSS



--
last-call mailing list
last-c...@ietf.org

Re: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10

[Ketan Talaulikar]

+1


On Thu, Feb 17, 2022 at 1:11 PM Rabadan, Jorge (Nokia - US/Sunnyvale) <
jorge.raba...@nokia.com> wrote:

> I agree with Vasilenko.
>
>
>
> The meaning of the label is given by the encapsulation, e.g. for the EVPN
> family, label=VNI if the bgp encapsulation extended community indicates
> VXLAN, and label=MPLS-label if the encapsulation indicates MPLS.
>
>
>
> In this document, the label is a transposed function if the encapsulation
> indicates SRv6 (given by the SRv6 Services TLV). So it is consistent with
> the approach used by SAFIs that support different identifiers in the label
> field.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Vasilenko Eduard 
> *Date: *Thursday, February 17, 2022 at 8:30 AM
> *To: *Warren Kumari , Ron Bonica 
> *Cc: *draft-ietf-bess-srv6-services@ietf.org <
> draft-ietf-bess-srv6-services@ietf.org>, last-c...@ietf.org <
> last-c...@ietf.org>, bess@ietf.org , int-...@ietf.org <
> int-...@ietf.org>
> *Subject: *RE: [bess] [Last-Call] Intdir telechat review of
> draft-ietf-bess-srv6-services-10
>
> Hi all,
>
> About this point:
>
> 1) In Section 3.2.1, the draft transposes bits into the MPLS Label field.
> This
> is surprising because MPLS appears nowhere in the forwarding plane. Maybe
> we
> shouldn't advertise an MPLS label?
>
>
>
> I have seen in some BESS documents that this field is called “Service
> Label”, not “MPLS label”.
>
> Because MPLS does not exist in VxLAN too, but the same label is used.
>
> Hence, 1) is easy to resolve. It is just a terminology correction that
> makes sense in principle for all BESS documents.
>
> Eduard
>
> *From:* BESS [mailto:bess-boun...@ietf.org] *On Behalf Of *Warren Kumari
> *Sent:* Thursday, February 17, 2022 4:37 AM
> *To:* Ron Bonica 
> *Cc:* draft-ietf-bess-srv6-services@ietf.org; last-c...@ietf.org;
> bess@ietf.org; int-...@ietf.org
> *Subject:* Re: [bess] [Last-Call] Intdir telechat review of
> draft-ietf-bess-srv6-services-10
>
>
>
>
>
>
>
> On Mon, Feb 14, 2022 at 11:20 AM Ron Bonica via Datatracker <
> nore...@ietf.org> wrote:
>
> Reviewer: Ron Bonica
> Review result: Not Ready
>
> I am an assigned INT directorate reviewer for
> draft-ietf-bess-srv6-services.txt.
> These comments were written primarily for the benefit of the Internet Area
> Directors. Document editors and shepherd(s) should treat these comments
> just
> like they would treat comments from any other IETF contributors and resolve
> them along with any other Last Call comments that have been received. For
> more
> details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/
> .
>
> Major issues:
>
> 1) In Section 3.2.1, the draft transposes bits into the MPLS Label field.
> This
> is surprising because MPLS appears nowhere in the forwarding plane. Maybe
> we
> shouldn't advertise an MPLS label?
>
> 2) In Section 3.2.1 the draft says:
>
>   BGP speakers that do not support this specification may misinterpret,
>on the reception of an SRv6-based BGP service route update, the part
>of the SRv6 SID encoded in MPLS label field(s) as MPLS label values
>for MPLS-based services.  Implementations supporting this
>specification SHOULD provide a mechanism to control the advertisement
>of SRv6-based BGP service routes on a per-neighbor and per-service
>basis.  The details of deployment designs and implementation options
>are outside the scope of this document.
>
>
>
> Much thanks to Ron for this OpsDir review -- I'd completely missed the
> above points, and they are important to address.
>
>
>
> W
>
>
>
>
>
> s/BGP speakers that do not support this specification/Legacy BGP
> implementations
>
> It seems that this isn't backwards compatible unless either:
>
> - the SHOULD becomes a MUST
> - the mechanism is described in this document
>
> 3) I concur with Warren Kumari's DISCUSS
>
>
>
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>
>
>
>
> --
>
> The computing scientist’s main challenge is not to get confused by the
> complexities of his own making.
>   -- E. W. Dijkstra
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Ketan Talaulikar]

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
implementations that are enabled for and support SRv6. We will still need
the policy configuration knobs for more granular control and filtering
mechanisms. So, IMHO, these mechanisms are complementary.

That said, let us go through the normal WG review process and I see no
issue in extending with capability exchange in a future document such as
yours.

Thanks,
Ketan



On Thu, Feb 17, 2022 at 12:15 PM  wrote:

> 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
>
> One solution(if new AFI/SAFI is not defined) we proposed in the draft is
> to define a new BGP capability code for for SRv6-based BGP service
> capability, and then SRv6 service routes would only be exchanged between
> devices that support it based on this capability.
>
> Do you think this is a possible solution?
>
>
> Regards,
>
> Yao
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Ketan Talaulikar]

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, 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 https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>
>
>
> --
> DISCUSS:
> --
>
> 1. The shepherd writeup for this document says “It also received an RTG DIR
> review and cross-reviewed with the IDR working group”. Searching in my IDR
> inbox and the IDR mailing list archives, I don’t find any sign of the
> cross-review — can you please point me to it?
>
> 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 split across
> the
> NLRI and the Prefix-SID attribute. What are the potential error modes if
> the
> Prefix-SID attribute should be lost from the route, while the NLRI is
> retained?
>
> (An obvious way of addressing this particular concern would be to define a
> new
> NLRI type with the desired semantics, instead of creatively repurposing
> fields
> within an existing NLRI type contrary to their definitions. Such an NLRI
> type
> would, for example, presumably state in its specification that if it was
> received without an accompanying Prefix-SID attribute, that would
> constitute an
> error.)
>

KT> This document follows the approach similar as taken for extending MPLS
EVPN RFC7432 by RFC8365.


>
> 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 conversation. It’s still
> the
> case that sometimes (often?) routes are distributed from VPN address
> families
> into the Global Internet table. When this is done, by default, all the path
> attributes come along for the ride. Anyone who thinks this is just a
> hypothetical case might want to look back to (for example) significant
> network
> outages that were caused around a decade ago by leakage of BGP Attribute
> 128
> (ATTR_SET, RFC 6368) into the global Internet.
>
> The SIDs contained in these if-they-were-to-leak routes potentially give an
> attacker a means of directing packets into a VPN customer’s internal
> network.
>

KT> I believe we are getting now into implementation aspects when you bring
up handling of attributes during redistribution from VPN tables into the
default table. We can add some text in the security considerations to
discuss this.


>
> 4. Speaking of Warren’s DISCUSS, the shepherd’s writeup indicates “solid
> [WG]
> consensus”; however, there doesn’t seem to be consensus even amongst the
> authors as to whether Sections 5.3 and 5.4 are appropriate. This is a
> fairly
> fundamental disagreement! An illustration of the disagreement is
> https://mailarchive.ietf.org/arch/msg/bess/K1JKxGn19BXALs3rUzUAaGTZi0Y/:
>
> “So I can see why some people may have thought oh since transport in SRv6
> comes
> for free let's load it with services in an attribute and be done. Yes I
> can see
> that flattening this make it potentially easier (one less SAFI to enable),
> *but
> I am not sure we have reached a broad agreement here.* This comes as a
> consequence of moving service prefixes from MP_REACH_NLRI (perhaps new
> format
> and new SAFI) to an attribute.”
>
> (Emphasis added.)
>
> It's of course possible for an author to be in the rough as regards
> consensus,
> just as any other WG contributor, but it's a little unusual, and this
> disagreement doesn't even seem to have been previously aired. For this
> reason,
> I have to question the strength of the consensus behind this document, and
> ask
> the WG chairs to weigh in regarding whether consensus on at least this
> point
> needs to be checked before we proceed forward.
>

KT> My co-author Robert has clarified. One other way to look at consensus
is based on the multivendor implementations, interoperability, and
deployments.


>
> 5. Finally, I have to question the length of the author list. As I’m sure
> you
> know, the guidance is to limit author lists to no more than five, other
> than
> under unusual circumstances. I would have expected to find an explanation
> of
> the circumstances around the author list of this document in the shepherd
> 

Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-srv6-services-11: (with COMMENT)

[Ketan Talaulikar]

Hi Murray,

Thanks for your review.

This document covers several BGP services and has received contributions
from several people over the past 5 years. The authors will discuss and get
back on the trimming of the front page list.

Thanks,
Ketan


On Thu, Feb 17, 2022 at 11:44 AM Murray Kucherawy via Datatracker <
nore...@ietf.org> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-bess-srv6-services-11: No Objection
>
> 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 https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>
>
>
> --
> COMMENT:
> --
>
> Just to double-check: Are we okay with having seven authors on this
> document
> when the guidelines specify a limit of five?
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Erik Kline's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS)

[Ketan Talaulikar]

Hi Erik,

Thanks for your review and please check inline below for responses.


On Thu, Feb 17, 2022 at 11:33 AM Erik Kline via Datatracker <
nore...@ietf.org> wrote:

> Erik Kline 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 https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>
>
>
> --
> DISCUSS:
> --
>
> I have little to add to the DISCUSSes held by others beyond my support.
>
> However, I would like to discuss having SRv6 control plane information,
> i.e.
> SIDs and their behaviours etc., being isolated by associating it with
> a separate SAFI.  Any other protocol element that needs to refer to such
> information can make reference to it through context-appropriate
> extensions.
>

KT> This is what the draft proposes. We have existing BGP services (e.g.
L3VPN & EVPN) and we are introducing extensions for signaling of SRv6
specific context for them.


>
> {AFI=IPv6, SAFI=unicast} is a valid way to advertise an SRv6 locator
> prefix,
> for example, as that's just IPv6 forwarding information.  If SRv6-specific
> information where separately advertised as {AFI=IPv6, SAFI=SRv6} then I
> suspect it would be simpler to filter out that information, detect leaks,
> and generally help the SRv6 domain fail closed more easily.
>

KT> This document does not cover nor discuss signaling of SRv6 locator
prefixes. That is already done today by IGPs with or without summarization
(or where necessary in multi-AS networks by BGP for IPv6 RFC 2545) and this
is all within a provider network. Nothing new is required for that.


> But I'm prepared to learn why this wouldn't work or would be somehow worse.
>

KT> It isn't necessary nor required because SRv6 locators are just IPv6
prefixes that are already covered by IGP/BGP extensions for IPv6 routing. A
provider that uses global IPv6 addresses in their infrastructure (e.g. for
their BGP and other routing sessions, on their router links and loopback,
for DHCP, AAA, etc.) already do routing for those prefixes via IGP/BGP.
These are not advertised (nor leaked) out into the Internet since doing so
can result in attacks on their internal network and infrastructure. They
are protected via BGP configuration to stop leaks and then again by ACLs at
Internet Border Routers to prevent attacks via the data path. This still
remains the case to be done for SRv6 locators - they are similarly the
service provider's "internal" infrastructure.

Thanks,
Ketan
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess