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

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 9 May 2020 13:55:33 +0000

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 <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Friday, May 8, 2020 at 5:22 PM
To: Philip Homburg <[email-masked]>
Cc: 6man WG <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 May 2020 09:24:52 +1200

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:
> *From: *ipv6 <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
> *Date: *Friday, May 8, 2020 at 5:22 PM
> *To: *Philip Homburg <[email-masked]>
> *Cc: *6man WG <[email-masked]>
> *Subject: *Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03
> 
>  
> 
> Hello Philip,
> 
>  
> 
> On Fri, May 8, 2020 at 9:26 PM Philip Homburg <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sun, 10 May 2020 02:09:51 +0000

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.

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:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Sunday, May 10, 2020 5:25 AM
To: [email-masked]
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

On 10-May-20 01:55, Zafar Ali (zali) wrote:
> 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.
> 
>  
> 
> 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.
> 
>  
> 
> 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.
> 
>  
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 May 2020 14:52:23 +1200

Hi Jingrong,

I agree with your analysis (unfortunately it is really too late to add another example to my draft, since it is in the final RFC-editing stage). But as I said, that is not an IETF consensus.

Regards
   Brian Carpenter

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sun, 10 May 2020 03:32:30 +0000

Hi Brian,
Good to know this is in RFC-editing stage, and look forward to the publication of RFC.

Welcome for the 6man discussion on this BIERv6 proposal as well, as this I think is an example of limited domain case, and ipv6-ext-hdr topic:
https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06

Regards
Jingrong

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Sunday, May 10, 2020 10:52 AM
To: Xiejingrong (Jingrong) <[email-masked]>; [email-masked]
Subject: Re: Intra SR Domain Deployment Model - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

Hi Jingrong,

Regards
   Brian Carpenter

On 10-May-20 14:09, Xiejingrong (Jingrong) wrote:
> Subject: Re: Intra SR Domain Deployment Model - Re: some feedback on 
> feedback on draft-bonica-6man-ext-hdr-update-03
> 
> Hi,
> 
>> 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.
>>
>>  
>>
>> 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.
>>
>>  
>>
>>     Administrative Requests: 
>> https://www.ietf.org/mailman/listinfo/ipv6
>>

---

From: Mark Smith <[email-masked]>
Date: Sun, 10 May 2020 13:49:54 +1000

On Sun, 10 May 2020, 12:10 Xiejingrong (Jingrong), <[email-masked]>
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.
> Limited-domain is a very small subset of Internet, e.g., a
> service-provider's network, a CDN network, etc.
>

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.
> (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+).
>
> 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.
>
> > +1; to add to what Robert explained (also changing subject to highlight
> the scope - 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
> >
> >
> >
> > 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.
> >
> >
> >
> > 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.
> >
> >
> >
> > 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.
> >
> >
> >
> > 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.
> >
> >
> >
> > transit network T1 packets is getting a new IPv6 header. Original packet
> intact is wrapped and placed into the new envelope.
> >
> >
> >
> > Sometimes it means a middle hop which by network programming will know
> how to handle it and apply new destination Tn.
> >
> >
> >
> > 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.
> >
> >
> >
> > 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.
> >
> >
> >
> > 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.
> >
> >
> >
> > 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 <
> [email-masked] <mailto:[email-masked]>>
> wrote:
> >

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sun, 10 May 2020 04:44:23 +0000

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:[email-masked]]
Sent: Sunday, May 10, 2020 11:50 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; 6man WG <[email-masked]>
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), <[email-masked]<mailto:[email-masked]>> 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.

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.

Thanks
Jingrong

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

Hi,

Regards
   Brian

On 10-May-20 01:55, Zafar Ali (zali) wrote:
> *From: *ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk
> <[email-masked]<mailto:[email-masked]>>
> *To: *Philip Homburg <[email-masked]<mailto:[email-masked]>>
> *Cc: *6man WG <[email-masked]<mailto:[email-masked]>>
> On Fri, May 8, 2020 at 9:26 PM Philip Homburg <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 10 May 2020 01:19:19 -0400

I can't speak for Mark.
 From where I sit, the mechanisms in 8754 are the ones we have used for 
protecting a number of things.  They produce a moderately protected 
domain that suffices if one is also careful in other regards.

That does not mean that it is safe to do anything and everything in the 
controlled domain that would not be safe on the open Internet.

I saw something that claimed to be a security analysis that claimed 
there was no risk of wire-tapping because it was a controlled domain. 
That simply does not follow.

Similarly, with the operational difficulties of header insertion, using 
the protocol in a quasi-limited domain does not suddenly make the 
operations safer, simpler, or more tractable.  It doesn't.

So yes, limited / controlled quasi-domains do help.  But they do not 
vitiate the many constraints in RFCs.  I would be very unhappy at the 
IETF taking Brian's useful work and trying to turn that into some kind 
of escape clause.

Yours,
Joel

PS: As Mark and others have noted, we have a lot of examples of things 
escaping out of controlled domains and of things leaking into domains 
where they do not belong.  So one has to be extremely cautious with the 
entire concept.   I am actually sympathetic to the security and 
congestion folks who keep asking for better behavior inside domains.  I 
just don't know how to make things like NSH both more robustly secure 
and still effective and useful.  I do acknowledge the tension.  And NSH 
does abide by all of the IP RFCs.  Quite carefully.

On 5/10/2020 12:44 AM, Xiejingrong (Jingrong) wrote:
> The success rate of implementing controlled domains using IPv6 is going 
> to be quite a bit lower than with MPLS because of these reasons.
> 
> ==> 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:[email-masked]]
> *Sent:* Sunday, May 10, 2020 11:50 AM
> *To:* Xiejingrong (Jingrong) <[email-masked]>
> *Cc:* Brian E Carpenter <[email-masked]>; 6man WG 
> <[email-masked]>
> *Subject:* Re: Intra SR Domain Deployment Model - Re: some feedback on 
> On Sun, 10 May 2020, 12:10 Xiejingrong (Jingrong), 
> <[email-masked] <mailto:[email-masked]>> 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.
>     I think this is an important thing that make it deployable using
>     IPv6 but not impact much on the public Internet.
> 
> 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.
> 
> The success rate of implementing controlled domains using IPv6 is going 
> to be quite a bit lower than with MPLS because of these reasons.
> 
> 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.
>     (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:
>     From: ipv6 [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Brian E Carpenter
>     To: [email-masked] <mailto:[email-masked]>
>     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
> 
>     > *From: *ipv6 <[email-masked] <mailto:[email-masked]>> on behalf of
>     Robert Raszuk
>     > <[email-masked] <mailto:[email-masked]>>
>     > *To: *Philip Homburg <[email-masked] <mailto:[email-masked]>>
>     > *Cc: *6man WG <[email-masked] <mailto:[email-masked]>>
>     > 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.
>     > 
>     >  
>     > 
>     > 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.
>     > 
>     >  
>     > 
>     > On Fri, May 8, 2020 at 9:26 PM Philip Homburg <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> 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.
>     > 
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Erik Kline <[email-masked]>
Date: Sat, 9 May 2020 23:28:10 -0700

There are, however, plenty of documents with an applicability
statement near the top.

These are usually "additive" in nature, i.e. "here's when you can use
IP over Avian Carrier", rather than redefining or violating some other
pre-existing standard.

I tend to think that w.r.t. SR (broadly) this is the case.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 10 May 2020 04:58:57 -0400

Jingrong

Are you stating that the success rate of SRv6 with controlled domains is
going to be much less due to the ability of SRv6 to overcome some of the
scalability issues that exist with MPLS inter-as.

By that you are referring to the reason why SRv6 and even SR-MPLS would
prevail and make inter-as solution more viable for service providers
overcoming the MPLS inter-as scalability issue using SR-TE binding sid to
inter link domains together.  Double edged sword of course and the good and
the bad with that as far as from a securing and controlled domain aspects.

So section 5 securing the SR Domain talks about how the intra SRv6 domain
can be secured, however as you and others mentioned since SRv6 uses the
IPv6 data plane, unintended leaking is more probable as well as intended
leaking.  Unintended leaking using SR-TE being more scalable then MPLS
inter-as we will see more usage across private and public internet. With
the inter liking of domains now coming more to fruition with SRv6 which is
a positive for service providers of course -  the down side is the intra
domain really becomes more widespread with even  inter domain over public
and private transport  ;  and the section 5 security ACLs etc would end up
having to be more relaxed to allow inter domain SRV6 routing to work.

Gyan

On Sun, May 10, 2020 at 2:28 AM Erik Kline <[email-masked]> wrote:

> standards
> > > +1; to add to what Robert explained (also changing subject to
> highlight the scope - 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
> > >
> > >
> > >
> > > 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.
> > >
> > >
> > >
> 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
> Sometimes it means a middle hop which by network programming will know how
> to handle it and apply new destination Tn.
> > >
> > >
> > >
> 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.
> > >
> > >
> > >
> 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
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Sun, 10 May 2020 09:27:27 -0300

> I tend to think that w.r.t. SR (broadly) this is the case.

I did the exercise myself and looked at the applicability statements of 
ten random RFCs. I found none (zero) where an applicability statement 
allowed for a violation of a core property of a standard.

It seems to be it would be okay to, say, use existing protocol knobs in 
a specific way for a given environment (e.g., timers, number of 
re-transmissions, etc.). It would also seem to be okay to state which 
specs are required (or are not) for a specific type of deployment or 
device (e.g. what should be implemented in routers vs. hosts). Or to 
state where some specific (e.g. deployment) advice applies.

But it would not be okay to violate a core protocol behavior based on an 
"applicability statement". That would make standards violation a simple 
matter of defining an applicability statement that suits you. And would 
also be a very unfortunate outcome if a folk looking at, say, a tcpdump 
trace, had to think "Oh, this is IPv6. But... where in the network am I? 
Is IPv6 end-to-end here?" (that should be an indication that your 
changing a standard behind the scenes)

As per the above, I certainly do not think that the RFC8200-violating 
behaviors we have been objecting from SRv6-related documents fall into 
the category where you can fix things by an "applicability statement 
that allows them to do more".

With that reasoning, how about, for example, "IPv6-super (whatever that 
means)", where now addresses are variable-length (thus "allowing you to 
do more"). -- but with a nice "applicability statement" saying that it's 
only applicable for service provider networks. Would one get to specify 
that without the required spec-manship and formal update to, say the 
IPv6 addressing architecture?

It is fine for SRv6 to have an associated applicability statement 
(otherwise, I wouldn't be surprised if the reaction of folks were "what 
the heck? you are bringing back source routing?"), and noting that the 
segment routing header is only meant to be employed for certain specific 
scenarios/environments.

But I don't think one can (or should, for instance) get away with 
violating a core aspect of a core standard via an applicability 
statement. And the formal description for applicability statemetns found 
in RFC2026 does not seem to allow for that, either.

To be honest, much of these discussions have looked to me a bit like 
"what rules are we going to bend or violate to make this happen?". 
Whereas I would have preferred myself that the same workflow of the rest 
of mere-mortals be applied, instead: call a lemon a lemon, identify what 
needs to be changed, and make the case for it.

The precedent that all this is setting is *very bad*, and doesn't speak 
of fairness.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Erik Kline <[email-masked]>
Date: Sun, 10 May 2020 12:28:23 -0700

> changing a standard behind the scenes)

I generally agree with the above.

> that allows them to do more".

It's here where I think we begin to differ.

There is, IMHO, a very real loop hole in the text of RFC 8200.  A
"strict literal interpretation" loop hole big enough to drive an
entire working group through.

>From this perspective, there are no violations of 8200 being allowed
for net-pgm draft -15.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 10 May 2020 16:56:07 -0300

On 10/5/20 16:28, Erik Kline wrote:
[...]
> entire working group through.

Since there's conflicting, contradicting, and confusing text in RFC8200, 
may I ask why one particular way to read one particular part of the 
standard is supposed to trump others?

In particular when the particular interpretation applied by the spring 
folks breaks even core ipv6 functionality such as PMTUD and error reporting?

Isn't this, maybe, an indication that the text in RFC8200 was simply 
imprecise, but otherwise the intent quite clear, since otherwise lots of 
things would be breaking?

Please take a look at my response to the automated email that was sent 
as a result of the erratum processed.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 10 May 2020 17:26:07 -0300

> entire working group through.

In the context of RFC8200, the only possible address that could be in 
the Destination Address is the final destination, since RFC8200 does not 
specify any routing headers.

Additionally, I should note that RFC8200 says:

    Extension headers (except for the Hop-by-Hop Options header) are not
    processed, inserted, or deleted by any node along a packet's delivery
    path, until the packet reaches the node (or each of the set of nodes,
    in the case of multicast) identified in the Destination Address field
    of the IPv6 header.

if interpreted that "Destination Address" is each instantiation of the 
Destination Address along the delivery path, the above text would also 
imply that multicast could be employed as "waypoints" of a packet.

That would be yet another source of breakage -- DoS'ers would love it.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 May 2020 08:51:57 +1200

> IETF taking Brian's useful work and trying to turn that into some kind 

Thankyou, Joel. Indeed, the conclusion from my draft is that *if* we
continue defining limited-domain protocols, *then* we need a solid
and secure definition of domain membership and domain boundary.
(draft-ietf-anima-autonomic-control-plane is a sort of prototype.)
At the moment, everyone who wants to define some kind of local
behaviour has to define their own flavour of domain, and that seems
like a recipe for operational confusion.

But that isn't our topic here in 6MAN. Fixing ambiguity in RFC8200 is.

    Brian

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 11 May 2020 00:08:02 +0000

Happy Mother’s Day to everyone.

Hi Fernando:

The section 3 of RFC8200 has a very clear definition of "Destination Address" (copied verbatim):

      "Destination Address 128-bit address of the intended recipient of
                          the packet (possibly not the ultimate
                          recipient, if a Routing header is present)."

Furthermore, the text you quoted is very clear:

  *   The processing, insertion and deletion restrictions only apply “until the packet reaches the node identified in the Destination Address field of the IPv6 header”.
  *   The segment endpoint IS “the node identified in the Destination Address field of the IPv6 header”.
  *   The text did NOT state the "ultimate-destination".

In addition, please note:

1. The processing, insertion and deletion operations are bundled together in the text you quoted.
2. The very concept of IPv6 routing headers requires to process the routing header at the segment endpoints
2.1 The segment endpoint reads the next segment from the (S)RH
2.2 The segment endpoint decrements the SegmentsLeft value
    This processing applies to ANY routing header.
3. Per 2., the extension header processing restriction cannot apply to segment endpoints

Per 1. and 3., the extension header insertion and deletion restrictions do not apply to segment endpoints, especially when proven safe within SR Domain Deployment Model defined in RFC8402 and RFC8754.

Lately, during the net-pgm WG LC, many have shared the same interpretation.
Here is a partial list:

Suresh Krishnan (6man AD at that time) (Dec 2019):

  *   https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
  *   https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/

Various working group participants:

  *   Joel Halpern (Dec 2019): https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk/
  *   Dirk Steinberg (Feb 2020): https://mailarchive.ietf.org/arch/msg/spring/6ZNyPMuZaaP9amVRXQdX9uRMbVk/
  *   Brian Carpenter (March 2020): https://mailarchive.ietf.org/arch/msg/spring/nbAdEl4HwCeRRzXEWnzxVnBt_YQ/
  *   Stefano Salsano (Feb 2020): https://mailarchive.ietf.org/arch/msg/spring/C20J-h835TJYHH2Q4KCHaS_lmek/
  *   Pablo Camarillo  (Feb 2020): https://mailarchive.ietf.org/arch/msg/spring/65GgH7fY3_TDEbE7dNXwSz64l58/
  *   Robert Raszuk (Dec 2019): https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw/
  *   Darren Dukes (Dec 2019): https://mailarchive.ietf.org/arch/msg/spring/JdpSLS7ax0VUZLG6SINxnOWJzbY/

Spring Chair Bruno Decraene (Dec 2019):

  *   https://mailarchive.ietf.org/arch/msg/ipv6/7uvJnZGNCs2x1FR2fWmOWiO5x2Q/
  *   https://mailarchive.ietf.org/arch/msg/spring/EM2Fvo2mcZPBnrdwfRfUW07LsXs/

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of Fernando Gont <[email-masked]>
Date: Sunday, May 10, 2020 at 4:27 PM
To: Erik Kline <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: Intra SR Domain Deployment Model - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: [email-masked]<mailto:[email-masked]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 11 May 2020 11:34:59 +0000

Hi Gyan,

I mean SRv6 may go not so slow due to its inter-AS scalability (comparing to MPLS) and the deployable security boundary mechanism.

Note the SR Domain could be an “intra-AS” or “inter-AS” infrastructure of a service-provider per the RFC8402 section 2.

The security boundary mechanism in RFC8754 section 5 ensures the “programmable SRv6 SID” and “SRH” would not be used by internet attackers.

I saw no problem with SR Domain and the PSP, but maybe the talking of the list was more about the behavior of “SRH insertion”, and that was outside my opinion.

Thanks
Jingrong

From: ipv6 [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Sunday, May 10, 2020 4:59 PM
To: Erik Kline <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: Intra SR Domain Deployment Model - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

Jingrong

Are you stating that the success rate of SRv6 with controlled domains is going to be much less due to the ability of SRv6 to overcome some of the scalability issues that exist with MPLS inter-as.

By that you are referring to the reason why SRv6 and even SR-MPLS would prevail and make inter-as solution more viable for service providers overcoming the MPLS inter-as scalability issue using SR-TE binding sid to inter link domains together.  Double edged sword of course and the good and the bad with that as far as from a securing and controlled domain aspects.

So section 5 securing the SR Domain talks about how the intra SRv6 domain can be secured, however as you and others mentioned since SRv6 uses the IPv6 data plane, unintended leaking is more probable as well as intended leaking.  Unintended leaking using SR-TE being more scalable then MPLS inter-as we will see more usage across private and public internet.. With the inter liking of domains now coming more to fruition with SRv6 which is a positive for service providers of course -  the down side is the intra domain really becomes more widespread with even  inter domain over public and private transport  ;  and the section 5 security ACLs etc would end up having to be more relaxed to allow inter domain SRV6 routing to work.

Gyan

On Sun, May 10, 2020 at 2:28 AM Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:
There are, however, plenty of documents with an applicability
statement near the top.

On Sat, May 9, 2020 at 2:25 PM Brian E Carpenter
<[email-masked]<mailto:[email-masked]>> wrote:
> > *From: *ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>

Email: [email-masked]<mailto:[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 11 May 2020 09:58:43 -0400

Hi Jingrong

Understood.  I think we are on the same page as far a securing SRv6 domain
inter or intra with section 5 from public internet domain attack vector.

As a side note, I am working on a draft with IDR related to use case review
of all inter-as MPLS based options that exist today and compare and
contrast with SRv6 and SR-MPLS use of SR-TE bsid to inter link and chain SR
domains together.  The main point of the document is to resolve confusion
that exists today with inter-as options with MPLS as there are are many
flavors and each is for specific use cases to get around scalability
issues.  Also in this new new draft  I am working on context of SR flavors
that all MPLS based inter-as options can be used with SR flavors as well
providing flexibility to the operators.

Thanks

Gyan

On Mon, May 11, 2020 at 7:35 AM Xiejingrong (Jingrong) <
[email-masked]> wrote:

> Hi Gyan,
>
>
>
> I mean SRv6 may go not so slow due to its inter-AS scalability (comparing
> to MPLS) and the deployable security boundary mechanism.
>
>
>
> Note the SR Domain could be an “intra-AS” or “inter-AS” infrastructure of
> a service-provider per the RFC8402 section 2.
>
>
>
> The security boundary mechanism in RFC8754 section 5 ensures the
> “programmable SRv6 SID” and “SRH” would not be used by internet attackers.
>
>
>
> I saw no problem with SR Domain and the PSP, but maybe the talking of the
> list was more about the behavior of “SRH insertion”, and that was outside
> my opinion.
>
>
>
> Thanks
>
> Jingrong
>
>
>
> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *Gyan Mishra
> *Sent:* Sunday, May 10, 2020 4:59 PM
> *To:* Erik Kline <[email-masked]>
> *Cc:* IPv6 List <[email-masked]>
> inter-as we will see more usage across private and public internet.. With
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 May 2020 08:26:50 +1200

On 11-May-20 23:34, Xiejingrong (Jingrong) wrote:
...
> I saw no problem with SR Domain and the PSP

The problem is not that it won't work, unless IPSec/AH is used. It will not damage PMTUD, because it makes the packet smaller for the last hop.

The problem is that some people think it violates RFC8200 and some people think the opposite.

It certainly violates draft-bonica-6man-ext-hdr-update.

Regards
   Brian Carpenter

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 May 2020 08:32:03 +1000

On Tue, 12 May 2020 at 06:29, Brian E Carpenter
<[email-masked]> wrote:
> ....

I expect the people who think it is fine don't have much operational
experience fixing faults on the Internet.

I've seen a brand new model of a Cisco router (7201), in 2009, leak
ARP packets received on one layer 3 physical interface onto a
different layer 3 physical interface (i.e. effectively bridging them
between physical interfaces - and there was no bridging configured).
These ARP packets caused the MAC address limit to be triggered at the
far end of the second link, causing the link to be taken down by the
far end. This was a critical peering link for us, that spanned half of
Australia and saved so much money on transit that the savings paid for
the new router in a month.

According to an Internet search, Cisco IOS started to be developed in
1986. So a 23 year old code base, in an area which would have
literally been used and deployed 100 of 1000s of times (basic IPv4
forwarding), likely millions of times, had a bug that caused ARP
packets to leak from one interface to another.

Of course we told the people at the other end of the link that the
fault must be theirs, this was decades old IOS, until they captured
packets showing the fault was ours.

Controlled or limited domain boundary enforcement cannot be relied
upon 100% in reality; saying so in an RFC or ID doesn't make it true.
It's nothing more than an aspiration.

Regards,
Mark.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 11 May 2020 19:13:10 -0400

ARP is one of those things that has been problematic 30+ years, and is
still a problem today.  ARP has to be carefully accounted for in any new
technology to prevent ARP storms along with L2 Spanning tree loops which
have been known to cause data center wide meltdowns.  Various features of
ARP throttling such as dynamic arp inspection and auto CoPP policies as
well as many other feature such as broadcast suppression have come about to
mitigate problems with ARP broadcasts.

With newer technologies for example with NVO3 vxlan BGP evpn overlay
technologies, we are able to design to eliminate all Fs broadcast by
translation of broadcast to be forwarded L2 over vxlan data plane as BUM
(broadcast, unknown unicast, multicast) to multicast using MVPN procedures
used today for L3 services PMSI-UI/MI trees default inclusive trees.  We
have learned a lot from MPLS and what works and what does not.  There is a
lot that we have leaned and reaped the benefits from MPLS to apply to newer
NG L2 technologies such as EVPN.

I am working on a draft that compares and contrasts all SR flavors and
variants to help operations make the best decision.  Using a decision tree
that helps operators make the best decision on which flavor of SR works
best for them based on their requirements.

Overall for operators there is tremendous to gain from SR technologies over
MPLS which why the industry push for SR.

Any new technology does not come with growing pains and of course ensuring
that all standards are met and that we are not fixing one thing but
inadvertently breaking many other things.  Stability is key for operators
and MTTR( mean time to recovery).

MPLS when it came out post ATM days had a myriad of problems from  ldp/IGP
sync issues to FEC binding issues to name a few and I remember the acronym
MPLS= “more problems less service”. Well MPLS has gone a long long ways
since it’s inception and we have no doubt as operators learned a lot.

With SR we are trying to take the best of MPLS and RSVP TE learnings as
well as other technologies, and applying the best of all those features to
SR while at the same time eliminating all the pitfalls of mpls.

Kind regards

Gyan
Verizon

On Mon, May 11, 2020 at 6:32 PM Mark Smith <[email-masked]> wrote:

> > The problem is not that it won't work, unless IPSec/AH is used. It will
> not damage PMTUD, because it makes the packet smaller for the last hop.
> >
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347