Re: [sfc] New version of draft-ietf-bess-nsh-bgp-control-plane

[[e-mail]]

Hi Roberta, 

Fully agree. What I had in mind is the AFTR part. 

I also agree that MAP BR is a good candidate item to be listed as SFT. 

That's said, I trust Adrian to do the right thing here. 

Cheers,
Med

> -----Message d'origine-----
> De : Roberta Maglione (robmgl) [mailto:[e-mail]]
> Envoyé : mardi 16 juin 2020 10:05
> À : [e-mail]; BOUCADAIR Mohamed TGI/OLN; [e-mail]
> Objet : RE: [sfc] New version of draft-ietf-bess-nsh-bgp-control-plane
> 
> Med, Adrian,
> I have a couple of comments on this list:
> > With these types:
> >
> >   o  Basic NAT44            ==> Section 2.1 of RFC 3022
> >   o  NAPT44                 ==> Section 2.2 of RFC 3022
> >   o  Destination NAT        ==> RFC 8512
> >   o  NAT64                  ==> RFC 6146
> >   o  SIIT                   ==> RFC 7915
> >   o  EAM                    ==> RFC 7757
> >   o  NPTv6                  ==> RFC 6296
> >   o  DS-Lite                ==> RFC 6333
> 
> I think the term DS-Lite  does not uniquely identify a service function,
> because DSlite has two components/elements B4 and AFTR, each of them
> implementing different functions.
> Here the definitions from RFC 6333:
> AFTR section 6.1 :  "An AFTR element is the combination of an IPv4-in-IPv6
> tunnel endpoint and an IPv4-IPv4 NAT implemented on the same node."
> B4 section 5.1 : " The B4 element is a function implemented on a dual-
> stack-capable node, either a directly connected device or a CPE, that
> creates a tunnel to an AFTR."
> 
> 
> Also if you decide to list in this section all the possible functions for
> IPv4/IPv6 migration technologies other atomic function are missing, like
> for instance MAP BR and CE RFC 7597, RFC 7599
> 
> Thanks
> Roberta
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: sfc <[e-mail]> On Behalf Of Adrian Farrel
> Sent: Monday, June 15, 2020 10:57 PM
> To: [e-mail]; [e-mail]
> Subject: Re: [sfc] New version of draft-ietf-bess-nsh-bgp-control-plane
> 
> Hi Med,
> 
> In line...
> 
> >   o  The SFIR is advertised by the node hosting the service function
> >                                    ^^^^^^^^^^^^
> >      instance (i.e., the SFF).
> >
> >
> > I guess what is meant here is that the SFF is servicing this SFI, not
> > that
> the
> > SFI is embedded in the same node as the SFF. No?
> 
> Yeah. That can be clarified.
> I'll hold it for completion of the IESG discussions.
> 
> > Also, you may consider updating this list:
> >
> >     40    | Network Address Translator    | [This.I-D] | Date-to-be-set
> >     41    | NAT44                         | [This.I-D] | Date-to-be-set
> >     42    | NAT64                         | [This.I-D] | Date-to-be-set
> >     43    | NPTv6                         | [This.I-D] | Date-to-be-set
> >
> > With these types:
> >
> >   o  Basic NAT44            ==> Section 2.1 of RFC 3022
> >   o  NAPT44                 ==> Section 2.2 of RFC 3022
> >   o  Destination NAT        ==> RFC 8512
> >   o  NAT64                  ==> RFC 6146
> >   o  SIIT                   ==> RFC 7915
> >   o  EAM                    ==> RFC 7757
> >   o  NPTv6                  ==> RFC 6296
> >   o  DS-Lite                ==> RFC 6333
> 
> Considered, but not done :-Z
> 
> Our list was derived from RFC 7498 and RFC 8300.
> 
> It's quite likely that the list you give may need to be added, but at the
> moment we don't have much push for more than we've listed. I think other
> additional SFTs can be added at pretty much any time in the future.
> 
> Best,
> Adrian
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.