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

[Robert Raszuk <[e-mail]>]

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