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

["Dikshit, Saumya" <[e-mail]>]

Hello Bess member,

I support the adoption of this draft as a WG document.

Hello Gyan et all,

I have following comments from the fleeting parse of the first half of the draft with tag [SD]


>>>>The Ingress and Egress PE Label Stack on the 4PE router
   contains the Service label with Bottom of Stack "S" bit set and
   contains the IPv4 NLRI prefixes "labeled" using BGP-LU, IPv4 Address
   Family Identifier (AFI) IPv4 (value 1) Subsequent Address Family
   Identifier (SAFI)(value 4).
[SD] I think we need to mention label-space may be distinct/common for each AF/SAFI.



>>>> The 4PE design is fully applicable to both full mesh BGP peering
   between all Ingress and Egress PE's as well as when Route Reflectors
   are utilized as per BGP specification
[SD] You may want to use the term Route-servers as Route reflectors a typical for iBGP peering


>>>>the 4PE
   design described in this document, all such systems MUST support
   building the topmost transport label tunneling using IPv6-signaled
   MPLS LSPs established by LDP [RFC5036<https://datatracker.ietf.org/doc/html/rfc5036>] or Resource Reservation
   Protocol (RSVP-TE) [RFC3209<https://datatracker.ietf.org/doc/html/rfc3209>].
[SD] Is underlay a better mention here, instead of “topmost transport Label tunneling”.
More so, a signaling purists may indicate, that LDP may just form a so called LSP, whereas, RSVP-TE signals a “TE tunnel”.


>>>>While this design concept could theoretically operate in some
   situations using a single level of labels,
[SD] should this be underlay labels and not related to ipv4 prefix labels


>>>> Therefore, on MPLS links that are used for
   transport of IPv4, as per the 4PE approach, and that do not support
   link-specific fragmentation and reassembly, the MTU must be
   configured to at least 576 octets plus the MPLS label stack
   encapsulation overhead bytes.
[SD]For any underlay build upon ipv6, the min mtu size should be a function of 1280. There is a mention of same in the following text, but not here.


>>>> This is
   because, according to [RFC4443<https://datatracker.ietf.org/doc/html/rfc4443>], the core router will build an ICMP
   "Unreachable " message filled with the invoking packet up to 576
   bytes,
[SD] The term “core router”, is it referring to an lsr in the underlay path (LSP or RSVP-TE tunnel). Kindly make it clear.


>>>>  In the 4PE design with Segment Routing SR-MPLS architecture [RFC8660<https://datatracker.ietf.org/doc/html/rfc8660>]
   the design is identical as the IPv6 signaled LSP from ingress PE to
   egress PE is identical but now with underlay traffic steering
   capabilities.
[SD] Needs paraphrasing.

>>> Nitties
Basic Spell checks are missing.

Regards,
Saumya.


From: BESS [mailto:[e-mail]] On Behalf Of Gyan Mishra
Sent: Saturday, November 12, 2022 4:43 AM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: BESS <[e-mail]<mailto:[e-mail]>>; Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] Suggestion on v4-only/v6-only drafts

Robert

On Fri, Nov 11, 2022 at 4:49 PM Robert Raszuk <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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.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/<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/<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/<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]<mailto:[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

--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

_______________________________________________
BESS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bess<https://www.ietf.org/mailman/listinfo/bess>
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347