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

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