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

[Igor Malyushkin <[e-mail]>]

My comments are inline (IM2).

чт, 3 авг. 2023 г. в 18:54, Gyan Mishra <[e-mail]>:

> Hi Igor
>
> Yes looks like we have reached a consensus!!
>
>
> On Thu, Aug 3, 2023 at 8:43 AM Igor Malyushkin <[e-mail]>
> wrote:
>
>> Hi Gayn, looks like we have reached a consensus!
>>
>>
>> чт, 3 авг. 2023 г. в 09:03, Gyan Mishra <[e-mail]>:
>>
>>> Hi Igor
>>>
>>> I am good with everything listed below.
>>>
>>> As far as the topmost explicit versus arbitrary label I agree that based
>>> on implementation if you use arbitrary you are ok if 1/4 service label is
>>> used
>>>
>>
>> IM> Ok.
>>
>>
>>> however if you use arbitrary topmost label and use 1/1 for service label
>>> at the PHP node the native IPv4 packet could be dropped.  There would be a
>>> warning for that particular use case.
>>>
>>
>> IM> Yes. But I would say not at the PHP node. The PHP node just swaps a
>> label in the case of arbitrary labels. Dropping occurs at the ultimate node
>> (egress PE) due to any label for IPv6 LSPs (an arbitrary one or explicit 2)
>> here can be allocated for the IPv6 routing process, but a packet is an IPv4
>> one.
>>
>
>     Gyan> My understanding here is that the PHP (Penultimate Hop POP) node
> is not the Ultimate hop which is the egress LER (PE) but is one hop prior
> to the egress LER which would be the egress LSR (P) node.
>
[IM2] Yes, a PHP node is not an egress LER (PE). I've never heard someone
calls a penultimate node an egress LSR, but ok, I will follow for this
discussion.


> So when the topmost label is an arbitrary label by default the PHP node
> egress LSR (P) when it does a label swap the incoming label is arbitrary
> but the outgoing label is “POP” which signals implicit null value 3.
>
[IM2] No. Let me give you an example. Egress LER X allocates the label of
3000 and puts it in its ILM table with a POP operation. Then it advertises
a mapping of its loopback's IPv6 address plus the label (3000) via LDPv6.
That means that the egress LER expects MPLS traffic with the label of 3000
on its LDP-enabled interfaces and will strip this label by itself. All its
neighbors would either swap something to 3000 or push 3000. The former case
is when these neighbors are LSRs, the latter is when they are iLERs. In
other words, we have a continuous single-labeled LSP from ingress LER to
egress LER. All LSRs just do swapping of labels, but not popping.

As I previously said, Nokia does it by default for RSVP, LDP, and BGP LSP.
Huawei has a configuration option at least for LDP to turn this feature on.
>From time to time there are bugs with handling labels 0,2 or 3 among
different vendors. I had a very unpleasant experience with this too before.
Arbitrary labels allow us to fool the penultimate nodes and make them
regular LSRs. It also could work with egress LERs when they due to a bug
cannot handle either unlabeled traffic or traffic with explicit labels.
Personally, I consider PHP and UHP with explicit labels as rudiments and
prefer using arbitrary labels instead.

 So once the  PHP node egress LSR does the “POP” processing the outer
topmost  label in the label stack is stripped or removed leaving the
exposed payload which if a 2 level label stack would now be a single level
label stack 1/4 and the labeled packet is successfully forwarded to the
egress LER (PE) that POPs the remaining labels in the stack in this case
the BOS bit set service label and the native IPv4 packet is forwarded to
IPv4 context PE-CE interface via standard forwarding.
[IM2] That's correct.

So if it’s a single level label stack with topmost IPv6 arbitrary label
once the PHP processing is completed “POP” operation stripping or removing
outer topmost IPv6 arbitrary label the IPv4 payload is now exposed in the
case of 1/1 service and the unlabeled IPv4 packet is dropped by the PHP
node as it cannot be forwarded onto the egress IPv6 only  core interface
facing the egress LER (PE). That’s the problem that we would address in
this specification with 4PE.
[IM2] That's not.

>
> If the egress LER signaled explicit null pipe mode to the egress LSR PHP
> node, the PHP node seeing the value 2 IPv6 explicit null label being
> signaled and would preserve the topmost IPv6 label in pipe mode and forward
> the packet now still with topmost IPv6 label intact preserved over the IPv6
> core interface to the egress LER (PE) which would receive the single level
> label stack and now pop the remaining label in this case the explicit null
> value 2 topmost label and forward the native IPv4 packet to the outgoing
> PE-CE ipv4 routing context.
>
[IM2] No, it does not forward an IPv4 packet after the stripping of the
label of 2. I've just checked it on a Juniper, it drops all such traffic
until we turn off the explicit label (I tried with LDPv6 and family inet
without an address for the incoming interface). Nokia does the additional
packet inspection for arbitrary labels that belong to IPv6 LSPs and
forwards IPv4 packets. I cannot check it with an explicit label, looks like
it is not supported or I failed to find it.

[IM] For example, RFC3032 says:

A value of 2 represents the "IPv6 Explicit NULL Label".
              This label value is only legal at the bottom of the label
              stack.  It indicates that the label stack must be popped,
              and the forwarding of the packet must then be based on the
              IPv6 header.


Despite I believe that requirement of the bottomness is kinda relaxed these
days, anyway, it indicates that after the label of 2, there must be the
IPv6 header, not IPv4. So, as I said, some boxes expect only IPv6 traffic
and drop everything else if there is a label of 2 with a BoS set. Others
could check packets deeper and forward them.

>
> No IPv4 dropped packets with IPv6 explicit null signaling value 2 but with
> arbitrary label we drop all IPv4 packets on the PHP node after the “POP”
> operation.
>
[IM] As I explained above, in both cases -- no.


> The egress node can do additional packet inspection and avoid the
>> dropping, but there is no guarantee. This warning should be described in
>> the document alongside the warning of the PHP case for single-labeled
>> traffic.
>> Also, if this document tried to invent and describe procedures on how to
>> not drop IPv4 unlabeled traffic coming from IPv6 LSPs, I would say, that
>> deserves to be a Standard :)
>>
>> Summary:
>> * For single-labeled stacks:
>> * * If the topmost label is an explicit one (value 2) or an arbitrary
>> one, a drop is possible at an egress PE. The PE could think that a packet
>> behind the label is IPv6, if there is no additional packet inspection, the
>> drop will occur.
>> * * In the PHP case a drop is possible at the penultimate PE when the
>> topmost label is stripped of the payload. The PE could check the outgoing
>> interface's families and does not allow IPv4 packets there.
>> * For two or more labeled stacks:
>> * * A bottom label must be present and be either an arbitrary one or
>> explicit (0).
>> * * Any labels above can be present in a stack with any values or cannot
>> be present at all.
>>
>>
>>> The use case of topmost explicit null or implicit null default will both
>>> work with PE loopback LSP or per CE PE-CE interface LSP context label
>>> table.  We will allow topmost label PHP with no restriction as this is
>>> possible with the permutation of use cases using 1/4 for service label
>>> labeling all prefixes one bucket for all global table prefixes,  as well ws
>>> works for your use case PE loopback LSP or per CE PE-CE interface LSP
>>> carrying the per CE unlabeled CE prefixes.  As long as the service prefixes
>>> are labeled allowing PHP for topmost label is valid permutation without any
>>> risk of payload traffic drops.
>>>
>>
>> [IM] Yes, agree.
>>
>>>
>>> Let me know if you are good with what I have stated.
>>>
>>
>> [IM] I'm good with that, yes.
>>
>>
>>> As far as standards track I will discuss with the       co-authors.
>>>
>>> I will discuss if in shipping code what is implemented in detail and
>>> with what is described below if there is anything that requires
>>> standardization even though existing mechanisms are being used that if any
>>> procedural or any differences could cause interoperability issues.  One of
>>> the major goal of the IETF standardization is mix vendor interoperability.
>>> So if this can be achieved as informational draft or based on
>>> interoperability issues found with current or future vendor implementation
>>> do we need to have a standards track draft or not to meet the goal.
>>> Normative language only comes into play for standards track draft so since
>>> we do have normative language RFC 2119 does that mean this document should
>>> be standards track.
>>>
>>> I will discuss this topic with the chairs as well.
>>>
>>> Many Thanks!
>>>
>>> Gyan
>>>
>>> On Wed, Aug 2, 2023 at 6:32 AM Igor Malyushkin <[e-mail]>
>>> wrote:
>>>
>>>> Hi Gyan.
>>>>
>>>> When I'm talking about transport, I mean some underlay, i.e., LSPs that
>>>> points to remote PEs. They could be RSVP/LDP/SR-MPLS in a single domain or
>>>> the exact same options with BGP LSP (IPv6) as E2E LSP through several
>>>> domains. This draft should not restrict any label operations in any way for
>>>> this set. That is what I meant for PHP. With PHP for these LSPs, we can
>>>> face the situation when the IPv4 payload is exposed at the penultimate node.
>>>>
>>>> To avoid the problem with the exposure of the payload this draft offers
>>>> to use the next level of LSPs -- IPv4 labeled unicast LSPs. And we have
>>>> spent some time discussing how to organize them. This is where I was
>>>> talking about the separation of reachability from next-hops signaling. I
>>>> didn't mean PHP for these LSPs. Here we can use either an explicit label
>>>> when we want to make an IPv4 lookup in the IPv4 global routing table or an
>>>> arbitrary label for the rest of the cases (i.e., per-CE, per-prefix, it
>>>> also supports per-table, SR OS uses it by default for per-table). This is
>>>> some form of overlay.
>>>>
>>>> For both, underlay and overlay, explicit labels *and *arbitrary labels
>>>> are possible and the latter do not break anything. I hope we are
>>>> synchronized at this point. For overlay, the selection could be done with a
>>>> variable granularity. Many vendors allow us to set a per-table label (it
>>>> can be an explicit one but not necessarily) for the most prefixes, and set
>>>> dedicated labels for some smaller groups of routes that belong to some
>>>> interfaces of this table (per-CE). It does not depend on whether we send
>>>> all customer's routes as labeled or just next-hops for them.
>>>>
>>>> Third, despite this draft trying to save people from some pitfalls
>>>> (losing frames at the penultimate node when the payload is unlabeled after
>>>> PHP with a single-labeled stack's LSPs) I still think that these options
>>>> shouldn't be excluded from the consideration. If we advertise IPv4 1/1
>>>> routes with IPv6 NHs and PHP is not done, nothing bad happens, right? So,
>>>> from my POV, it is better not to delve into the kingdom of restrictions,
>>>> but to make a clear statement that with PHP for transport/underlay in the
>>>> case of a single-labeled stack, there is a dangerous situation. If a user
>>>> applies a two-labeled or more stack, PHP is possible for all labels prior
>>>> to the bottom one. So there is a simple condition for PHP depending on the
>>>> depth of the stack, and no need to restrict a user with the exact depth.
>>>>
>>>> In summary.
>>>> * The draft should remove all "MUST" corresponding to the procedures of
>>>> sending customers' routes and the selection of AFI/SAFI for them (IPv4 1/1
>>>> vs. 1/4).
>>>> * The draft should not restrict using any labels for transport LSPs
>>>> (arbitrary vs. explicit).
>>>> * The draft should describe the case when the penultimate node drops
>>>> traffic, warn readers, and suggest (not mandate) a more viable alternative.
>>>> * With this alternative (IPv4 LU) there should not be strict
>>>> requirements for sending all customers' routes via 1/4, for some cases, the
>>>> signaling of next-hops is also suitable.
>>>> * The draft should be informational, all the mechanics are already
>>>> available, and the notion of the depth of a label stack is not something
>>>> new.
>>>> * The draft should consider other options, not related to MPLS, or
>>>> related but with nowadays features (e.g., TEA).
>>>>
>>>> Thank you!
>>>>
>>>>
>>>>
>>>>
>>>> ср, 2 авг. 2023 г. в 04:13, Gyan Mishra <[e-mail]>:
>>>>
>>>>>
>>>>> Hi Igor
>>>>>
>>>>> We are making a lot of progress here!
>>>>>
>>>>> Responses in-line Gyan5>
>>>>>
>>>>> On Tue, Aug 1, 2023 at 5:42 PM Igor Malyushkin <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>>        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.
>>>>>>
>>>>>
>>>>>    Gyan5> Understood and points and use cases and reasons for
>>>>> flexibility of arbitrary label are well taken.
>>>>> Just to make sure I am crystal clear.  The use of topmost transport
>>>>> IPv6 explicit null label does not allow you to create the per CE / LSP IPv4
>>>>> context tables or does it.  If so what is the technical reason why you
>>>>> cannot label the loopbacks or CE interface creating an IPv4 LSP to tunnel
>>>>> the per CE prefixes unlabeled.  I missed that if that’s the case so want to
>>>>> understand why your use case is not possible with topmost transport label
>>>>>  IPv6 explicit null.
>>>>>
>>>>> I believe you would like the flexibility of PHP as you have use cases
>>>>> where PHP is necessary.   However that is separate from your primary use
>>>>> case of per CE / LSP IPv4 context tables providing scalability and faster
>>>>> convergence.
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>>    Gyan5> Agreed will fix
>>>>>
>>>>>>
>>>>>> вт, 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*
>>>>>>>
>>>>>>> --
>>>>>
>>>>> <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*
>
>