Re: [Idr] [bess] Suggestion on v4-only/v6-only drafts

[Gyan Mishra <[e-mail]>]

Hi Igor

Thank you for your comments

Understood that 4PE has been implemented by most vendors, however a
standards specification has not been written till now and standardization
of this draft would ensure interoperability as many operators have mix
vendor environments.

Responses in-line

Thanks

On Sat, Nov 12, 2022 at 5:31 PM Igor Malyushkin <[e-mail]>
wrote:

> Hi gents,
>
> I found this conversation curious and started reading the document
> (draft-mishra-idr-v4-islands-v6-core-4pe-02). First, I skipped the section
> about SRv6 because I'm not good at this technology. Maybe the deal is this
> section because I couldn't find anything new in the rest of the document to
> put it into the Standard Track category. It more looks like a list of best
> practices to fire up 4PE in the network.
>

   Gyan> The reason for standardization is to ensure that the process and
procedures implemented by each vendor is the same to ensure
interoperability

Of course, 4PE is already a well-known design pattern that has been
> implemented in lots of network OS and moreover implemented in production
> networks.
>

Gyan> 4PE is well known however it has not been standardized so this would
make it standard across all vendor implementations

Personally, I'm not against having a BCP document that combines everything
> about 4PE together if the authors want to perpetuate the abbreviation.
>

Gyan> I think the process and procedures can be standardized with the
normative language as written to ensure vendor interoperability.  Existing
mechanisms are used however the draft defines procedures to be followed and
that is what would be standardized.

>
>
> The second thing is about wording/writing. I don't want to seem rude or
> something but it was challenging for me to read the document. I believe it
> should be rewritten in a clearer way.
>

Gyan> No worries, I can work with the authors to clean up the writing and
thank you for the feedback.

>
>
> Talking about the 4PE and after reading this document I disagree with the
> idea to use LU as the only way to spread reachability (actually I prefer
> almost not to use it for this task it better suits LSP signaling).
>

Gyan>  The reason for the  BGP LU label binding of all the IPV4 prefixes
tunneled over the core is for the PHP node exposing the native IPv4 packet
which would not have the EXP marking PHB scheduling.  This is exactly what
is done in 6PE as it as well uses BGP-LU for the same reason labeling all
the IPv6 prefixes tunneled.  This is a good example and reason for
standardization.  If one vendor labeled the tunneled prefixes and another
vendor implementation did not we would run into issues.  We have not had at
least in North America and Europe many networks that have migrated to IPv6
core so have not seen interoperability issues however as more operators now
start to migrate to an IPV6 data plane ..MPLS, SR-MPLS, SRV6 we could have
issues so I think it’s important to get this standardized.

This approach governs me to always bind any reachability to a PE but not to
> a CE.
>

Gyan> Yes for an important reason for the PHP node POP and forwarding
native IPv4 packet and breaking EXP scheduling on the last hop to the
egress PE

How can I implement EPE this way?
>

Gyan> You can still implement EPE with BGP-LU SR EPE or EPE w/o SR

What if I want to advertise IPv4 prefixes with vanilla IPv4 (1/1) with
> IPv4-encoded NH (let's say with the CE address) and propagate this NH as
> IPv4 LU with the IPv6 NH?
>

Sure that would work fine.  That is exactly what is stated in the draft as
the process for 4PE.

>
I see a lot of "MUST" preventing me from doing so.
>

   Where ?

Please quote the line or paragraph

Thank you

>
>
> сб, 12 нояб. 2022 г. в 02:08, Gyan Mishra <[e-mail]>:
>
>>
>> Thanks Robert for your feedback on the draft.
>>
>> Dear IDR
>>
>> Please review the draft and provide feedback.
>>
>> Thank you
>>
>> Gyan
>>
>> On Fri, Nov 11, 2022 at 6:46 PM Robert Raszuk <[e-mail]> wrote:
>>
>>> Gyan,
>>>
>>> Returning today from London I did read the draft. It's a great example
>>> of how IETF documents should *NOT* be written. 47 references says it all.
>>> You are mixing pieces from completely different areas all in one place.
>>>
>>> Indeed I encourage everyone to read this draft and submit an opinion to
>>> the list before WG takes any action on it.
>>>
>>> > You mean IPv6 mapped IPv4 address.
>>>
>>> No, I meant what I wrote.
>>>
>>> Kind regards,
>>> R.
>>>
>>>
>>> On Sat, Nov 12, 2022 at 12:13 AM Gyan Mishra <[e-mail]>
>>> wrote:
>>>
>>>> Robert
>>>>
>>>> On Fri, Nov 11, 2022 at 4:49 PM Robert Raszuk <[e-mail]>
>>>> wrote:
>>>>
>>>>> Gyan,
>>>>>
>>>>> RFC8950 is all that is required to be standardized in IDR for
>>>> connecting ipv4 sites over ipv6 core from the perspective of BGP extension
>>>> to propagate reachability in the control plane. /* Btw as stated in my
>>>> previous note even that is not needed if we would solve the requirement
>>>> using v4 mapped v6 addresses. */
>>>>
>>>>    Gyan> 4PE as well as 6PE is more then just reachability extension
>>>> next hop encoding.  Please read the draft and then provide me some feedback
>>>> as it goes over all different inter-as scenarios as well as details
>>>> requirements for 2 level label stack related BGP-LU labeled unicast
>>>> labeling binding of all the IPv4 prefixes.  As well as implicit null PHP
>>>> and explicit null case for RFC 3270 pipe mode support etc.
>>>>
>>>> You mean IPv6 mapped IPv4 address.  That has always been very confusing
>>>> for troubleshooting as the next hop should follow the core protocol used
>>>> for reachability and not the NLRI which would have been done backwards with
>>>> IPv6 mapped IPv4 address and who knows what that would encode you look
>>>> like..  for IPv4 core IPv6 NLRI over and IPv4 next hop is IPv4 mapped IPv6
>>>> address ::FFFF:10.0.0.1.  That was one of the main reasons for encoding
>>>>  simplicity to change to IPv6 address follows the core protocol in RFC 8950
>>>> and not use IPv6 mapped IPv4 address.  Since the mapped address is not a
>>>> legitimate address extra coding hooks need to be done to make it routable
>>>> based on the embedded PE loopback in the next hop address.  All avoided and
>>>> confusion avoided by using RFC 8950 style next hop encoding and not using a
>>>> mapped address.
>>>>
>>>>>
>>>>> > This draft also defines critical extensibility to segment routing
>>>>> SR-MPLS and SRv6 which did
>>>>> > not exist when 6PE RFC 4798 was developed.
>>>>>
>>>>> IDR does not standardize SR-MPLS nor SRv6.
>>>>>
>>>>
>>>>     Gyan> I am not standardizing SR as here just providing
>>>> extensibility of the specification to support Segment Routing.
>>>>
>>>>>
>>>>> > RFC 8950 as stated defines only  the next hop encoding and for
>>>>> example does not define
>>>>> > BGP MPLS VPN RFC 4659 AFI/SAFI 2/128 specification nor does it
>>>>> define BGP LU
>>>>> > RFC 8277 specification  AFI /SAFI 2/4….
>>>>>
>>>>> This is all defined in stated above documents.
>>>>>
>>>>
>>>>     Gyan> My point here is that AFI/SAFI 2/128 and 2/4 use RFC 8950
>>>> which only defines the next hop encoding for the AFI/SAFI and not the
>>>> specification for the AFI/SAFI and thus the RFC.  RFC 4798 6PE uses IPv4
>>>> mapped IPv6 next hop encoding which does not have a next hop encoding
>>>> specification but still does have an RFC for 6PE.  Even if a next hop
>>>> encoding standard existed, that would just be for the next hop encoding,
>>>> does not mean that a standard for 6PE is not necessary for interoperability
>>>> as is the case here.
>>>>
>>>>>
>>>>> IDR drafts focus on required protocol extensions to BGP. I do not see
>>>>> any new protocol extensions in this draft anyway.
>>>>>
>>>>
>>>> Gyan> 6PE RFC 4798 as well does not have a IANA code point allocation
>>>> for a protocol extension, however it does define a procedure and process of
>>>> how 6PE works which is why it was still standardized so ensure
>>>> interoperability between vendor implementations.  There are many more
>>>> examples as such that have
>>>>
>>>>>
>>>>> Regards,
>>>>> R.
>>>>>
>>>>>
>>>>> On Fri, Nov 11, 2022 at 10:38 PM Gyan Mishra <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>> RFC 8950 only defines only the IPv4 NLRI over IPv6 next hop encoding
>>>>>> IANA BGP capability code point 5 that updates RFC 5549 next hop encoding
>>>>>> for SAFI 128 and 129 where the 8 byte RD set to 0 was left of the next hop
>>>>>> encoding specification.
>>>>>>
>>>>>> RFC 8950 as stated defines only  the next hop encoding and for
>>>>>> example does not define BGP MPLS VPN RFC 4659 AFI/SAFI 2/128 specification
>>>>>> nor does it define BGP LU RFC 8277 specification  AFI /SAFI 2/4….
>>>>>>
>>>>>> The next hop encoding is just component of the overall 4PE
>>>>>> specification which did exist till this draft was published.  There are
>>>>>> vendors that have implemented 4PE which may or may not even be called 4PE,
>>>>>> and this draft defines the name “4PE” and what it means form a
>>>>>> specification perspective and thus would ensure the standardization of all
>>>>>> implementations to ensure interoperability.
>>>>>>
>>>>>> As operators start migrating their core to IPv6 this does become a
>>>>>> big deal as most operators have multi vendor environments and so this comes
>>>>>> to the surface as a hot topic to ensure interoperability.
>>>>>>
>>>>>> This draft also defines critical extensibility to segment routing
>>>>>> SR-MPLS and SRv6 which did not exist when 6PE RFC 4798 was developed.
>>>>>>
>>>>>> Many Thanks
>>>>>>
>>>>>> Gyan
>>>>>>
>>>>>> On Fri, Nov 11, 2022 at 3:56 PM Robert Raszuk <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> Gyan,
>>>>>>>
>>>>>>>
>>>>>>>> IDR draft:
>>>>>>>>
>>>>>>>> The 4PE draft connecting IPv4 islands over an IPv6 core  over the
>>>>>>>> global table is similar in semantics to 6PE RFC 4798 which connects IPv6
>>>>>>>> islands over an IPv4 core over the global table and the draft is extensible
>>>>>>>> to SR-MPLS and SRv6. There currently is not a standard for 4PE so this
>>>>>>>> draft would standardize 4PE for vendor  interoperability.
>>>>>>>>
>>>>>>>
>>>>>>> Not true.
>>>>>>>
>>>>>>> Quote from RFC8950:
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> I do not see anything your draft would add to it.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> R.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://datatracker.ietf.org/doc/draft-mishra-idr-v4-islands-v6-core-4pe/
>>>>>>>>
>>>>>>>> BESS drafts - these drafts are completely different from IDR 4PE
>>>>>>>> draft.
>>>>>>>>
>>>>>>>> I have already combined two of the drafts into one for the
>>>>>>>> IPv4-Only PE All SAFI draft
>>>>>>>>
>>>>>>>>
>>>>>>>> https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design-all-safi/
>>>>>>>>
>>>>>>>> IPv6 Only PE Design BCP draft below was adopted  last year and the
>>>>>>>> new draft extensible to ALL SAFI Standards Track below I plan to progress
>>>>>>>> separately.  As one is BCP and the other Standards track I don’t think they
>>>>>>>> could be combined and even if they were combined into the super set all
>>>>>>>> SAFI that would have to go through adoption process again anyway so I plan
>>>>>>>> to keep separate.
>>>>>>>>
>>>>>>>> This draft I will queue up for adoption call.
>>>>>>>>
>>>>>>>>
>>>>>>>> https://datatracker.ietf.org/doc/draft-mishra-bess-ipv6-only-pe-design-all-safi/
>>>>>>>>
>>>>>>>>
>>>>>>>> Many Thanks
>>>>>>>>
>>>>>>>> Gyan
>>>>>>>>
>>>>>>>> On Fri, Nov 11, 2022 at 6:19 AM Ketan Talaulikar <
>>>>>>>> [e-mail]> wrote:
>>>>>>>>
>>>>>>>>> Hi Gyan,
>>>>>>>>>
>>>>>>>>> Sharing a couple of suggestions here for your 5 drafts (4 in
>>>>>>>>> BESS + 1 in IDR) as we lost time due to the audio issues:
>>>>>>>>>
>>>>>>>>> (1) put the portions to be standardized (very focussed/small
>>>>>>>>> hopefully) in one single draft and post/share with both IDR and BESS since
>>>>>>>>> you are changing NH encoding (from what I heard?)
>>>>>>>>> (2) all other informational/BCP material could be combined in a
>>>>>>>>> single draft (perhaps the existing BESS WG draft)
>>>>>>>>>
>>>>>>>>> IMHO, that would facilitate an appropriate focussed review of the
>>>>>>>>> content/proposals.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Ketan
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>
>>>>>>>> <http://www.verizon.com/>
>>>>>>>>
>>>>>>>> *Gyan Mishra*
>>>>>>>>
>>>>>>>> *Network Solutions A**rchitect *
>>>>>>>>
>>>>>>>> *Email [e-mail] <[e-mail]>*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *M 301 502-1347*
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> BESS mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>>>>>
>>>>>>> --
>>>>>>
>>>>>> <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*
>>
>> _______________________________________________
>> 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*