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

[Igor Malyushkin <[e-mail]>]

       Gyan3> I agree this sentence is a bit confusing with regards to
label 0 and 2 use.  We are not using IPv4 explicit null value 0 at all in
this draft.  So the conveying of the next hop and what the sentence it
talking about related to the IPv6 LSP egress PE signaling done via the IPv6
explicit null label value 2 defined in RFC 4182 to use for topmost label so
the next hop of the  advertised IPv4 routes have an IPv6 next hop as
defined according to RFC 8950 next hop encoding which is an IPv6 labeled
address per BGP LU RFC 8277 for the BOS IPv4 prefixes. So here  we are
talking about using label value 2 IPv6 explicit null to identify the IPv4
routing context of the outgoing interface since the next hop is an IPv6
next hop for the labeled IPv4 prefixes.  I will cleanup the wording.

Now it is more clear to me. Thank you. I've already expressed my thoughts
on restriction of the transport. I strongly disagree.

P.S. Label value 2 cannot identify the IPv4 routing context. With BoS bit
it identifies the IPv6 routing context. Without BoS bit this label is
stripped and a lookup is done for the next label until the bottom
is reached. The bottom label actually identifies the context in this case.
So, it is also not the best wording I believe.

вт, 1 авг. 2023 г. в 21:20, Gyan Mishra <[e-mail]>:

>
> Hi Igor
>
> Response on the remaining item I missed in your first email - Gyan3>
>
> Thanks
>
> Gyan
> On Tue, Aug 1, 2023 at 11:02 AM Gyan Mishra <[e-mail]> wrote:
>
>> Hi Igor
>>
>> Responses in-line Gyan2>
>>
>> On Mon, Jul 31, 2023 at 5:20 AM Igor Malyushkin <[e-mail]>
>> wrote:
>>
>>> 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.
>>>
>>
>>    Gyan2>Unidirectional LSP so no concept of both sides -agreed. One side
>> could signal LSP using arbitrary label and other side explicit null. There
>> is not related to mismatch and is some other peculiar case which I have to
>> dig up.
>>
>>>
>>>
>>>>
>>>>> "*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.
>>>
>>
>> Gyan2> Got it will update
>>
>>>
>>>>> 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.
>>>
>>
>>     Gyan2> Yep Understood
>>
>>>
>>>>> 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.
>>>
>>>
>>      Gyan2> Thank you for the detailed use case.  Have you tried to
>> configure this example and with which vendor?  I am not sure I would call
>> it EPE as SR or BGP-LU are not steering traffic to the egress but I get it
>> your point EPE like behavior to point to specific CE next hop.  What is the
>> advantage of doing so.  With my solution you have a single next hop which
>> is the egress PE however all the prefixes received on the egress PE in the
>> IPv4 labeled unicast RIB would get advertised to each CE across the
>> respective next hops. In your example you create and LSP between the PE
>> loopbacks or use PE-CE interface next hop for the LSP per CE and then
>> advertise all the prefixes per CE unlabeled.  The  prefixes for each CE
>> broken down now by IPv4 LSP are going to all get advertised out to all CEs
>> anyway doing it your way or my way.  So net end result of what gets
>> advertised to which ingress and egress CE over the LSP is identical. I am
>> not seeing any benefit to doing so other than added complexity.  I am not
>> sure how much convergence gain you have as you can do per VRF label
>> allocation and better scale and convergence. Can you expand on the benefits
>> of doing so in your example. I do now understand the flexibility you desire.
>>
>>>
>>>>>
>>>>> 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.
>>>
>>>
>>     Gyan2> I am restricting the transport from PHP with topmost IPv6 LSP
>> explicit null signaling.  The service does not need to be restricted as
>> it’s only popped at the egress PE.  The PHP node would either do default
>> PHP and pop the topmost label or if explicit null signaling is enabled for
>> the LSP the topmost is preserved to egress PE which pops the entire stack.
>> All intermediate LSRs would do the normal swap operation except the PHP
>> node which would use the implicit null value 3 label default PHP POP
>> operation.  My concern is only with exposing unlabeled service which would
>> get dropped with the default PHP operation and not using explicit null
>> signaling on the transport LSP.
>>
>>>
>>>>>
>>>>> 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 :(
>>>
>>
>>     Gyan2> I will answer in the next email, thanks
>>
>>>
>>>
>>
>        Gyan3> I agree this sentence is a bit confusing with regards to
> label 0 and 2 use.  We are not using IPv4 explicit null value 0 at all in
> this draft.  So the conveying of the next hop and what the sentence it
> talking about related to the IPv6 LSP egress PE signaling done via the IPv6
> explicit null label value 2 defined in RFC 4182 to use for topmost label so
> the next hop of the  advertised IPv4 routes have an IPv6 next hop as
> defined according to RFC 8950 next hop encoding which is an IPv6 labeled
> address per BGP LU RFC 8277 for the BOS IPv4 prefixes. So here  we are
> talking about using label value 2 IPv6 explicit null to identify the IPv4
> routing context of the outgoing interface since the next hop is an IPv6
> next hop for the labeled IPv4 prefixes.  I will cleanup the wording.
>
>>
>>>
>>>>> 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.
>>>
>>
>>     Gyan2>   In the draft all I am concerned about is the transport
>> topmost label IPv6 explicit null signaling so the PHP node preserves the
>> transport label to prevent the IPv4 packets from being dropped at PHP
>> node.  It sounds like Nokia by default for RSVP and LDP LSP does not do PHP
>> by default on the PHP node PHP label 3 and uses arbitrary label as you
>> mentioned.  Cisco, Juniper and most all vendors on the market do PHP by
>> default.  Egress LER pops the entire stack of remaining labels regardless
>> of topmost label explicit null signaling or PHP operation.  Since the
>> explicit versus arbitrary relates to the topmost transport label the
>> behavior of what happens on the LER egress PE is identical popping the
>> entire stack after which perform per VRF table lookup, per CE next hop or
>> per prefix label allocation. I think what you are missing is RFC 4182
>> updates RFC 3032 label stack so that explicit null 0 and 2 can be used for
>> the transport label where previously was only valid for BOS label.  That is
>> what I have been referring to using explicit null for topmost label and not
>> the BOS label.
>>
>>>
>>>
>>>>>
>>>>> 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).
>>>
>>
>>    Gyan2> I think it’s actually the opposite that when using 6VPE or 4VPE
>> you have VRF context but with 6PE or 4PE their is not many VRF context
>> instances but we do have a single default VRF context so single label for
>> the default VRF.  With per CE label allocation with 6VPE / 4VPE versus 6PE
>> / 4PE I don’t see how it’s any different with per CE the label is stripped
>> by the PE and the native packet payload is forwarded to the exact CE
>> interface in this case it’s the default VRF many interfaces which with VPE
>> you can have many interfaces as well - no different.  If per CE works for
>> 6VPE / 4VPE it should work for 6PE / 4PE.
>>
>>>
>>>
>>>>
>>>>> 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*
>>>>
>>>> --
>>
>> <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*
>
>