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

[Gyan Mishra <[e-mail]>]

Hi Igor

My comments in-line Gyan3>

This last thread really helped clear up the use case of arbitrary labels
which comes into play if any implementation desired to not signal implicit
null value 3 by default.  Implicit null default is not a requirement so we
have to account for both use case possibilities.

We are pretty well in sync!!

On Sat, Aug 5, 2023 at 1:11 PM Igor Malyushkin <[e-mail]>
wrote:

> Hi Gyan,
>
> My comments are inline with the IM3 prefix.
>
> сб, 5 авг. 2023 г. в 19:17, Gyan Mishra <[e-mail]>:
>
>> Hi Igor
>>
>> Responses in-line Gyan2>
>>
>> On Thu, Aug 3, 2023 at 2:35 PM Igor Malyushkin <[e-mail]>
>> wrote:
>>
>>> 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.
>>>
>>
>>    Gyan2> Thanks for the clarification on arbitrary label use case which
>> is why the arbitrary label comes into play. So it appear this is a vendor
>> implementation difference.  I think this helps shed some light on the
>> arbitrary label case that you made and helps me understand the use case.
>>
> [IM3] Good! But I don't see where the vendor implementation difference
> comes to play. To me, it is standard behavior for MPLS.
>
>>
>> Since Nokia does not implement implicit null by default, PHP is disabled,
>> so then the  topmost label then can be any arbitrary label and the topmost
>> label is now preserved to the egress LER which then pops the entire stack.
>>
> [IM3] I want you to note that I've never said that Nokia does not
> implement an implicit null. I don't want problems with Nokia fellas :) It
> is turned off by default, yes, but you can easily turn it back. The rest is
> correct.
>

     Gyan3> Ack we are in sync here.  Just for clarity I think both of us
did not say that Nokia did not implement implicit null.  My main point is
that RFC 3031 does not make implicit null a MUST for implementations by
default as long as implicit null is supported.  So Nokia supports
configuration of implicit null, however it is not default and leads to a
valid corner case with arbitrary labels use case where PHP is disabled.
PHP disabled default behavior as well provides an alternative to orthogonal
point that RFC 3270 MPLS QOS Pipe mode using explicit null is not necessary
as now you can use arbitrary topmost labels which are now preserved and do
PHB MPLS QOS EXP scheduling is not broken.  So that based on
implementations over the years makes disabling PHP by default by not
signaling implicit null possibilities as not a corner case at all as there
are many advantages of doing so as we have seen with this thread.
Historically PHP existed to not overburden the LER to pop the entire stack
offloading the load to the egress LSR to POP the topmost label (PHP).  As
well two flavors of implementation to disable PHP, Cisco / Juniper method
of enabling explicit null and Nokia method of disabling implicit null by
default.  I would like to point out that the MPLS QOS EXP scheduling reason
for explicit null or not configuring implicit null is vendor implementation
of being able to PHB schedule MPLS QOS EXP and simultaneously with same
policy schedule on DSCP allows QOS PHB scheduling to not be broken which
both Cisco and Juniper implements, allowing operators to keep the default
PHP behavior and not have to signal explicit null Pipe mode to fix the
scheduling issue.  So there is a quite a number of permutations of designs
based on use case.

>
>> RFC 3031 section 4.1.5 describes the MPLS requirement to support implicit
>> null value 3 signaling done via label mapping message from egress LER to
>> PHP node (egress LSR) to POP the topmost label.  The MPLS standard does not
>> specify that implicit null MUST be the default behavior, however most
>> vendors have implemented as Default behavior.
>>
>
>> Cisco and Juniper use implicit null value 3 signaled by LER to PHP node
>> LSR (egress P) to pop the topmost outer label.  With Nokia implicit null is
>> not default and has to be enabled manually see links below:
>>
> [IM3] See my point above.
>

     Gyan3> Ack

>
>> Cisco supports implicit null signaling for PHP by default link below.
>>
>>
>> https://community.cisco.com/t5/mpls/implicit-null-and-explicit-null/td-p/1496792
>>
>>
>> Juniper supports implicit null signaling by default link below.
>>
>>
>> https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/ref/statement/explicit-null-edit-protocols-mpls.html
>>
>>
>> Nokia does NOT support implicit null signaling by default link below.
>> Since implicit null is a configured option it’s not enabled by default to
>> signal PHP.  Given that is the case AFAIK, any arbitrary label can be
>> preserved and thus you don’t have to use the explicit null label to
>> preserve the topmost label.  All you need to do is disable PHP which is
>> done by default my not signaling implicit null.  Cisco and Juniper as
>> implicit null is default behavior PHP is signaled, however in order to
>> disable PHP explicit null has to be configured.  So then the arbitrary
>> label concept only comes into play with vendors that don’t support PHP by
>> default like Nokia.
>>
>>
>> https://infocenter.nokia.com/public/7750SR217R1A/index.jsp?topic=%2Fcom.nokia.MPLS_Guide_21.7.R1%2Fconfiguring_imp-ai9emdyowp.html
>>
>> Configuring Implicit Null Label
>>
>> The implicit null label option allows an egress LER to receive MPLS
>> packets from the previous hop without the outer LSP label. The user can
>> configure to signal the implicit operation of the previous hop is referred
>> to as penultimate hop popping (PHP). This option is signaled by the egress
>> LER to the previous hop during the FEC signaling by the LDP control
>> protocol.
>>
>> Enable the use of the implicit null option, for all LDP FECs for which
>> this node is the egress LER, using the following command:
>>
>> config>router>ldp>implicit-null-label
>>
>> When the user changes the implicit null configuration option, LDP
>> withdraws all the FECs and re-advertises them using the new label value.
>>
>>>
>>> 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.
>>>
>>
>>    Gyan2> See above what I mentioned about Nokia and PHP signaling via
>> implicit null appears to not be enabled by default.
>>
> I have tested 0, 2, 3 with Cisco and Juniper and I have not run into any
>> issues.  Based on what I stated above I agree the arbitrary label concept I
>> believe only comes into play with vendors such as Nokia that do not have
>> implicit null signaling to trigger the PHP node to POP the topmost
>> transport label.
>>
> [IM3] I don't get the idea of the last sentence. Arbitrary labels (if they
> are supported by a vendor in question) come into play when a network
> engineer decides to turn them on. Their usage is a matter of configuration
> and a design solution.
>
>
     Gyan3> In the last sentence I forgot to say by “default” vendors such
as Nokia that enable implicit null signaling for PHP to be enabled by
default.  The main reason to use arbitrary labels is for UHP to preserve
the topmost label to the egress LER.  Correct?  It’s the exact same reason
to use explicit null signaling to preserve the topmost label so it’s not
popped by the default implicit null PHP enabled mode.  Cisco / Juniper both
support the latter scenario where implicit null is not configurable and
cannot be explicitly enabled or disabled, however in order to switch from
implicit null PHP mode to explicit null UHP mode you have to explicitly
configure explicit null.  So for Cisco and Juniper, arbitrary labels are
not possible as implicit null enable disable state from a configurable
perspective does not exist as implicit null is enabled by default. Nokia
for example does not support implicit null by default and has a
configuration command to enable implicit null and thus by default arbitrary
labels use case is possible.  That is why I say arbitrary labels usage and
use case is based on vendor implementation for the designer to use.  Of
course of its not implemented like with Cisco and Juniper for example it
cannot be used.


Since PHP is disabled on Nokia by default you can now fool the PHP node
>> making it act as a regular LSR.  You are not actually fooling the PHP node,
>> it’s just that implicit null is not signaled by default so PHP is disabled,
>> so when LDP distributes the labels via downstream unsolicited from
>> downstream to upstream nodes and the LSP is instantiated and LIB is
>> allocated and LFIB data plane forwarding is programmed, the LSP is standard
>> swapping on every LSR including the PHP nodes as it did not get signaled
>> for implicit null to POP the transport label so acts as normal LSR swapping
>> labels.  No fooling and is acting as it should with arbitrary labels.
>>
> [IM3] Well, I can not use this term if you don't like it :) By fooling, I
> meant exactly what you stated above. So, looks like we are in sync here.
>

     Gyan> Excellent! We are in sync here!

>
>>>  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.
>>>
>>
>>     Gyan2> Updated arbitrary label use case.  So here  we not signaling
>> PHP with implicit null as some vendors do not signal implicit null value 3
>> by default so PHP is disabled.  So now the topmost arbitrary label is
>> preserved to the egress LER which pops the entire stack and forwards the
>> native IPv4 packet to IPv4 routing context.
>>
> [IM2] In general, yes, except I'm not sure an IPv4 packet is forwarded to
> the IPv4 routing context for every implementation. From my understanding,
> this is vendor-depended behavior. If there is a normative reference to this
> procedure, please, let me know!
>
>>
>>>> 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.
>>>
>>
>>     Gyan2> I believe IPv6 explicit null label as topmost once popped
>> cannot determine the network layer protocol of the unlabeled IPv4
>> underneath and so drops the packet.
>>
>
>
>> But it appear from your test that when using topmost arbitrary label it
>> can determine the network layer protocol type.
>>
> [IM3] Yes, but we should use this information very cautiously. We don't
> know the internals of one or another implementation. I'll repeat myself:
> some vendors do additional packet inspection, while others do not.
>

     Gyan3>  As this use case digs deep into vendor implementation
internals I think it’s fair to exclude 1/1 unlabeled use case under the
topmost both arbitrary or explicit null cases due to the variation in deep
packet inspection being supported or not by vendors.

Based on this we are in sync for 4PE!

1/1 unlabeled is possible but due variance in support or not from 4PE
specification perspective we would have the following use cases:

3 use cases can have topmost be arbitrary or explicit null.

  1st - All CE global table prefixes are labeled
  2nd - PE loopback to PE loopback LSP BOS set that contains all the CE
global table prefixes unlabeled
  3rd - Per CE PE-CE interface label table BOS set  IPv4 routing context
that contains the respective CE prefixes unlabeled

3 use cases of PHP implicit null - have you tested this ?  This should work

 1st - All CE global table prefixes are labeled
  2nd - PE loopback to PE loopback LSP BOS set that contains all the CE
global table prefixes unlabeled
  3rd - Per CE PE-CE interface label table BOS set  IPv4 routing context
that contains the respective CE prefixes unlabeled

For the arbitrary or explicit null 1/1  unlabeled IPv4 prefixes case
confirming we will not include due to the deep packet inspection variable
or maybe could mention with the implementation requirement of deep packet
inspection to infer the network protocol type?

>
>
>>
>> RFC 3032 section 2.2 talks about determining the network layer protocol
>> type of the different protocol type exposed underneath topmost  once the
>> topmost is popped and it says that the network layer protocol type is
>> inferred from the value of label at bottom of stack. I think since explicit
>> null is a special label it cannot infer the protocol type but when using
>> arbitrary it can as proved from your test.
>>
> [IM3] No, that is not what I proved. Please, be careful here. Let me
> explain my point broader. From RFC 3032 (section 2.2) and specifically
> mentioned by you RFC 4182 (section 2), we can understand that the explicit
> labels, if and only if they have a BoS set, point exactly to the network
> protocol they belong to.
>

> RFC4182 (cases for labels with BoS):
>
>        If, on the other hand, the NULL was the only label on the
>           stack, then the stack is now empty.  The resulting packet is
>           treated as an IPv4 packet, and its disposition is based on the
>           IPv4 header.
>
>
>           If, on the other hand, the NULL was the only label on the
>           stack, then the stack is now empty.  The resulting packet is
>           treated as an IPv6 packet, and its disposition is based on the
>           IPv6 header.
>
>

    Gyan3> So for IPv6 explicit null it’s expecting an IPv6 packet and not
IPv4 so the packet would be dropped unless the implementation supports deep
packet inspection to infer the protocol type underneath.  What you quoted
from RFC 4182 section 2 is it says null is the only label in the label
stack so then of course no label with BOS.  This is
the 1/1 use case unlabeled IPv4 packets so no BOS would be present since
it’s a single level label stack. Please clarify.

>
> So, I expect an implementation to drop any IPv4 packets above the label of
> 2 and any IPv6 packets above the label of 0 according to these RFCs as the
> default behavior. However, according to the RFC3032, section 2.2:
>

    Gyan3>. This is for the 1/1 not 1/4 (BOS) set with explicit null
topmost label so I would expect the IPv4 packets to be dropped as that is
based on the vendor implementation of deep packet inspection or not.  This
is the 1/1 use case so no labeled IPv4 prefixes but you are mentioning >=2
. We are talking 4PE which is IPv4 packets over IPv6 core not 6PE which is
IPv6 packets over IPv4 core, so in 6PE case as well the IPv6 packets would
be dropped.  So in both 4PE or 6PE unless the implementation supports deep
packet inspection the 1/1 unlabeled packets would be dropped.

> This means that the identity of the network layer protocol
>    must be inferable from the value of the label which is popped from
>    the bottom of the stack, possibly along with the contents of the
>    network layer header itself.
>
>
> We see that also vendors *can *analyze a network layer header, but it is
> complementary rather than the general behavior (see *possibly*). As I
> understand it, that is exactly what I have seen with the arbitrary label on
> Nokia. From my POV, it is also true for the explicit labels. But I think
> there is no guarantee, that each vendor adheres to this.
>

   Gyan4> Understood on the deep packet inspection and that it’s
complementary optional but not generally implemented.  Agreed.  The thread
above was a bit confusing see above that we are talking about 1/1 not 1/4
so it’s unlabeled IPv4 prefixes with arbitrary or explicit topmost label.

>
>   So I can mention this as a valid use case in the draft which is good
>> reason for arbitrary label.  So IPv6 explicit null is valid and not illegal
>> with the RFC 4182 update in 2005 to be used for any level of label stack
>> including topmost, however for case where the network layer under the
>> topmost is unlabeled you have to use arbitrary label for the IPv4 packet to
>> be inferred and not dropped.
>>
> [IM3] I will highlight it here too for additional clearance. Neither
> arbitrary nor explicit labels guarantee us that the IPv4 payload will be
> forwarded. That is why I think, the draft should clearly warn readers.
>

     Gyan3> Ack and just to be crystal clear again this is 1/1 use case for
arbitrary or explicit null topmost.

>
>
>>> [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/>
>>>>>>>>>>>
>>>>>>>>>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*