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

[Gyan Mishra]

Hi Ketan

I agree with you that for B section 5.3 and 5.4  IPv4 and IPv6 global table
over SRv6 core does bring filtering aspects to the security considerations
to ensure that the operators SRv6 infrastructure block does not get leaked
from the global table to the internet over eBGP peer as well as
infrastructure ACLs to prevent access to SRv6 infrastructure IPs per RFC
8402 section 8.2.

I don’t see any other security issues other than what is described in RFC
8402 section 8.2.

I agree as well that this security consideration is no different then
precautions taken today on an operators network.

Kind Regards

Gyan

On Mon, Feb 14, 2022 at 12:55 AM 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).
>
> 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]
>>   [RFC9136].  Some SRv6 Endpoint behaviors which MAY be encoded, but
>>   not limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc.
>>
>>o  SRv6 L2 Service TLV: This TLV encodes Service SID information for
>>   SRv6 based L2 services.  It corresponds to the equivalent
>>   functionality provided by an MPLS Label1 for Ethernet VPN (EVPN)
>>   Route-Types as defined in 

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

[Ketan Talaulikar]

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).

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]
>   [RFC9136].  Some SRv6 Endpoint behaviors which MAY be encoded, but
>   not limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc.
>
>o  SRv6 L2 Service TLV: This TLV encodes Service SID information for
>   SRv6 based L2 services.  It corresponds to the equivalent
>   functionality provided by an MPLS Label1 for Ethernet VPN (EVPN)
>   Route-Types as defined in [RFC7432].  Some SRv6 Endpoint behaviors
>   which MAY be encoded, but not limited to, are End.DX2, End.DX2V,
>   End.DT2U, End.DT2M etc.
>
>When an egress PE is enabled for BGP Services over SRv6 data-plane,
>it signals one or more SRv6 Service SIDs enclosed in SRv6 Service
>TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs
>defined in [RFC4760] [RFC4659] [RFC8950] [RFC7432] [RFC4364]
>[RFC9136] where applicable as described in Section 5 and Section 6.
>
>The support for BGP Multicast VPN (MVPN) Services [RFC6513] with SRv6
>is outside the scope of this document.
>
>
>
> - - -
>
>
>
> This limits the overlay signalling to non global SAFIs mainly SAFI 128 and
> SAFI 70.
>
>
>
> To your note SAFI 4 is private and never exchanged in the wild. Also SAFI
> 2 is multicast which is out of scope of this draft.
>
>
>

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Anoop Ghanwani]

Thanks Luc.

I have reviewed the changes and they look good to me.

On Sat, Feb 12, 2022 at 10:45 AM Luc André Burdet 
wrote:

> Hi Anoop,
>
> Thanks for your detailed review, I have posted -04 addressing these
> comments.
>
>
>
> >>Timestamp Fractional Seconds (17 bits)
>
> This threw me off for a bit...
>
> >> Now that I double check, the figure is wrong!  It uses only 7 bits for
> the Type which looks like it should be 8 bits.  So it looks like Timestamp
> Fractional Seconds should be 16 bits.
>
> ...but you actually hit onto a critical misalignment in the figure !
>
>
>
> I have moved the whole description section up into the encoding/extcomm as
> descriptive text of the fields themselves. Nice catch, thank you !
>
>
>
> Regards,
>
> Luc André
>
>
>
> Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254
> 4814
>
>
>
>
>
> *From: *Anoop Ghanwani 
> *Date: *Friday, February 4, 2022 at 12:50
> *To: *Bocci, Matthew (Nokia - GB) 
> *Cc: *draft-ietf-bess-evpn-fast-df-recov...@ietf.org <
> draft-ietf-bess-evpn-fast-df-recov...@ietf.org>, bess@ietf.org <
> bess@ietf.org>, bess-cha...@ietf.org 
> *Subject: *Re: [bess] WGLC, IPR and Implementation Poll for
> draft-ietf-bess-evpn-fast-df-recovery-03
>
> I support publication of the document as an RFC.  However, I think there
> are some editorial nits that need to be addressed (see below).
>
>
>
> Anoop
>
>
>
> ==
>
>
>
> Abstract
>
>
>
> performed via a simple signaling between the recovered PE
>and each PEs in the multi-homing group.
> ->
> performed via simple signaling between the recovered PE
>and each of the other PEs in the multi-homing group.
>
>
>
>
>
> Multiple sections
>
>
>
> multi-homing Ethernet Segment ->
>
> multi-homed Ethernet Segment
>
>
>
> Ethernet-Segment ->
>
> Ethernet Segment
>
>
>
> There are some instances of use of ES (section 3.2).  Either ES should be
> spelled out and used throughout or, which is what I would do, replace the 2
> instances of ES in Section 3.2 with Ethernet Segment.
>
> It would also be good to provide captions for all figures since it makes
> it easy to reference.
>
>
>
> Section 1
>
> EVPN solution [RFC7432]
> ->
> The EVPN specification [RFC7432]
>
>
>
> and it is performed via a
>simple signaling between the recovered PE and each PE in the multi-
>homing group.
> ->
> and it is performed via
>simple signaling between the recovered PE and each of the other PEs in
> the multi-
>homing group.
>
>
>
>
>
> Section 2
>
> The current state of art (Highest Random Weight)
> ->
> The current state of art HRW (Highest Random Weight)
>
>
>
> duplication of DF roles for a give VLAN is possible.
> ->
> duplication of DF roles for a given VLAN is possible.
>
>
>
>
>
> Section 3.1
>
>
>-  A simple uni-directional signaling is all needed
> ->
>-  A simple uni-directional signaling is all that is needed
>
>
> -  (e.g .NTP, PTP, etc.)
> ->
> -  (e.g. NTP, PTP, etc.)
>
>
>
>
>
> Section 3.2
>
> It would be good to explicitly explain the fields below the figure, e.g.
> Timestamp Seconds (32 bits): ...
> Timestamp Fractional Seconds (17 bits): ... (provide details on how this
> part is created)
> If this is omitted because it is in some other doc, then provide a
> reference.
>
>
>
> [Looks like the figure is wrong about length for Timestamp Fractional
> Seconds which is why it would help to have a description as above.]
>
>
>
> PEs in the ES [there are 2 instances]
>
> ->
>
> PEs attached to the Ethernet Segment
>
>
>
> want the DF type be of HRW
>
> ->
> want the DF type to be HRW
>
>
>
> "The use
>of a 32-bit seconds and 16-bit fractional seconds yields adequate
>precision of 15 microseconds (2^-16 s)."
>
> The figure shows 17 bits for fractional seconds.  Now that I double check,
> the figure is wrong!  It uses only 7 bits for the Type which looks like it
> should be 8 bits.  So it looks like Timestamp Fractional Seconds should be
> 16 bits.
>
>
>
>
>
> Section 3.4
>
>-  PE2, it starts its 3sec peering timer as per RFC7432
> ->
>-  PE2, starts its 3 sec peering timer as per RFC7432
>
>
>
> [RFC7432] aims of favouring traffic black hole over duplicate traffic
> (Missing period at end of sentence.)
>
>
>
> Spell out first use of NDF.
>
>
>
> becomes a no-op
> ->
> becomes a non-issue.
>
>
> The usage of
>SCT approach remedies to the exposed problem with the usage of
>peering timer.  The 3 seconds timer window is shorthen to few
>milliseconds.
> ->
> The usage of
>SCT approach remedies the problem with the usage of the
>peering timer.  The 3 second timer window is shortened to a few
>milliseconds.
>
>
>
>
>
> Section 3.5
>
>
>
> modulus based
> ->
> modulo-based
>
>
>
> running an baseline DF election
> ->
> running a baseline DF election
>
>
>
> shall simply discard unrecognized new SCT BGP extended community.
> ->
> will simply disregard the new SCT BGP extended community.
>
>
>
> "...all PEs in the Ethernet-Segment may revert back to the 

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

[Gyan Mishra]

Hi Robert

I am not saying MPLS is sent in SAFI 1.

Let me try to explain.

In the use case we are discussing in section 5.3 and 5.4  is when there is
no VPN overlay as the PE-CE AC sits in the global routing table native BGP
unlabeled prefixes and the label stack is just a single label deep with the
topmost transport label.  In that scenario 5.4 is IPv6 unicast SAFI 1 NLRI
is carried over an IPv6 core transport label LSP.

In the MPLS analogy use case of global table routing  there is no bottom of
stack service label as is required for L3 VPN where we have a label as we
have an VPN overlay present. So the BGP routes are carried in the BGP RIB
natively in the global routing table unlabeled.  So that is what we are
talking about for the 5.4 use case now with SRv6 no VPN label and so NO
SRv6 L3 service TLV encoded in BGP prefix SID attribute.  The MPLS label
stack L3 VPN service label in SRv6 scenario in FUNCT field is now not
present with SAFI 1 IPV6 Unicast “Global IPv6 over IPv6 core”.

In section 5.1 and 5.2 BGP-LU SAFI 4 is required
because the SRv6 L3 Service TLV for L3 VPN overlay service route must
encoded in BGP prefix SID as it must be sent as labeled.

So in section 5.3 Global IPv4 over SRv6 core is similar to a 6PE RFC 4798
scenario analogy where the IPv6 prefixes are carried over an IPv4 core with
IPv4 signaled LSP with additional bottom of stack label as IPV6 prefixes
are labeled with BGP-LU SAFI 4  2/4 and must be sent labeled due to PHP
requirement as stated in RFC 4798.

So we have in section 5.3 the same scenario as 6PE but now over SRv6 using
RFC 8950 IPv6 next hop encoding to carry the BGP LU SAFI 4 labeled IPv4
prefixes.

So in 5.3 that section would need to be updated to state that BGP-LU
labeled IPv4 prefixes is necessary with encoded SRv6 L3 service TLV in BGP
prefix SID attribute so the IPv4 prefixes can be sent as labeled prefixes
over SRv6 core.

Upon exiting the SRv6 domain at the egress PE the outer IPv6 header is
removed that contains the SRv6 programming endpoint behavior semantics with
native payload forwarded by the PE to the CE similar to MPLS label
disposition at egress PE exiting the domain.

So here no issue with filtering as once you exit the domain the SRv6
forwarding plane semantics are stripped from the packet.

Hopefully this clarifies.

Many Thanks,

Gyan

On Sun, Feb 13, 2022 at 7:48 AM Robert Raszuk  wrote:

> Gyan,
>
> MPLS is never sent in SAFI 1.
>
> Thx,
> R.
>
> On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra  wrote:
>
>> Hi Robert
>>
>> On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk  wrote:
>>
>>> Gyan,
>>>
>>> Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
 encoding.  In this case using GRT transport underlay layer now carry’s the
 customer routes and that is what Warren and Andrew concern is as far as BGP
 leaks.

>>>
>>> I would have the same concern so would VPN customers. No one is selling
>>> L2 or L3 VPN service to them distributing their reachability in the global
>>> routing table. They can do that all by themselves and there is lot's of
>>> really solid tools or products to do that already without being locked to a
>>> single telco.
>>>
>>
>> Gyan> MPLS provides the capability for GRT native routing  SAFI 1 as well
>> as SAFI 128, so in my opinion both should be supported by SRV6 as operators
>> look to use SRv6 for a variety of use cases. That’s my point as there
>> should be complete feature parity between MPLS and SRv6 as to AFI / SAFI
>> support.  Global Internet routing would not be the best use case for SAFI 1
>> GRT due to the attack vector - agreed, but enterprise networks with
>> internal customers where there is a trust level is a huge use case.
>>
>>>
>>> So when GRT is used the same edge filtering protection mechanisms used
 today for MPLS and SR-MPLS would apply to SRv6 for GRT use case.

>>>
>>> Not possible. It is not about filtering ... it is all about using
>>> globally routable SAFI vs private SAFIs to distribute customer's
>>> reachability, IMO that should still be OTT only.
>>>
>>
>> Gyan> As SRv6 source node is requirement to encapsulation with IPv6
>> outer header and decapsulation at egress PE for SRv6-BE and SRv6-TE path
>> steering the security issue brought up related to 5.3 and 5.4 is not an
>> issue requiring filtering per RFC 8402.  So routable and private SAFI
>> scenario would be the same now due to encapsulation overlay for both.  Do
>> you agree ?
>>
>>>
>>> I don’t think we are saying 5.3 or 5.4 should not be allowed but just to
 tighten up verbiage as far securing the domain.

>>>
>>> BGP filtering or policy is in hands of many people. As has been proven
>>> you can not tighten them strong enough not to leak. The only natural way to
>>> tighten them is to use different plane to distribute private information
>>> what in this context means at least different BGP SAFI.
>>>
>>> So no - I do not agree with your observations.
>>>
>>
>>Gyan> I am not promoting 

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

[Robert Raszuk]

Hi Andrew,

Most of what you say is true, so is my statement that MPLS labels are never
carried in SAFI 1 in BGP.

However, let me explain why I think a bit different view may work better
here ...

First let's clearly divide MPLS labels used for transport (which create
actual LSPs) from MPLS labels used for services (which are used to demux
packets at the egress PEs into appropriate context tables - typically VRFs
but not only (can be directly CEs too))

So the draft in the discussion is about overlay VPN services and therefore
the analogy made to MPLS labels are only related to SAFI 128 or SAFI 70.
Nothing here travels in unicast SAFI 1 nor in any IGP. So in the context of
this draft we should never allow to put the new attribute neither in SAFI 1
nor even SAFI 4.

But now comes the part which makes this discussion mangled ... unlike in
MPLS where LSPs need to be signalled in SRv6 you do not need any signalling
and IPv6 reachability is all that is needed for transport. So in SRv6 what
is in MPLS world signalled in LDP or RSVP-TE or SAFI 4 is indeed carried in
AFI 2 & SAFI 1.  /* SAFI 4 comes helpful when you build hierarchical LSPs
but in this discussion it is completely irrelevant. */

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.

Thx,
R.





On Sun, Feb 13, 2022 at 2:50 PM Andrew - IETF 
wrote:

> +1
>
>
>
> This is something I was a little confused about since its been referenced
> in these emails time and again, and I was wondering if I had missed
> something, but, I’ve checked to be 100%  certain, RFC8950 which is what
> this document refers to explicitly states that the NLRI encoding  of the
> destination must not change – and since the IPv4 NLRI leaves no provision
> for labels – and  makes it clear that SAFI 4 is used for MPLS – MPLS
> doesn’t fall into SAFI 1.
>
> In fact, what is described in 5.3 only results from the nature of SRv6, it
> states:
>
>
>
>SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.  The
>
>SRv6 Endpoint behavior of the SRv6 SID is entirely up to the
>
>originator of the advertisement.  In practice, the SRv6 Endpoint
>
>behavior is End.DX4 or End.DT4.
>
>
>
> Since 5.3 can operate in SAFI 1 (it explicitly refers to Global IPv4 over
> SRv6 core – which by correlation to 8950 is SAFI 1) and based on the
> wording of the above, this actually puts MPLS type functionality into SAFI
> 1 where it never was before, by using the SID as a normal address which is
> then dealt with as a SID inside the domain.  But no – this is not providing
> equal functionality for MPLS – this is extending MPLS style functionality
> into SAFI 1, which, if my reading of Warren’s discuss is accurate, is
> pretty much the essence of the problem.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, February 13, 2022 3:48 PM
> *To:* Gyan Mishra 
> *Cc:* Andrew - IETF ; BESS ;
> Bocci, Matthew (Nokia - GB) ; The IESG <
> i...@ietf.org>; Warren Kumari ; bess-cha...@ietf.org;
> draft-ietf-bess-srv6-servi...@ietf.org
> *Subject:* Re: [bess] Warren Kumari's Discuss on
> draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
>
>
>
> Gyan,
>
>
>
> MPLS is never sent in SAFI 1.
>
>
>
> Thx,
> R.
>
>
>
> On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra  wrote:
>
> Hi Robert
>
>
>
> On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk  wrote:
>
> Gyan,
>
>
>
> Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
> encoding.  In this case using GRT transport underlay layer now carry’s the
> customer routes and that is what Warren and Andrew concern is as far as BGP
> leaks.
>
>
>
> I would have the same concern so would VPN customers. No one is selling L2
> or L3 VPN service to them distributing their reachability in the global
> routing table. They can do that all by themselves and there is lot's of
> really solid tools or products to do that already without being locked to a
> single telco.
>
>
>
> Gyan> MPLS provides the capability for GRT native routing  SAFI 1 as well
> as SAFI 128, so in my opinion both should be supported by SRV6 as operators
> look to use SRv6 for a variety of use cases. That’s my point as there
> should be complete feature parity between MPLS and SRv6 as to AFI / SAFI
> support.  Global Internet routing would not be the best use case for SAFI 1
> GRT due to the attack vector - agreed, but enterprise networks with
> internal customers where there is a trust level is a huge use case.
>
>
>
> So when GRT is used the same edge filtering protection mechanisms used
> today for MPLS and SR-MPLS would apply to SRv6 for GRT use case.
>
>
>
> Not possible. It is not about 

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

[Andrew - IETF]

+1

This is something I was a little confused about since its been referenced in 
these emails time and again, and I was wondering if I had missed something, 
but, I’ve checked to be 100%  certain, RFC8950 which is what this document 
refers to explicitly states that the NLRI encoding  of the destination must not 
change – and since the IPv4 NLRI leaves no provision for labels – and  makes it 
clear that SAFI 4 is used for MPLS – MPLS doesn’t fall into SAFI 1.
In fact, what is described in 5.3 only results from the nature of SRv6, it 
states:

   SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.  The
   SRv6 Endpoint behavior of the SRv6 SID is entirely up to the

   originator of the advertisement.  In practice, the SRv6 Endpoint

   behavior is End.DX4 or End.DT4.

Since 5.3 can operate in SAFI 1 (it explicitly refers to Global IPv4 over SRv6 
core – which by correlation to 8950 is SAFI 1) and based on the wording of the 
above, this actually puts MPLS type functionality into SAFI 1 where it never 
was before, by using the SID as a normal address which is then dealt with as a 
SID inside the domain.  But no – this is not providing equal functionality for 
MPLS – this is extending MPLS style functionality into SAFI 1, which, if my 
reading of Warren’s discuss is accurate, is pretty much the essence of the 
problem.

Thanks

Andrew

From: Robert Raszuk 
Sent: Sunday, February 13, 2022 3:48 PM
To: Gyan Mishra 
Cc: Andrew - IETF ; BESS ; Bocci, 
Matthew (Nokia - GB) ; The IESG ; 
Warren Kumari ; bess-cha...@ietf.org; 
draft-ietf-bess-srv6-servi...@ietf.org
Subject: Re: [bess] Warren Kumari's Discuss on 
draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

Gyan,

MPLS is never sent in SAFI 1.

Thx,
R.

On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:
Hi Robert

On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Gyan,

Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop encoding.  
In this case using GRT transport underlay layer now carry’s the customer routes 
and that is what Warren and Andrew concern is as far as BGP leaks.

I would have the same concern so would VPN customers. No one is selling L2 or 
L3 VPN service to them distributing their reachability in the global routing 
table. They can do that all by themselves and there is lot's of really solid 
tools or products to do that already without being locked to a single telco.

Gyan> MPLS provides the capability for GRT native routing  SAFI 1 as well as 
SAFI 128, so in my opinion both should be supported by SRV6 as operators look 
to use SRv6 for a variety of use cases. That’s my point as there should be 
complete feature parity between MPLS and SRv6 as to AFI / SAFI support.  Global 
Internet routing would not be the best use case for SAFI 1 GRT due to the 
attack vector - agreed, but enterprise networks with internal customers where 
there is a trust level is a huge use case.

So when GRT is used the same edge filtering protection mechanisms used today 
for MPLS and SR-MPLS would apply to SRv6 for GRT use case.

Not possible. It is not about filtering ... it is all about using globally 
routable SAFI vs private SAFIs to distribute customer's reachability, IMO that 
should still be OTT only.

Gyan> As SRv6 source node is requirement to encapsulation with IPv6 outer 
header and decapsulation at egress PE for SRv6-BE and SRv6-TE path steering the 
security issue brought up related to 5.3 and 5.4 is not an issue requiring 
filtering per RFC 8402.  So routable and private SAFI scenario would be the 
same now due to encapsulation overlay for both.  Do you agree ?

I don’t think we are saying 5.3 or 5.4 should not be allowed but just to 
tighten up verbiage as far securing the domain.

BGP filtering or policy is in hands of many people. As has been proven you can 
not tighten them strong enough not to leak. The only natural way to tighten 
them is to use different plane to distribute private information what in this 
context means at least different BGP SAFI.

So no - I do not agree with your observations.

   Gyan> I am not promoting use of SAFI 1 however I SRv6 should provide 
complete parity with MPLS to support both SAFI 1 and 128. There  are plenty of 
use cases for SAFI 1 and it should be supported with SRv6.

However I am for providing overlay reachability over global IPv6 Internet to 
interconnect customer sites. But routing within those sites should not be 
traversing Internet routers and using SAFI 1.

Rgs,
Robert.

--

[Image removed by sender.]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

___
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]

Gyan,

MPLS is never sent in SAFI 1.

Thx,
R.

On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra  wrote:

> Hi Robert
>
> On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk  wrote:
>
>> Gyan,
>>
>> Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
>>> encoding.  In this case using GRT transport underlay layer now carry’s the
>>> customer routes and that is what Warren and Andrew concern is as far as BGP
>>> leaks.
>>>
>>
>> I would have the same concern so would VPN customers. No one is selling
>> L2 or L3 VPN service to them distributing their reachability in the global
>> routing table. They can do that all by themselves and there is lot's of
>> really solid tools or products to do that already without being locked to a
>> single telco.
>>
>
> Gyan> MPLS provides the capability for GRT native routing  SAFI 1 as well
> as SAFI 128, so in my opinion both should be supported by SRV6 as operators
> look to use SRv6 for a variety of use cases. That’s my point as there
> should be complete feature parity between MPLS and SRv6 as to AFI / SAFI
> support.  Global Internet routing would not be the best use case for SAFI 1
> GRT due to the attack vector - agreed, but enterprise networks with
> internal customers where there is a trust level is a huge use case.
>
>>
>> So when GRT is used the same edge filtering protection mechanisms used
>>> today for MPLS and SR-MPLS would apply to SRv6 for GRT use case.
>>>
>>
>> Not possible. It is not about filtering ... it is all about using
>> globally routable SAFI vs private SAFIs to distribute customer's
>> reachability, IMO that should still be OTT only.
>>
>
> Gyan> As SRv6 source node is requirement to encapsulation with IPv6
> outer header and decapsulation at egress PE for SRv6-BE and SRv6-TE path
> steering the security issue brought up related to 5.3 and 5.4 is not an
> issue requiring filtering per RFC 8402.  So routable and private SAFI
> scenario would be the same now due to encapsulation overlay for both.  Do
> you agree ?
>
>>
>> I don’t think we are saying 5.3 or 5.4 should not be allowed but just to
>>> tighten up verbiage as far securing the domain.
>>>
>>
>> BGP filtering or policy is in hands of many people. As has been proven
>> you can not tighten them strong enough not to leak. The only natural way to
>> tighten them is to use different plane to distribute private information
>> what in this context means at least different BGP SAFI.
>>
>> So no - I do not agree with your observations.
>>
>
>Gyan> I am not promoting use of SAFI 1 however I SRv6 should provide
> complete parity with MPLS to support both SAFI 1 and 128. There  are plenty
> of use cases for SAFI 1 and it should be supported with SRv6.
>
>>
>> However I am for providing overlay reachability over global IPv6 Internet
>> to interconnect customer sites. But routing within those sites should not
>> be traversing Internet routers and using SAFI 1.
>>
>> Rgs,
>> Robert.
>>
>> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess