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

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

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:[e-mail]] 
Sent: Sunday, May 10, 2020 10:52 AM
To: Xiejingrong (Jingrong) <[e-mail]>; [e-mail]
Subject: Re: Intra SR Domain Deployment Model - Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

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

On 10-May-20 14:09, Xiejingrong (Jingrong) 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.
> 
> 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
> --------------------------------------------------------------------
>