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

[Igor Malyushkin <[e-mail]>]

Well, I don't mind if others, possibly not even related to MPLS, ways will
be added to this list. I've just tried to make some MPLS summary.

пн, 31 июл. 2023 г. в 16:39, Robert Raszuk <[e-mail]>:

>
> > and a single label underneath are still possible
>
> Why put any labels at all ?
>
> You bind a "4PE" service to a loopback, advertise such a loopback in the
> tunnel encap attribute or direct or via any other control or mapping
> plane (read LISP) and you need no labels, no issues with PHP, explicit
> nulls all of that ....
>
> Decapsulation directs packets to v4 VRFs you do the lookup and forwards.
>
> Case solved.
>
> Cheers,
> R.
>
>
>
>
>
>
> On Mon, Jul 31, 2023 at 12:41 PM Igor Malyushkin <[e-mail]>
> wrote:
>
>> And several additional words.
>>
>> First, I think that end-to-end vanilla IPv4 routes with IPv6 NHs and a
>> single label underneath are still possible and should not be restricted.
>> All that the document should do is warn people that if the underneath
>> LSP experiences PHP there are possible problems. I'm writing "possible"
>> because AFAIK some vendors handle this case well, but the warning is
>> desired.
>>
>> So, I see the next options for the draft:
>> * Describe the case, when reachability and label-signaling are combined
>> with IPv4 1/4 with IPv6 NHs.
>> * Describe the case, when reachability is separated from label-signaling,
>> i.e., IPv4 1/1 for customer's prefixes, IPv4 1/4 for their NHs (here IPv4
>> 1/4 routes are with IPv6 NHs for sure).
>> * Describe the case, when reachability is a matter of IPv4 1/1 routes
>> with IPv6 NHs, and LSPs towards these NHs are without PHP.
>> * Describe the case, when reachability is a matter of IPv4 1/1 routes
>> with IPv6 NHs, and LSPs towards these NHs can use PHP at your own risk.
>>
>> Second, about DiffServ Pipe mode. I believe, that this aspect is
>> orthogonal to the topic of this solution. I don't agree that the document
>> about services must confine transport underneath them. It only could
>> highlight some possible problems and warn people.
>>
>> Third, about the arbitrary-ness of labels. Neither IPv6 nor IPv4 should
>> be confined to using only explicit labels. For IPv4 LSPs, it leads to the
>> inability to achieve different modes of label allocation (per table, per
>> NH, per prefix). Imagine the 4VPE case, this is the same as 4PE (if
>> considering only the current body of the document), but labels at the
>> bottom are always arbitrary. For IPv6 LSPs, it does not influence the PHP
>> in any way, that's just meaningless.
>>
>> Fourth, I concur with Robert, this document should be informational. I
>> don't see any new mechanics at all. This document is trying to prevent
>> people from making mistakes and it offers a more interoperable solution,
>> but this solution is a combination of current shipped features. So, if
>> delete all the restrictions from the current version, make it more
>> readable, and change the track to informational, there will be a pretty
>> useful doc.
>>
>>
>>
>>
>>
>>
>> пн, 31 июл. 2023 г. в 13:20, Igor Malyushkin <[e-mail]>:
>>
>>> Hi Gyan,
>>>
>>> My responses are also inline (IM>).
>>>
>>> пн, 31 июл. 2023 г. в 09:07, Gyan Mishra <[e-mail]>:
>>>
>>>>
>>>> Hi Igor
>>>>
>>>> Many thanks to your questions to clarify points in the draft.
>>>>
>>>> Responses in-line Gyan>
>>>>
>>>> On Sun, Jul 30, 2023 at 8:40 AM 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.
>>>>>
>>>>
>>>> Gyan> I was referring to the bottom of stack service labeling of the
>>>> IPv4 customer prefixes which the traffic flows are within the payload of
>>>> packet and not the label stack.  I can change the verbiage to labeled
>>>> traffic. Good point.
>>>>
>>>>>
>>>>> "*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.
>>>>>
>>>>
>>>>     Gyan> What I am describing is the native IPv4 prefixes under the
>>>> topmost transport IPv6 label once popped that are exposed which the
>>>> protocol is IPv4, where  the core P nodes are IPv6 so the IPv4 Paulo’s
>>>> packets will be dropped.  Imagine the scenario where you have an IPv4 core
>>>> and have native IPv4 to the edge so in that case you would have native IPv4
>>>> Unicast prefixes 1/1 over a IPv4 core IPv4 LSP topmost label, and with IPv6
>>>> core IPv6 LSP topmost label would have native IPv4 Unicast prefixes 1/1
>>>> over IPv6 core.  I can rewrite as “Native IPv4 prefixes are exposed and non
>>>> routable and IPv4 payload traffic is dropped. RFC 3032 section 2.2 states
>>>> that the bottom of stack prefixes if a different protocol  then the topmost
>>>> label as in this case must be labeled to identify the protocol type of the
>>>> prefixes.  We can discuss the other options.
>>>>
>>>
>>>>> "*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.
>>>>>
>>>>
>>>>    Gyan> Issue arises if one vendor uses arbitrary label and the other
>>>> vendor uses IPv4 explicit null label value 1. AFAIK  Both sides using to
>>>> arbitrary value or both sides signaling explicit null is ok but with
>>>> mismatch there is an issue.
>>>>
>>>
>>> IM> The selection of a value for a label is a matter of choice of a node
>>> that allocates the value for the label. I'm lost what you mean by "both
>>> sides". There is no such conception as "mismatch" because LSRs do not
>>> negotiate label values among themselves in general. Yes, there are examples
>>> of the opposite but for peculiar cases that do not interfere with our topic.
>>>
>>>
>>>>
>>>>> "*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.
>>>>>
>>>>
>>>>    Gyan> Yes please clarify
>>>>
>>> IM> Well, I've done it below in my previous message.
>>>
>>>>
>>>>>
>>>>> "*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.
>>>>>
>>>>
>>>> Gyan> It’s just for reference stated explicitly in the draft but I
>>>> agree it can be removed
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>    Gyan>  RFC 3031 is referenced for MPLS data plane but I did not
>>>> specify LDP spec which I can add to be consistent.  Further down in the
>>>> draft I do mention RSVP-TE but forgot to mention in above text so will add.
>>>>
>>>>
>>>>>
>>>>>
>>>>> 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?
>>>>>
>>>>
>>>>    Gyan> Yes it can using as you stated using BGP-LU is exactly how
>>>> it’s done with inter-as option C where the next hops are imported between
>>>> the IGP domains.  See section 7.3.2.
>>>>
>>>
>>> IM> "Between the IGP domains" does not mean "between ASes". From my
>>> understanding, Option C describes the latter, I was asking about the
>>> former. So my question is still intact. Can addresses for BGP next-hops be
>>> learned via means different from IGP as you stated in the body of the doc?
>>> Consider the Seamless MPLS approach. My point is that you should delete
>>> "... via IGP", not only IGP can do that, but BGP also can.
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Gyan> Agreed will fix
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Gyan> Agreed will fix
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Gyan> Will define and make clear
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>   Gyan> I was speaking generically not actually but is confusing as you
>>>> stated not correct- so will fix with the LDP downstream unsolicited and
>>>> RSVP-TE DOD.
>>>>
>>>
>>> IM> Well, one can call me too pedantic, but I believe that technical
>>> documentation especially the one that wants to be a Standard must be
>>> streamlined and precise.
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>      Gyan> Will fix
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>     Gyan> Will fix
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>     Gyan>Lets discuss this in more detail the use cases for not
>>>> labeling.  Also the issue I mentioned in RFC 3032 section 2.2 that
>>>> describes the problem with not labeling the prefix if the protocol is
>>>> different between the topmost label and service prefix.
>>>>
>>>
>>> IM> I believe there should be a clear distinction between reachability
>>> advertisements and LSP signaling. BGP LU does both at the same time. Every
>>> IP prefix here comes with a label that allows us to signal a BGP LSP. It
>>> seems to me, you consider LU only as the copy-paste of IPv4 unicast but
>>> with labels. I offer you to look at it as an LSP signaling protocol (one
>>> can think LU is an LDP on steroids).
>>>
>>> Let's consider an example. We have a PE-CE link with an IPv4 subnet
>>> toward an IPv4 CE. A PE router of that PE-CE link is a part of the
>>> IPv6-only core. We have some v6 LSP mesh among all PEs of that core. These
>>> v6 LSPs populate the FTN table and allow us to resolve any BGP next-hops
>>> through the network. The CE advertises IPv4 routes via 1/1. Let's call them
>>> Customer Prefixes or Reachability for convenience. I believe, at this
>>> point, the setup is pretty clear.
>>>
>>> Your draft restricts me to export these Customer Prefixes into IPv4
>>> labeled unicast internal sessions and also restricts me to attach an
>>> explicit null label (with the value of 0) to them. Anyway, that works, and
>>> I have never argued
>>>
>>> I don't see a good reason to do that. All that I want is to create an
>>> IPv4 loopback on the PE and advertise its IPv4 address via IPv4 labeled
>>> unicast toward remote PEs. In doing so I create a BGP LSP from every remote
>>> PE to this advertising PE. The label from this advertisement can be either
>>> an explicit null or an arbitrary one. This is my choice. Then I just
>>> readvertise all Customer Prefixes via internal IPv4 1/1 sessions with the
>>> next-hop address of my new shiny IPv4 loopback.
>>>
>>> Both examples would have the same deep of a label stack. Both examples
>>> wouldn't have any problems at the penultimate LSR. Both examples (well,
>>> mechanics, not exact examples) should be a part of the doc.
>>>
>>> But with my example, I have greater flexibility, I can change the
>>> next-hop addresses from the loopback address to an address of the PE-CE
>>> link, allocate an arbitrary label in a per-next-hop fashion and get an EPE.
>>> Also, it would increase convergence if I want to. The key here -- is my
>>> desire as a designer. With your solution, it is impossible because the
>>> next-hop for all Customer Prefixes and the label would always be the same.
>>> It is impossible from a single value (0) to produce many different actions
>>> at egress.
>>>
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>   Gyan> I am referring to BGP SAFI in this case IPv4 labeled unicast
>>>> 1/4 which should say “advertised” and not “forwarded”
>>>>
>>>>>
>>>>>
>>>>> 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?
>>>>>
>>>>
>>>>    Gyan> yes two ships in the night two different scenarios will fix
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>    Gyan> Yes that’s correct and will add that scenario of multiple
>>>> domains to the wording for end to end scenario
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>    Gyan> Agreed.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>    Gyan> Agreed will fix
>>>>
>>>>>
>>>>> 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?
>>>>>
>>>>
>>>>     Gyan> The reason for IPv6 explicit null label for topmost label is
>>>> to prevent the drop issue in case the service prefix is not labeled as I
>>>> have mentioned in the draft and the IPv4 traffic is dropped.  Using IPv6
>>>> explicit null label RFC 3270  pipe mode also fixes the MPLS QOS issue of
>>>> EXP PHB scheduling on PHP node when the topmost label is popped as
>>>> mentioned earlier.
>>>>
>>>
>>> IM> My question was about a different thing. An arbitrary label also
>>> prevents a penultimate LSR from exposing the payload. An LSR would do a
>>> simple swap operation not knowing itself as penultimate. The second moment,
>>> I don't understand why are you restricting the transport from PHP if you
>>> have already restricted the service from that. One shouldn't try to save
>>> everybody from every possible pitfall with a single document.
>>>
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>> IM> It seems, that you have skipped the crucial part of my message :(
>>>
>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>>     Gyan> I agree most vendors use arbitrary label by default and an
>>>> option to use explicit null.  As it’s an easy configuration change to use
>>>> explicit null with its benefits why not mandate it with the benefits.  As
>>>> well as solve issues with mix of arbitrary and explicit null usage.  I
>>>> would like to highlight that there would not be PHP but AFAIK that can only
>>>> be done if using explicit null. As well as explicit null pipe mode solves
>>>> the MPLS QOS PHB EXP scheduling issue.
>>>>
>>>
>>> IM> No, this can be done not only using the explicit null. For example,
>>> Nokia SR OS allocates arbitrary labels by default for RSVP and LDP LSPs.
>>> Penultimate routers in that case just swap one label to another (our
>>> arbitrary one). Egress LER then handles the stack with the transport label
>>> at the top that it allocated previously. But the difference between an
>>> explicit label and an arbitrary one is this eLER can do many things with
>>> the latter: allocate if for a table, for a prefix, for a next-hop address.
>>> You can not do it with the single-valued label (0 or 2). The labels of 0 or
>>> 2 are always tightened with their global contexts. Changing that is not
>>> possible under this draft because it influences the whole MPLS paradigm.
>>>
>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>     Gyan> The IPv4 labeled prefixes AFAIK would have a single label per
>>>> CE or per VRF. Can you elaborate on why not possible?
>>>>
>>>
>>> IM> Yes. We have a single label per VRF but we can't have a single label
>>> per CE because there are possibly lots of CEs in a VRF. The egress router
>>> doing a label lookup must understand what to do with every label it
>>> allocated. With a per VRF label it does an IP lookup in a corresponding
>>> VRF. With a per CE label it strips the label and sends payload via the
>>> exact interface without any IP lookups. As you can see, you can't bind a
>>> single value to many different interfaces (tasks).
>>>
>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>>    Gyan> 7.3.1 Opt-B I mentioned that labeled unicast RIB is maintained
>>>> on ASBR but as you stated in the details is LFIB and not RIB agreed is more
>>>> optimized as what some vendors do by default both RIB and LFIB. Agreed.
>>>>
>>>>>
>>>>> 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?
>>>>>
>>>>
>>>>  Gyan>  It does not.  It’s just explicitly stating the next hop
>>>> encoding used.  So this section could be deleted.  As the next hop encoding
>>>> is critical I had added the section explicitly.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>>     Gyan> I can add that to security considerations
>>>>
>>>> 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.
>>>>>
>>>>
>>>>
>>>>     Gyan> Understood I can add to the security considerations section
>>>>
>>>>>
>>>>>
>>>>> 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
>>>>>>
>>>>> --
>>>>
>>>> <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
>>
>