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

[Gyan Mishra <[e-mail]>]

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*