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

[Mark Smith <[e-mail]>]

On Sun, 10 May 2020, 12:10 Xiejingrong (Jingrong), <[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]] On Behalf Of Brian E Carpenter
> Sent: Sunday, May 10, 2020 5:25 AM
> To: [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]> on behalf of Robert Raszuk
> > <[e-mail]>
> > *Date: *Friday, May 8, 2020 at 5:22 PM
> > *To: *Philip Homburg <[e-mail]>
> > *Cc: *6man WG <[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]>>
> 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]>
> >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >
> > --------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>