Re: [Idr] Fwd: [E] New Version Notification for draft-mishra-idr-v4-islands-v6-core-4pe-05.txt

[Robert Raszuk <[e-mail]>]

Gyan,

*> Arbitrary label versus explicit null debate for IPv6 LSP.*

"debate" - but still configuration option.

Vendor's manual:
You can configure the IPv6 Explicit Null Label by using the label mode [
explicit-null| all-explicit-null] command in the address family
configuration mode.

*> Keeping the IPv4 prefixes labeled versus unlabeled *

Clearly a configuration choice.

*> Label stack depth and future MNA*

Result of configuration choice

*> Support for PHP or not *

See vendor's manual explicit null vs implicit null configuration

*> Support for explicit null or not *

Again as per line #1 - configuration choice

*> 4PE data planes supported *

Again configuration option. Hint: You may have IPv4 VRF on IPv6 node.

*> Support for LDP and RSVP-TE *

Configuration choice

Thank you,
R.




On Mon, Jul 31, 2023 at 8:28 AM Gyan Mishra <[e-mail]> wrote:

>
> Robert
>
> I don’t think any of them are configuration options as they are 4PE
> specification design options.
>
> Kind Regards
>
> Gyan
>
> On Mon, Jul 31, 2023 at 2:25 AM Robert Raszuk <[e-mail]> wrote:
>
>> Gyan,
>>
>> All of the below elements are configuration options for already defined
>> standards track RFCs
>>
>> Last time I checked IDR nor any other IETF WG is not tasked to
>> standardize specific configuration choices.
>>
>> Kind regards,
>> Robert
>>
>>
>> On Mon, Jul 31, 2023 at 7:47 AM Gyan Mishra <[e-mail]>
>> wrote:
>>
>>>
>>> Hi Robert
>>>
>>> As I had mentioned during the IDR meeting update and exactly the
>>> discussion being had with Igor that there are a lot of procedural details
>>> in the draft that if not standardized could result in interoperability
>>> issues.
>>>
>>> RFC 4798 6PE was standardized and for good reason and following suit
>>> here to provide vendor interoperability this 4PE draft should be
>>> standardized.
>>>
>>> A few items from this discussion thread that are good reasons for
>>> standardization.
>>>
>>> Arbitrary label versus explicit null debate for IPv6 LSP.
>>>
>>> Keeping the IPv4 prefixes labeled versus unlabeled
>>>
>>> Label stack depth and future MNA
>>>
>>> Support for PHP or not
>>>
>>> Support for explicit null or not
>>>
>>> 4PE data planes supported
>>>
>>> Support for LDP and RSVP-TE
>>>
>>> Let the WG decide during the adoption call but I don’t think there is
>>> any reason why this should not be standardized.
>>>
>>> Thanks for the comments!
>>>
>>> Gyan
>>>
>>> On Sun, Jul 30, 2023 at 3:45 PM Robert Raszuk <[e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>> Great comments from Igor.
>>>>
>>>> And honestly I do not intend to repeat again the entire discussion on
>>>> this document we already have had in the past.
>>>>
>>>> But please Gyan kindly answer why you think this draft should be a
>>>> "Standards Track" document. You are not defining a single
>>>> protocol extension nor providing modifications to protocol operations. You
>>>> are also not asking IANA for any new type or value allocation.
>>>>
>>>> Instead the draft enumerates various ways one could in theory signal
>>>> IPv4 reachability over networks running IPv6 in the underlay.
>>>>
>>>> And that list of options is also far from complete too as it misses the
>>>> number of various overlays one can build today to transparently communicate
>>>> over any underlay and over any provider without any action on the transit
>>>> network. Think of it like CSC with pure IPv6 encapsulation - no labels nor
>>>> SIDs of any sort needed.
>>>>
>>>> So considering the above easy alternative it can't fit to be a BCP doc
>>>> as provided options in the draft are neither "Best" nor "Common" and hardly
>>>> "Practices" :).
>>>>
>>>> Honestly what could be perhaps helpful (if authors are still interested
>>>> in this topic) instead of 24 pages of pretty hard to parse text a single
>>>> 1-2 page table comparing pros and cons of various solutions in this space
>>>> published as an informational RFC.
>>>>
>>>> Kind regards,
>>>> Robert
>>>>
>>>>
>>>> On Sun, Jul 30, 2023 at 2:40 PM Igor Malyushkin <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi Gyan,
>>>>>
>>>>> I have several questions w.r.t your draft. But first I would like to
>>>>> clarify some points from your summary.
>>>>>
>>>>>
>>>>> "*Customer IPv4 prefixes must be labeled when tunneled over IPv6 LSP*".
>>>>> I believe there is a misconception between the "labeled prefixes" and the
>>>>> "labeled traffic". Prefixes cannot be tunneled via LSPs, traffic can be.
>>>>> Customer IPv4 prefixes can be dissipated as vanilla IPv4 prefixes without
>>>>> labels. I described the reasons during the previous discussion of this
>>>>> document.
>>>>>
>>>>> "*If not labeled on the PHP node when the topmost label is popped the
>>>>> native IPv4 prefix is exposed and is not routable and will be dropped*",
>>>>> this sentence describes traffic, not BGP prefixes, and I'm sure we can
>>>>> reach the goal of having two and more labels in a stack without advertising
>>>>> tons of IPv4 reachability with labels. We can solely use IPv4 labeled
>>>>> prefixes also, as this draft describes, but there are other options too.
>>>>>
>>>>> "*RFC 7948 “6PE” states that the label bound to the IPv4 prefixes may
>>>>> be an arbitrary value or explicit null label which has led to vendor
>>>>> interoperability issues in the past*". Can you please elaborate on
>>>>> that topic? I know the exact opposite cases.
>>>>>
>>>>> "*4PE draft states that the IPv4 prefixes must use MPLS QOS RFC 3270
>>>>> Pipe mode explicit null label bound to the IPv4 prefix and MUST be used ...*".
>>>>> In my opinion, the idea of getting rid of arbitrary labels breaks a lot of
>>>>> stuff. I will clarify it later.
>>>>>
>>>>> "*Additional text clarity added related RFC 8950 next hop encoding...*".
>>>>> Honestly, I don't understand why. It is just a rephrase of the stuff from
>>>>> the original standard. Can you shed light on the necessity of this section?
>>>>> Maybe I'm missing something.
>>>>>
>>>>> Here and after my comments w.r.t the body of the draft.
>>>>>
>>>>> 1. Section 1. "*This document explains the "4PE" design procedures
>>>>> and how to interconnect IPv4 islands over a Multiprotocol Label Switching
>>>>> (MPLS) [RFC3031] LDPv6 enabled IPv6-Only core, Segment Routing (SR) enabled
>>>>> SR-MPLS [RFC8660] IPv6-Only core or SRv6 [RFC8986] IPv6-Only core*".
>>>>> Is my understanding correct that the 4PE solution does not support RSVP-TE
>>>>> LSP signaled to IPv6 tail-ends over an IPv6-routed core? I see LDPv6 here,
>>>>> but the link goes to RFC3031 which is the architecture standard that
>>>>> applies not only to LDP. By the way, 6PE/6vPE perfectly works with RSVP
>>>>> LSPs.
>>>>>
>>>>> 2. Section 1. "*The 4PE routers exchange the IPv4 reachability
>>>>> information transparently over the core using the Multiprotocol Border
>>>>> Gateway Protocol (MP-BGP) over IPv6. In doing so, the BGP Next Hop field
>>>>> egress PE FEC (Forwarding Equivalency Class) is used to convey the IPv6
>>>>> address of the 4PE router learned dynamically via IGP...*". Can a 4PE
>>>>> router, that resides in one IGP domain, use a next-hop address received
>>>>> from the other domain via, for example, IPv6 labeled unicast?
>>>>>
>>>>> 3. Section 1. "...* over an MPLS [RFC3031] LDP IPv6 core, Segment
>>>>> Routing SR-MPLS [RFC8660] IPv6 core or SRv6 [RFC8986] IPv6 core*".
>>>>> This part is a repetition of the same that was done previously, and it will
>>>>> be repeated several times later. Moreover, there are standard numbers
>>>>> enclosed after every term again and again. As I understand, it is enough to
>>>>> do it one time per every desired abbreviation during the whole body.
>>>>>
>>>>> 4. Section 1. "*The approach requires that the Provider Edge (PE)
>>>>> routers Provider Edge - Customer Edge (PE-CE) connections to Customer Edge
>>>>> (CE)*". Honestly, it is difficult to read such things. From my POV,
>>>>> there should be a section with all unique definitions pertaining to this
>>>>> draft (e.g., 4PE router). Moreover, things such as the PE, and CE are
>>>>> well-known and do not require unfolding. There is a document of such
>>>>> well-known terms on the IETF portal for your convenience. The last thing,
>>>>> as I see the same abbreviations are unfolded many times during the
>>>>> document, which is contrary to the idea of an abbreviation in general. Once
>>>>> explained, an abbreviation should be used without further explanation.
>>>>>
>>>>> 5. Section 3. "*...the 4PE IPv6 address Loopback0 MUST to be routable
>>>>> within the IPv6 core*". What is "the 4PE IPv6 address Loopback0"? It
>>>>> was not previously defined in the document.
>>>>>
>>>>> 6. Section 3. "*Every ingress 4PE router can signal an IPv6 MPLS
>>>>> [RFC3031] LSP, SRMPLS [RFC8660] LSP or instantiate an SRv6 Best Effort (BE)
>>>>> or Segment Routing Traffic Engineering (SR-TE) [RFC9256] path to send to
>>>>> any egress 4PE router*". It is not necessary for an ingress router to
>>>>> signal an LSP. For example, LDP DU signals LSPs from a downstream towards
>>>>> all possible upstreams. RSVP or LDP DoD acts the opposite (if we talk about
>>>>> the intention, not a label distribution). So it is better to rephrase this
>>>>> sentence as "every ingress 4PE router can have an LSP toward..." or
>>>>> something like that.
>>>>>
>>>>> 7. Section 3. "*...the IPv6 signaled next hop Loopback0 used to
>>>>> identify the Ingress and Egress 4PE router*". Now the Loopback0 is
>>>>> somehow connected to some next-hop. I believe this connection should be
>>>>> clarified too.
>>>>>
>>>>> 8. Section 3. "*In doing so, the 4PE routers convey their IPv6
>>>>> address FEC label binding as the BGP Next Hop for the advertised IPv4
>>>>> prefixes*". The term FEC is pretty general, but the "IPv6 address FEC
>>>>> label binding" can mislead a reader. From my POV, this term is related to
>>>>> LDP, but the document includes many options to signal transport paths.
>>>>>
>>>>> 9. Section 3. "*The ingress and egress 4PE router MUST bind a label
>>>>> to the IPv4 prefix as per [RFC8277] using BGP Labeled Unicast herinafter
>>>>> called BGP-LU, AFI/SAFI Address Family (AFI) / Subsequent Address Family
>>>>> Identifier (SAFI) 2-tuple "1/4"*".  Which is the IPv4 prefix? If I
>>>>> understand it correctly, this requirement is too strict. As a designer I
>>>>> don't want to send all IPv4 prefixes with labels in every case, I want to
>>>>> have some flexibility. Moreover, as a part of the implementation team, I'm
>>>>> sure we won't consider this as the only possible option too.
>>>>>
>>>>> 10. Section 3. "*The Ingress 4PE router MUST forward IPv4 NLRI as
>>>>> Labeled prefixes using BGP-LU SAFI over the IPv6-signaled LSP towards the
>>>>> Egress 4PE router identified by the IPv4 address advertised in the IPv6
>>>>> next hop encoding per [RFC8950]*". NLRI is a term related to BGP
>>>>> message encoding. How can a 4PE router forward an NLRI over an LSP?
>>>>> Forwarding is a procedure of transmitting traffic, LSP is a transport
>>>>> entity used for forwarding labeled traffic, not NLRIs.
>>>>>
>>>>> 11. Section 4. "*To ensure interoperability between routers that
>>>>> implement the 4PE design over MPLS [RFC3031] LDP IPv6 Core described in
>>>>> this document, ingress and egress 4PE MUST support building the underlay
>>>>> tunneling using IPv6-signaled MPLS LSPs established by LDP [RFC5036] or
>>>>> Resource Reservation Protocol (RSVP-TE) [RFC3209]*". Here we see that
>>>>> RSVP is anyhow possible, but I'm still missing the idea of "MPLS LDP IPv6
>>>>> Core" and how RSVP is related to it. Is this sentence about LDP over RSVP
>>>>> tunneling? Or about ships in the night?
>>>>>
>>>>> 12. Section 4. "*The (outer) label imposed MUST correspond to the
>>>>> IPv6- signaled LSP starting on the ingress 4PE Router and ending on the
>>>>> egress 4PE Router*". What if I have segmented LSPs among several
>>>>> domains of the same AS? Pretty sure that in this case, the outermost label
>>>>> would correspond to an LSP either from an ingress 4PE to an ABR or from an
>>>>> ABR to the other ABR/egress 4PE router.
>>>>>
>>>>> 13. Section 4. "*The reason for the use of a second level bottom of
>>>>> stack service label...*". I'm sure that the stack can be deeper. I
>>>>> made some hints earlier in my notes (e.g., see the previous bullet), also
>>>>> you can think about emerging MNA solutions. I think it is better to pay
>>>>> attention not to the number of labels in a stack but to the fact that the
>>>>> bottom label must pertain to an LSP forwarding IPv4 traffic and that this
>>>>> label must be present on the egress.
>>>>>
>>>>> 14. Section 4. "*...it allows for Penultimate Hop Popping (PHP) on
>>>>> the IPv6 Label Switch Router (LSR) Provider (P) node,...*". I believe
>>>>> it is better to use one terminology, either pertaining to an MPLS LSP
>>>>> (LER/LSR) or a BGP service (P/PE) in a single sentence. Here MPLS-related
>>>>> terms suit you better because you are describing an LSP and label stack.
>>>>>
>>>>> 15. Section 4. "*The label advertised by the egress 4PE Router with
>>>>> MP-BGP MUST be an explicit Null label Pipe mode Diff-Serv Tunneling Model
>>>>> use case as defined in [RFC3270], so that the topmost label can be
>>>>> preserved Ultimate Hop POP (UHP) to the egress PE Edge LSR*". Why can
>>>>> it be an arbitrary label instead an explicit null?
>>>>>
>>>>> 16. Section 4. "*The explicit null label advertised by the egress PE
>>>>> router with MP-BGP also identifies the IPv4 routing context or outgoing
>>>>> interface to forward the packet to and ingress 4PE Router which MUST be
>>>>> able to be accept the "IPv6 Explicit NULL Label" advertised*".  From
>>>>> the very beginning of this statement, I understand that the egress PE
>>>>> advertises an explicit label (0) for IPv4-labeled unicast routes to
>>>>> identify either IPv4 routing context or outgoing interface. The end of this
>>>>> sentence tells us that the ingress 4PE router must accept the IPv6 explicit
>>>>> label (2). This label (2) cannot be used to identify either IPv4 routing
>>>>> contexts or any interfaces. So I made an assumption that there is a mistake
>>>>> and this is actually a 0 label, not 2.
>>>>> How can the label with the same value (0) identify several things
>>>>> (context, interface)? If you offer to bind this label to an exact interface
>>>>> (without a route lookup at egress) instead of doing a lookup in the global
>>>>> routing context/table, it will break the idea behind this special purpose
>>>>> label and won't support more than one interface for your solution.
>>>>> Arbitrary labels solve this issue and also many others.
>>>>> For example, it allows us to do EPE if and only if we dissipate IPv4
>>>>> reachability (separately from its next-hop addresses) as IPv4 routes with
>>>>> IPv4 next-hops alongside arbitrary labels for these next-hops distributed
>>>>> as labeled IPv4 routes with IPv6 next-hops (which this draft does not
>>>>> support and breaks). In this case, these arbitrary labels are allocated in
>>>>> per next-hop fashion and preclude any IP lookups at egress. I've have
>>>>> mentioned it several months ago.
>>>>>
>>>>> 17. Section 4. "*4PE design MUST use "IPv6 Explicit Null label" value
>>>>> 2 defined in [RFC4182] Pipe Diff-Serv Tunneling Model as defined in
>>>>> [RFC3270]*". From this statement, I conclude that the authors talk
>>>>> about an underlying transport (IPv6 LSP via BGP LU). Why does the draft
>>>>> about a service mandate a label for transport? I don't see anything wrong
>>>>> with arbitrary labels for underlying IPv6 LSPs either. If you want to
>>>>> highlight that there should *not *be PHP it does not mean there is
>>>>> only option is an explicit label. Some vendors use arbitrary labels by
>>>>> default with an option to use a label of 2 instead.
>>>>>
>>>>> 18. Section 4. "*BGP/MPLS VPN [RFC4364] defines 3 label allocation
>>>>> modes for Layer 3 VPN's...*" and later "*The 4PE design provides the
>>>>> same operator flxeiblity as BGP/MPLS VPN [RFC4798], 2 level label stack
>>>>> option using Per-CE label allocation mode where the next hop is label so
>>>>> all prefixes associated with CE get the same label. The 4PE design provides
>>>>> the same operator flxeiblity as BGP/MPLS VPN [RFC4798], 2 level label stack
>>>>> option using Per-VRF label allocation mode where all prefixes within a VRF
>>>>> get the same is label*". I believe it is not possible with an
>>>>> explicit label for an IPv4 LSP either because a single value cannot be
>>>>> attached to many different things at the same time.
>>>>>
>>>>> 19. Section 7.3.1. "*...the 4PE IPv4 BGP-LU labeled Unicast RIB is
>>>>> not maintained on the ASBR*". I would further elaborate on this point
>>>>> as these routes must not be installed in the forwarding table as some
>>>>> vendors do it by default because it breaks the whole idea of the Option B
>>>>> scenario. Only their labels must be installed into LFIB. With the VPN-based
>>>>> option B there is no any danger because we do not create VRFs on an ASBR,
>>>>> but with labeled unicast this is a possible issue.
>>>>>
>>>>> 20. Section 8. RFC 8950 describes the logic of how to handle next-hop
>>>>> addresses with different lengths including the routes of SAFI 4. Does this
>>>>> section bring something new?
>>>>>
>>>>> 21. I don't see any description of a scenario when some vendors
>>>>> install specific routes in auxiliary tables for the sake of further BGP NH
>>>>> resolution and consider them as LSPs. There should be a warning at least.
>>>>> Let's imagine a case where there are two or more BNG routes residing
>>>>> in a single PoP. The core network is single-stack IPv6. BNGs are
>>>>> dual-stacked because we are still supporting some legacy connections for v4
>>>>> eyeballs. PE routes that are connected to these BNGs are dual-stacked too
>>>>> (you can consider a BNG as a CE router). Now we want to distribute tons of
>>>>> /32 among PEs because the BNGs share the same IPv4 subnets. That
>>>>> facilitates more optimal allocation of the depleting IPv4 address space and
>>>>> is a pretty common case in the SP world. So, if the PE routers distribute
>>>>> these specifics by mistake or by design (let's say, to other PEs of this
>>>>> PoP for CG-NAT purposes) as IPv4 labeled unicast routes. Possible receivers
>>>>> of these routes may consider them viable LSPs. Imagine of hundreds
>>>>> thousands of such prefixes. That's actually another reason why labeled
>>>>> unicast is not good at this task.
>>>>>
>>>>>
>>>>> Thank you in advance.
>>>>> Igor.
>>>>>
>>>>> чт, 27 июл. 2023 г. в 19:50, Gyan Mishra <[e-mail]>:
>>>>>
>>>>>> All
>>>>>>
>>>>>> I have updated the IDR draft below updates as reviewed during our
>>>>>> IETF  117 meeting.
>>>>>>
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/draft-mishra-idr-v4-islands-v6-core-4pe/05/
>>>>>>
>>>>>>
>>>>>>    - Customer IPv4 prefixes must be labeled when tunneled over IPv6
>>>>>>    LSP.  If not labeled on the PHP node when the topmost label is popped the
>>>>>>    native IPv4 prefix is exposed and is not routable and will be dropped
>>>>>>    unless RFC 3270 Pipe mode explicit null signaling is enabled, which may not
>>>>>>    be always the case for customers wanting to use PHP signaling implicit
>>>>>>    null.  For IPv6 prefixes over an IPv6 core or IPv4 prefixes over IPv4 core
>>>>>>    at PHP node the IPv4 or IPv6 prefix can still be routed since the protocol
>>>>>>    of the tunneled prefix matches underlay protocol.  Not the case for 4PE
>>>>>>    with protocol mismatch between 2 level label stack topmost IPv6 label and
>>>>>>    BOS S bit IPv4 prefixes.
>>>>>>    - Label stack MUST be 2 Level Label Stack is only supported.
>>>>>>    This is for interoperability as additional labels could be added for
>>>>>>    flexibility to the specification but that could break interop.  IPv4
>>>>>>    prefixes must still be labeled even with MPLS QOS explicit null label pipe
>>>>>>    mode RFC 3270 as described in RFC 3032.
>>>>>>    - RFC 7948 “6PE” states that the label bound to the IPv4 prefixes
>>>>>>    may be an arbitrary value or explicit null label which has led to vendor
>>>>>>    interoperability issues in the past.   4PE draft states that the IPv4
>>>>>>    prefixes must use MPLS QOS RFC 3270 Pipe mode explicit null label bound to
>>>>>>    the IPv4 prefix and MUST be used to signal from egress 4PE to ingress 4PE
>>>>>>    router that the packet is an IPv4 packet to identify the IPv4 routing
>>>>>>    context or outgoing interface to forward the packet.
>>>>>>    - When RFC 7948 “6PE” was written when Segment Routing did not
>>>>>>    exist.  The 4PE draft provides a detailed interworking of how 4PE is
>>>>>>    implemented with Segment Routing both SR-MPLS & SRv6.  I have cleaned up
>>>>>>    the related text in the draft on Segment Routing support to make it more
>>>>>>    clear.
>>>>>>    - Additional text clarity added related RFC 8950 next hop
>>>>>>    encoding interaction with 4PE and the importance of 4PE procedures and that
>>>>>>    RFC 8950 is strictly about the next hop encoding of IPv4 NLRI over an IPv6
>>>>>>    next hop peer.
>>>>>>    - Added comments related to alternatives to 4PE that exist to
>>>>>>    connect IPv4 islands over an IPv6 core and why a standardized BGP based 4PE
>>>>>>    specification is the desired solution as compared to alternatives that
>>>>>>    exist today.
>>>>>>
>>>>>>
>>>>>> Please review and provide any comments.
>>>>>>
>>>>>> Thank you
>>>>>>
>>>>>> Gyan
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ---------
>>>>>> From: <[e-mail]>
>>>>>> Date: Thu, Jul 27, 2023 at 11:23 AM
>>>>>> Subject: [E] New Version Notification for
>>>>>> draft-mishra-idr-v4-islands-v6-core-4pe-05.txt
>>>>>> To: Adam Simpson <[e-mail]>, Gyan Mishra <
>>>>>> [e-mail]>, Jeff Tantsura <[e-mail]>,
>>>>>> Mankamana Mishra <[e-mail]>, Shuanglong Chen <
>>>>>> [e-mail]>, Sudha Madhavi <[e-mail]>
>>>>>>
>>>>>>
>>>>>>
>>>>>> A new version of I-D, draft-mishra-idr-v4-islands-v6-core-4pe-05.txt
>>>>>> has been successfully submitted by Gyan Mishra and posted to the
>>>>>> IETF repository.
>>>>>>
>>>>>> Name:           draft-mishra-idr-v4-islands-v6-core-4pe
>>>>>> Revision:       05
>>>>>> Title:          Connecting IPv4 Islands over IPv6 Core using IPv4
>>>>>> Provider Edge Routers (4PE)
>>>>>> Document date:  2023-07-27
>>>>>> Group:          Individual Submission
>>>>>> Pages:          24
>>>>>> URL:
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dmishra-2Didr-2Dv4-2Dislands-2Dv6-2Dcore-2D4pe-2D05.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=VzHwh1TdZ13EhVmr48yMIBUCBRJ2ddcFx1t6Q7ZRm5rIAdubltLbXN5rM-19Gpnf&s=nt2Ly9ZOC094SqRgkAoslAoIF6Pp9RgKbxqqksJcfI4&e=
>>>>>> Status:
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmishra-2Didr-2Dv4-2Dislands-2Dv6-2Dcore-2D4pe_&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=VzHwh1TdZ13EhVmr48yMIBUCBRJ2ddcFx1t6Q7ZRm5rIAdubltLbXN5rM-19Gpnf&s=DJfC1DqgQ5IVWI3g7_N3FAyCnmJzFOeSCg3YcxYobjw&e=
>>>>>> Htmlized:
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dmishra-2Didr-2Dv4-2Dislands-2Dv6-2Dcore-2D4pe&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=VzHwh1TdZ13EhVmr48yMIBUCBRJ2ddcFx1t6Q7ZRm5rIAdubltLbXN5rM-19Gpnf&s=F_Wr8Fgqdm8T5fOlOYkhpHlYyUs3dJU1xXOA9ouUDTU&e=
>>>>>> Diff:
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dmishra-2Didr-2Dv4-2Dislands-2Dv6-2Dcore-2D4pe-2D05&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=VzHwh1TdZ13EhVmr48yMIBUCBRJ2ddcFx1t6Q7ZRm5rIAdubltLbXN5rM-19Gpnf&s=fTNPBdbUKuSCsofECeey7RGCd80t507kdsJP931effo&e=
>>>>>>
>>>>>> Abstract:
>>>>>>    As operators migrate from an IPv4 core to an IPv6 core for global
>>>>>>    table internet routing, the need arises to be able provide routing
>>>>>>    connectivity for customers IPv4 only networks.  This document
>>>>>>    provides a solution called 4Provider Edge, "4PE" that connects IPv4
>>>>>>    islands over an IPv6-Only Core Underlay Network.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The IETF Secretariat
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> <http://www.verizon.com/>
>>>>>>
>>>>>> *Gyan Mishra*
>>>>>>
>>>>>> *IT Technologist & Innovations Specialist*
>>>>>>
>>>>>> *Associate Fellow-Network Design*
>>>>>>
>>>>>> *Network Solutions A**rchitect, *
>>>>>>
>>>>>> *R&S, SP SME & Protocol Design Expert*
>>>>>>
>>>>>> *Global Technology Services*
>>>>>>
>>>>>>
>>>>>>
>>>>>> *O 240 970-6287M 301 502-1347*
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> <http://www.verizon.com/>
>>>>>>
>>>>>> *Gyan Mishra*
>>>>>>
>>>>>> *Network Solutions A**rchitect *
>>>>>>
>>>>>> *Email [e-mail] <[e-mail]>*
>>>>>>
>>>>>>
>>>>>>
>>>>>> *M 301 502-1347*
>>>>>>
>>>>>> _______________________________________________
>>>>>> Idr mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>>
>>>>> _______________________________________________
>>>>> Idr mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>
>>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>> *Email [e-mail] <[e-mail]>*
>>>
>>>
>>>
>>> *M 301 502-1347*
>>>
>>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
>