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

[Igor Malyushkin <[e-mail]>]

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. 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. Personally, I'm not
against having a BCP document that combines everything about 4PE together
if the authors want to perpetuate the abbreviation.

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.

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). This
approach governs me to always bind any reachability to a PE but not to a
CE. How can I implement EPE this way? 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? I see a lot
of "MUST" preventing me from doing so.


сб, 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
>