Re: [OPSAWG] Suresh Krishnan's No Objection on draft-ietf-opsawg-nat-yang-16: (with COMMENT)

[<[e-mail]>]

Hi Suresh, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Suresh Krishnan [mailto:[e-mail]]
> Envoyé : mercredi 26 septembre 2018 15:26
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : The IESG; [e-mail]; [e-mail]; opsawg-
> [e-mail]
> Objet : Re: [OPSAWG] Suresh Krishnan's No Objection on draft-ietf-opsawg-nat-
> yang-16: (with COMMENT)
> 
> Hi Med,
> 
> > On Sep 26, 2018, at 12:47 AM, <[e-mail]>
> <[e-mail]> wrote:
> >
> > Hi Suresh,
> >
> > Adding that default value would make sense if port restriction is only
> reserved to NATs deployed in combination with MAP-E BRs. The document does
> not make that assumption.
> 
> Are there any other expected consumers for this feature (other than MAP-E)?
> An example would be great.

[Med] Without citing other examples such as closed infrastructures in which only a subset of ports are allowed, let's focus on the A+P flavors.

The algorithm approach for identifying port sets is not specific to MAP-E, but is used by other mechanisms such as lightweight 4over6. RFC 7596 says the following:

"For lw4o6, the number of
   a-bits SHOULD be 0, thus allocating a single contiguous port set to
   each lwB4."

 I would think the offset bits (for the system port
> exclusion) and the PSID are fairly specific for MAP-E.

[Med] see above.  

 If there are other
> consumers, how do you ensure that  the value of the ‘a’ bits (i.e. A) needs
> to be greater than zero since I assumed the A>0 check will be done by the
> MAP-E implementation.

[Med] The range of allowed values is clear about this:

          type uint8 {
            range 0..15;
          }

> 
> Thanks
> Suresh