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

[Gyan Mishra <[e-mail]>]

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*