RE: Intra SR Domain Deployment Model - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Mark,
Have you found any problems of the “controlled domain” mechanism setup by RFC8754 section 5 ?
More below about the SRv6 controlled domain and the MPLS controlled domain:

The success rate of implementing controlled domains using IPv6 is going to be quite a bit lower than with MPLS because of these reasons.
==>Look at the deployment of SRv6 please.

(Has there ever been an MPLS leak between networks that caused problems in the receiving network?)
==> MPLS(and other L2.5 technology) used to be used in “intra-AS” scope, which is a very small part of a Service-provider’s network.
==> When it comes to “inter-AS” deployment within a service-provider, it encountered serious scalability problems. The industry spent many years trying to solve this scalability problem, and finally give up (https://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-07).
==>This is very much like the telephone AFAIK, firstly it is mainly used in a “metro wide”, and now it is common for a “national wide” telephone call without any extra fee for inter-metro.
==>While for an enterprise who want a national wide “connection” of its two sites,  it is hard for a service provider on its “inter-AS” infrastructure to provide such connection by using MPLS. That’s the pain.
==>There is also MPLS over IP/UDP proposal for such “inter-AS” connection, but I failed to see a good “security boundary” could be well deployed (see RFC7510 section 6) without using an IP address block.
==>I really don’t know any other methods to solve both better: the secure boundary, and the “inter-AS” scalability, until I realized that RFC8754 section 5.1 provides a paradigm IMO.

Thanks
Jingrong

From: Mark Smith [mailto:[e-mail]]
Sent: Sunday, May 10, 2020 11:50 AM
To: Xiejingrong (Jingrong) <[e-mail]>
Cc: Brian E Carpenter <[e-mail]>; 6man WG <[e-mail]>
Subject: Re: Intra SR Domain Deployment Model - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03


On Sun, 10 May 2020, 12:10 Xiejingrong (Jingrong), <[e-mail]<mailto:[e-mail]>> wrote:
Hi Brian,
I think the limited domain is a good summary to differentiate from the internet, and may help the understanding between "routing area" people and "internet area" people.
Internet is "networks' network", or "interconnection of service-provider's networks".
Limited-domain is a very small subset of Internet, e.g., a service-provider's network, a CDN network, etc.

Let me cite text from the <draft-carpenter-limited-domains> draft:
   Often, the boundary of a limited domain will also act as a security
   boundary.  In particular, it will serve as a trust boundary, and as a
   boundary of authority for defining capabilities.  For example,
   segment routing [RFC8402] explicitly uses the concept of a "trusted
   domain" in this way.

I think this is an important thing that make it deployable using IPv6 but not impact much on the public Internet.

If controlled domains were as reliability deployed as some believe, we wouldn't have RFC1918 address leaks, 100.64/10 route leaks, and need for the as112 project to deal with DNS PTR lookups for RFC1918 addresses.

People might think MPLS and IPv6 are equivalent transports for SR. They're not, there are quite a lot of differences.

MPLS doesn't have a default route label that causes traffic to try to leave the local network by default if there is no local matching destination.

MPLS isn't the universal end-to-end Internet protocol intended to be talked by all Internet attached nodes including end-user hosts. MPLS is a local network, most commonly within the network only protocol.

MPLS is an optional protocol that is used to support a network's use of IP. IP is a mandatory protocol needed to provide services to end-hosts that use IP to communicate.

MPLS's "nature" is to be and be used as a limited domain protocol. IPv6's nature is the opposite.

The success rate of implementing controlled domains using IPv6 is going to be quite a bit lower than with MPLS because of these reasons.

(Has there ever been an MPLS leak between networks that caused problems in the receiving network?)

If you want to much more reliability implement a controlled domain that is attached to the Internet, you use a local network protocol that has no chance of being able to traverse the Internet and reach a foreign host where it could cause problems, should it somehow leak.



SRv6 has a very clear and deployable "trust boundary" by using the widely available "ACL" capability as described in RFC8754 section 5.1.
And that's my observation about the "limited domain" and how SRv6 is a good design and good example:
(1) Use ipv6 address block for ease of "trust boundary" definition, making it deployable.
(2) Predicable MTU consumption by a Max-SID and Max-Delta assumption.
(3) Use of HMAC (also mature theory) to provide source-origin integrity of its L3 own, without burden of payload integrity (which is often guaranteed by L4+).

I would like to recommend one more use case of "limited domain" to your <draft-carpenter-limited-domains> draft:
https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06
(section 5.1 for secure the domain boundary, using the paradigm settled by RFC8754 section 5.1)

Thanks
Jingrong

-----Original Message-----
From: ipv6 [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Brian E Carpenter
Sent: Sunday, May 10, 2020 5:25 AM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: Intra SR Domain Deployment Model - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

Hi,

To my certain knowledge, the IETF has not agreed that exceptions to standards are allowed within limited domains, or established any standard about what a limited domain is and how its boundary and membership are established.

That might be a good thing to do, and I might even have some ideas about how to do it**. But so far, it hasn't happened.

Regards
   Brian

** https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/

On 10-May-20 01:55, Zafar Ali (zali) wrote:
> Hi,
>
>
>
> +1; to add to what Robert explained (also changing subject to highlight the scope - Intra SR Domain Deployment Model):
>
>
>
>   * RFC8402 (SR Architecture) defines segment routing within an SR Domain.
>   * RFC8754 (SRH) section 5 further defines the Intra SR Domain Deployment Model.
>   * draft-ietf-spring-srv6-network-programming defines segment behaviors solely within the context of these RFCs: i.e. within the SR Domain.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *ipv6 <[e-mail]<mailto:[e-mail]>> on behalf of Robert Raszuk
> <[e-mail]<mailto:[e-mail]>>
> *Date: *Friday, May 8, 2020 at 5:22 PM
> *To: *Philip Homburg <[e-mail]<mailto:[e-mail]>>
> *Cc: *6man WG <[e-mail]<mailto:[e-mail]>>
> *Subject: *Re: some feedback on feedback on
> draft-bonica-6man-ext-hdr-update-03
>
>
>
> Hello Philip,
>
>
>
> I am not sure if you have carefully followed 100s of emails so far on
> either 6man or spring WG lists..
>
>
>
> Your comments lead me to believe that perhaps you missed the key point here. Lecture of the subject draft also does not help at all to clarify what the behaviour should be as it just does not talk about the problem at hand. It talks about something which IMHO is obvious to all of us. It mixes end to end required behaviour with transport behaviour - completely different layers of transport all within layer 3.
>
>
>
> So let me for clarity restate the problem - hoping that those who do
> care about technical points will find it useful:
>
>
>
> Application opens a socket and original IPv6 packets get's send from
> node N1 to final/ultimate/etc destination N2.
>
>
>
> Obviously it contains some v6 base header and may contain some
> extension headers.
>
>
>
> No one here is doing *anything* to this very headers. For those calling it end to end principle of IPv6 no one is changing a bit. Those stay intact.
>
>
>
> But as it is unfortunately the case N1 and N2 may not be directly
> connected. Worse to get from N1 to N2 packets may need to transit via third party network or networks.
>
>
>
> So it is very common that each transit network today implements some
> form of encapsulation for various reasons. Some use IPv4 encap, some use MPLS-LDP, some use RSVP-TE, some use IPv6 in IPv6. Even if you go and try to buy "a circuit" you will be getting an emulated circuit over someone's IPv4 or IPv6 network.
>
>
>
> Transport network operator is responsible for his network - so all
> claims that oh if I insert a bit here or there packets may exceed MTU and will be dropped while theoretically true really do not happen in real life as no one sane accepts the larger packet which it would not be able to carry as transit provider. Besides if someone would he would be out of business already so nothing for IETF to worry about.
>
>
>
> So now comes the crux of what some call "the issue". On the edge of
> transit network T1 packets is getting a new IPv6 header. Original packet intact is wrapped and placed into the new envelope.
>
>
>
> Sometimes DST of the packet T2 means egress from transit network.
> Sometimes it means a middle hop which by network programming will know how to handle it and apply new destination Tn.
>
>
>
> I do not see anything wrong with any  "intermediate destination of the
> packet" to do what it considers best in order to deliver packet to the transit network egress node.
>
>
>
> Now comes the topic of an additional hander mangling even by nodes
> which are not intermediate destinations, yet all within transit network. Real use case example of this would be the local path or node protection. The less overhead it incurs the better for the end to end service hence those arguing let's apply new IPv6 header there are just off in the efficiency curve - even if it perhaps simplifies some of the hardware processing. If we can insert arbitrary MPLS stack anywhere in transit why one would not be able to insert a new SRH into his own IPv6 transit header ? SIDs are much larger - oh no ... take a look at our vSID proposal.
>
>
>
> Finally packet gets to the ultimate egress of transit network and
> continues its journey towards N2.
>
>
>
> To conclude - all what transit does with the packet has nothing to do with end to end principle. If someone is trying to fit today's networking into OSI model I am afraid it will fail as OSI model does not map today's flavors of IP layer 3 transport planes.
>
>
>
> If some would like to see N1 to N2 traversing without any
> encapsulation I believe need to build new Internet by themselves starting with dark fiber. Mean time folks trying to use IPv6 to deliver better services are facing some fascinating oppositions which can not even in technical terms explain the issue.
>
>
>
> I am really puzzled what the subject draft is trying to clarify. Plain
> mortal reading does not reveal the mystery behind it. Maybe printing it on good printer and flashing UV light would help ? Maybe some have special decoder which would reveal the real text. No idea.
>
>
>
> Kind regards,
>
> Robert.
>
>
>
> PS. Another way to look at this space is to either accept that encapsulation of IPv6 in IPv6 is allowed or not. And as we are rewriting L2 header at each L3 hop - one can consider SRv6 technology as rewriting IPv6 header at each L3 hop within a given network. If so all header operations are permitted by each hop if not by RFC8200 then by RFC2473.
>
>
>
>
>
> On Fri, May 8, 2020 at 9:26 PM Philip Homburg <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>
>     >    However,  if you look at it after PSP node has received and
>     >    processed the PSP function psuedocode you are now in RFC 8200
>     >    conformance.
>
>     If you say only the final destination of the IPv6 packet removes the
>     extension headers and no intermediate router inserts or removes anything,
>     then there is no conflict with draft-bonica-6man-ext-hdr-update-03 or
>     with Fernado's erratum. So we just accept either of those as a
>     clarification of RFC 8200 and move on.
>
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>
> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]<mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------