Re: [OPSAWG] Should the schedule YANG model be seperated from draft-ietf-opsawg-ucl-acl?

[Tianran Zhou]

QUESTION FOR THE CHAIRS
If this is split out, does it o into an individual draft for a further adoption 
poll, or can it be split into a second WG ID at once?

ZTR> In my opinion, it should go into an individual draft. We adopted 
draft-ietf-opsawg-ucl-acl because of the whole solution. Scheduling in this 
solution is only a component and very specific. If we want to generalize the 
scheduling for services, resources, etc, the common model is new work.

Best,
Tianran

发件人: OPSAWG  代表 Adrian Farrel
发送时间: 2023年10月10日 10:06
收件人: maqiufang (A) ; opsawg@ietf.org
抄送: draft-ietf-opsawg-ucl-...@ietf.org
主题: Re: [OPSAWG] Should the schedule YANG model be seperated from 
draft-ietf-opsawg-ucl-acl?

As I said in my original comment, I’d like to see this separation. Various 
recent conversations suggest that scheduling (services, resources, ACLs, etc.) 
is becoming a Big Thing. Having a common model to facilitate this would be 
really helpful.

QUESTION FOR THE CHAIRS
If this is split out, does it o into an individual draft for a further adoption 
poll, or can it be split into a second WG ID at once?

A

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of maqiufang (A)
Sent: 07 October 2023 11:48
To: opsawg@ietf.org
Cc: 
draft-ietf-opsawg-ucl-...@ietf.org
Subject: [OPSAWG] Should the schedule YANG model be seperated from 
draft-ietf-opsawg-ucl-acl?

Hi, all

Based on the comments we’ve received during the adoption call of 
draft-ma-opsawg-ucl-acl [1], the authors would like to start a separate thread 
to highlight a question raised by Adrian:
should the schedule model be moved out into a separate document? And we would 
like to collect more feedback from the WG.

It is indeed that the ietf-schedule YANG model in the draft is now designed to 
be applicable in other common scheduling contexts and not specific to ACL 
policies.
The authors already see some usage of it in other date and time based 
context[2], and it might seem awkward for it (and other potential ones in the 
future) to reference draft-ietf-opsawg-ucl-acl for reusing the scheduling 
groupings.

It would be good to know if the WG think it useful for this model to be defined 
in a separate document, so that the authors will take the time to work on it if 
there is consensus.
Would appreciate any of your input, thanks a lot!


[1] https://datatracker.ietf.org/doc/draft-ietf-opsawg-ucl-acl/
[2] 
https://datatracker.ietf.org/doc/draft-contreras-opsawg-scheduling-oam-tests/


Best Regards,
Qiufang
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

[Adrian Farrel]

Thanks for asking, Joe.

 

Yes, I think that the WG should be working on ACs. Yes, I think that this
set of I-Ds form the basis for what needs to be covered.

 

I am *slightly* queasy about there being four documents. I'd be happier if
some consolidation were possible. But I have no concrete suggestions, and if
the authors/WG think that this is the right number then I will support that
decision.

 

Adrian

 

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: 02 October 2023 14:22
To: opsawg@ietf.org
Subject: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

 

At IETF 117, we asked the room if there was support to adopt the four
attachment circuits drafts.  The room had support (of the 75 present, 18
raised hands for adoption interest, 1 was opposed), but the list is where it
counts.

 

While the drafts aren't too terribly long, there are four of them, so we
will do a three week call for adoption.  Please review and comment on-list
on the following indicating whether you support their adoption or not:

 

*   draft-boro-opsawg-teas-common-ac
*   draft-boro-opsawg-teas-attachment-circuit
*   draft-boro-opsawg-ntw-attachment-circuit
*   draft-boro-opsawg-ac-lxsm-lxnm-glue

 

The authors and contributors have all signaled there is no known IPR
covering this work.

 

The CfA will end on October 23.

 

Thanks.

 

Joe

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Should the schedule YANG model be seperated from draft-ietf-opsawg-ucl-acl?

[Adrian Farrel]

As I said in my original comment, I'd like to see this separation. Various
recent conversations suggest that scheduling (services, resources, ACLs,
etc.) is becoming a Big Thing. Having a common model to facilitate this
would be really helpful.

 

QUESTION FOR THE CHAIRS

If this is split out, does it o into an individual draft for a further
adoption poll, or can it be split into a second WG ID at once?

 

A

 

From: OPSAWG  On Behalf Of maqiufang (A)
Sent: 07 October 2023 11:48
To: opsawg@ietf.org
Cc: draft-ietf-opsawg-ucl-...@ietf.org
Subject: [OPSAWG] Should the schedule YANG model be seperated from
draft-ietf-opsawg-ucl-acl?

 

Hi, all

 

Based on the comments we've received during the adoption call of
draft-ma-opsawg-ucl-acl [1], the authors would like to start a separate
thread to highlight a question raised by Adrian:

should the schedule model be moved out into a separate document? And we
would like to collect more feedback from the WG. 

 

It is indeed that the ietf-schedule YANG model in the draft is now designed
to be applicable in other common scheduling contexts and not specific to ACL
policies. 

The authors already see some usage of it in other date and time based
context[2], and it might seem awkward for it (and other potential ones in
the future) to reference draft-ietf-opsawg-ucl-acl for reusing the
scheduling groupings.

 

It would be good to know if the WG think it useful for this model to be
defined in a separate document, so that the authors will take the time to
work on it if there is consensus.

Would appreciate any of your input, thanks a lot!

 

 

[1] https://datatracker.ietf.org/doc/draft-ietf-opsawg-ucl-acl/ 

[2]
https://datatracker.ietf.org/doc/draft-contreras-opsawg-scheduling-oam-tests
/ 

 

 

Best Regards,

Qiufang

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02

[mohamed . boucadair]

Re-,

Thanks for the follow-up.

For "No Next Header", I added the following so far to 
draft-ietf-opsawg-ipfix-tcpo-v6eh:

 The "No Next Header" (59) value is used if there is no upper-layer
  header in an IPv6 packet.  Even if the value is not considered as
  an extension header as such, the corresponding bit is set in the
  ipv6ExtensionHeadersFull IE whenever that value is encountered in
  the Flow.

Cheers,
Med

De : Eric Vyncke (evyncke) 
Envoyé : lundi 9 octobre 2023 16:44
À : BOUCADAIR Mohamed INNOV/NET ; opsawg@ietf.org
Cc : ip...@ietf.org
Objet : Re: Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02

Hello Med,

Thanks for the conversation on this interesting topic.

See in-line for EVY>

Bien à toi,

-éric

From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Date: Monday, 9 October 2023 at 11:32
To: Eric Vyncke (evyncke) mailto:evyn...@cisco.com>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>
Cc: ip...@ietf.org 
mailto:ip...@ietf.org>>
Subject: RE: Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02
Hi Éric,

Thank you for the review.

Please see inline.

Cheers,
Med

De : OPSAWG mailto:opsawg-boun...@ietf.org>> De la 
part de Eric Vyncke (evyncke)
Envoyé : vendredi 6 octobre 2023 13:46
À : opsawg@ietf.org
Cc : ip...@ietf.org
Objet : [OPSAWG] Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02

Benoît and Med,

Thanks for this document, please find below some comments on the IPv6 sections 
(4.1 and 9.1), obviously wearing no hat. I like the idea of creating a registry 
mapping IPFIX IE bits to IPv6 extension headers, even if there won't be any new 
IPv6 extension headers.

Another important issue is to export whether the full extension header chain 
has been parsed as some HW can only process so many headers or so many bytes. 
In this case, the bit mask is obviously incomplete. This could of course be 
another bit in the mask and could be specified in the companion I-D, 
draft-ietf-opsawg-ipfix-tcpo-v6eh.

[Med] Added this note:

"Some implementations may not be able to export all enclosed extension headers 
because of a hardware of software limit (see, e.g., 
{{?I-D.ietf-6man-eh-limits}}. The specification of the ipv6ExtensionHeaders 
Information Element does not discuss whether it covers all enclosed extension 
header or only update to a limit."

Let's discuss whether an explicit signal is needed to be encoded for this in 
draft-ietf-opsawg-ipfix-tcpo-v6eh.

EVY> fair enough, i.e., it looks good to me ;-)


# Section 9.1

Should there be an entry to "no next header" value ?
[Med] Not sure there is a value in exporting this one as part of the set. Do 
you see any? Thanks.

EVY> I tend to see value in 'sensing/measuring' what happens in a network. 
Else, the operator will never know that this header is used, or did I miss 
something ?

Should there be different bits for "destination options" as this one can happen 
*before* and *after* routing header ? Similar to FRA0 and FRA1 bits ?
[Med] This would be a major change to the IE while 
draft-ietf-opsawg-ipfix-fixes is supposed to cover simple "fixes". 
draft-ietf-opsawg-ipfix-tcpo-v6eh addresses this as part of 
ipv6ExtensionHeaderCount.

EVY> as long as the 2 destination headers issue is fixed, I do not care in 
which document (even if the bit mask - this document - is easy to parse).

Please replace the "IPv6 options" column by "IP protocol number" or "IPv6 
Next-Header Values"
[Med] OK, changed to "Protocol Number"

Use "IPv6 Hop-by-Hop Options" (plural) per RFC 8200 (even the IANA-EH registry 
is singular)
[Med] ACK.

The first "Note" already appears a couple of lines above ;-)
[Med] Yes, the second one is for action by IANA.

Hope this helps
[Med] Thank you.

EV> thanks for your reply

-éric









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.

Re: [OPSAWG] Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02

[Eric Vyncke (evyncke)]

Hello Med,

Thanks for the conversation on this interesting topic.

See in-line for EVY>

Bien à toi,

-éric

From: mohamed.boucad...@orange.com 
Date: Monday, 9 October 2023 at 11:32
To: Eric Vyncke (evyncke) , opsawg@ietf.org 
Cc: ip...@ietf.org 
Subject: RE: Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02
Hi Éric,

Thank you for the review.

Please see inline.

Cheers,
Med

De : OPSAWG  De la part de Eric Vyncke (evyncke)
Envoyé : vendredi 6 octobre 2023 13:46
À : opsawg@ietf.org
Cc : ip...@ietf.org
Objet : [OPSAWG] Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02

Benoît and Med,

Thanks for this document, please find below some comments on the IPv6 sections 
(4.1 and 9.1), obviously wearing no hat. I like the idea of creating a registry 
mapping IPFIX IE bits to IPv6 extension headers, even if there won’t be any new 
IPv6 extension headers.

Another important issue is to export whether the full extension header chain 
has been parsed as some HW can only process so many headers or so many bytes. 
In this case, the bit mask is obviously incomplete. This could of course be 
another bit in the mask and could be specified in the companion I-D, 
draft-ietf-opsawg-ipfix-tcpo-v6eh.

[Med] Added this note:

“Some implementations may not be able to export all enclosed extension headers 
because of a hardware of software limit (see, e.g., 
{{?I-D.ietf-6man-eh-limits}}. The specification of the ipv6ExtensionHeaders 
Information Element does not discuss whether it covers all enclosed extension 
header or only update to a limit.”

Let’s discuss whether an explicit signal is needed to be encoded for this in 
draft-ietf-opsawg-ipfix-tcpo-v6eh.

EVY> fair enough, i.e., it looks good to me ;-)


# Section 9.1

Should there be an entry to “no next header” value ?
[Med] Not sure there is a value in exporting this one as part of the set. Do 
you see any? Thanks.

EVY> I tend to see value in ‘sensing/measuring’ what happens in a network. 
Else, the operator will never know that this header is used, or did I miss 
something ?

Should there be different bits for “destination options” as this one can happen 
*before* and *after* routing header ? Similar to FRA0 and FRA1 bits ?
[Med] This would be a major change to the IE while 
draft-ietf-opsawg-ipfix-fixes is supposed to cover simple “fixes”. 
draft-ietf-opsawg-ipfix-tcpo-v6eh addresses this as part of 
ipv6ExtensionHeaderCount.

EVY> as long as the 2 destination headers issue is fixed, I do not care in 
which document (even if the bit mask – this document – is easy to parse).

Please replace the “IPv6 options” column by “IP protocol number” or “IPv6 
Next-Header Values”
[Med] OK, changed to “Protocol Number”

Use “IPv6 Hop-by-Hop Options” (plural) per RFC 8200 (even the IANA-EH registry 
is singular)
[Med] ACK.

The first “Note” already appears a couple of lines above ;-)
[Med] Yes, the second one is for action by IANA.

Hope this helps
[Med] Thank you.

EV> thanks for your reply

-éric









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.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Length of EHs RE: About draft-boucadair-opsawg-ipfix-tcpo-v6eh

[mohamed . boucadair]

Hi Éric, all,

> - what would also be SUPER interesting / useful is the length of those
> Ext Headers and their order...

The order part of the comment was already addressed. 

For the length, I think that the aggregate length would be more useful to 
explain packet drops, use of slow paths, etc. 

Please see a proposed PR to cover this issue at: 
https://github.com/boucadair/ipfix-tcpoptions-and-v6eh/pull/8/files.

Comments are more than welcome.

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de Eric Vyncke
> (evyncke)
> Envoyé : samedi 27 mai 2023 18:17
> À : opsawg@ietf.org
> Objet : [OPSAWG] About draft-boucadair-opsawg-ipfix-tcpo-v6eh
> 
> Benoît, Med,
> 
> I just found draft-boucadair-opsawg-ipfix-tcpo-v6eh and the idea
> behind this I-D seems very attractive to me. Do you intend to request
> adoption ?
> 
> BTW, if you do not mind some comments:
> - why not covering also IPv4 options ? Or split this I-D in two parts
> ?
> - how would an 'old' implementation (post a potential future
> publication of this I-D) differentiate between "unknown ext header"
> (this set is normally closed but who knows) and "unknown L4 header"
> and "unknow IP protocol" ?
> - ipv6ExtensionHeadersFull is redundant (always annoying) with
> ipv6ExtensionHeaderCount
> - what would also be SUPER interesting / useful is the length of those
> Ext Headers and their order...
> 
> I look forward to reading (or even working with you) more on this I-D
> 
> Regards
> 
> -éric
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fopsawg=05%7C01%7Cmohamed.boucadai
> r%40orange.com%7C602e6339fda948514e4308db5ecdd890%7C90c7a20af34b40bfbc
> 48b9253b6f5d20%7C0%7C0%7C638208010436919708%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C=nIqtkrl%2FS5M5Oh2yUy4X8ITGHI8E4eTjDnmRqIio%2BhI%3D
> served=0

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.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [radext] draft-ietf-opsawg-ucl-acl: User Access Control Group ID RADIUS Attribute

[mohamed . boucadair]

Re-,

Great, thanks. 

Yes, I confirm that the reference is cited as informative. 

Cheers,
Med

> -Message d'origine-
> De : Alan DeKok 
> Envoyé : lundi 9 octobre 2023 14:26
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : rad...@ietf.org; opsawg ; draft-ma-opsawg-ucl-
> a...@ietf.org
> Objet : Re: [radext] draft-ietf-opsawg-ucl-acl: User Access Control
> Group ID RADIUS Attribute
> 
> On Oct 9, 2023, at 3:06 AM, mohamed.boucad...@orange.com wrote:
> > We prepared a PR to address these at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fboucadair%2Fpolicy-based-network-
> acl%2Fpull%2F18%2Ffiles=05%7C01%7Cmohamed.boucadair%40orange.com%
> 7C302f3ea4943e469daa5908dbc8c2ee41%7C90c7a20af34b40bfbc48b9253b6f5d20%
> 7C0%7C0%7C638324511765512476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> a=aswcKGnWgTfRCHIKETwdFHuPPxT1eo2OKRglWfj%2BVFw%3D=0
> 
>   That looks good, thanks.
> 
> > I think that it is better to refer to a RADEXT doc (e.g., Section
> 7.3 of draft-dekok-radext-deprecating-radius) rather than duplicating
> the reco in the doc.
> 
>   Sure.  That reference should informative, as the deprecation doc may
> take a while to be published.  That way it doesn't block your
> document.
> 
>   Alan DeKok.


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.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [radext] draft-ietf-opsawg-ucl-acl: User Access Control Group ID RADIUS Attribute

[Alan DeKok]

On Oct 9, 2023, at 3:06 AM, mohamed.boucad...@orange.com wrote:
> We prepared a PR to address these at: 
> https://github.com/boucadair/policy-based-network-acl/pull/18/files

  That looks good, thanks.

> I think that it is better to refer to a RADEXT doc (e.g., Section 7.3 of 
> draft-dekok-radext-deprecating-radius) rather than duplicating the reco in 
> the doc. 

  Sure.  That reference should informative, as the deprecation doc may take a 
while to be published.  That way it doesn't block your document.

  Alan DeKok.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] count of EHs (RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

[mohamed . boucadair]

Re-,

Focusing on this part of your comments:

==
About having counters per extension header how is "This Information Element 
echoes the order and number of occurrences" to be interpreted for the following 
flow?

HBH-RH-DST
HBH-DST-RH-FRA0-DST
HBH-DST-RH-FRA1-...
RH-DST

Will it be a single IE with HBH=3, DST=5, RH=3, FRA0=1, FRA1=1 or 4 IE exported 
(one for each chain) ?

I think that the 4 IE sounds more logical and useful, then there is no need to 
count the occurrences of one specific EH but more how often a specific EH chain 
was seen.
==

Yes, I confirm that 4 IEs will be exported.

The count is still needed to report cases where an EH appear multiple times in 
the same chain. Updated the text to insist the count is related to consecutive 
occurrences, though:

OLD:
   Description:  As per [RFC8200], IPv6 nodes must accept and attempt to
  process extension headers in occurring any number of times in the
  same packet.  This Information Element echoes the order and number
  of occurrences of the same extension header instance in an IPv6
  packet.

NEW:

   Description:  As per Section 4.1 of [RFC8200], IPv6 nodes must accept

  and attempt to process extension headers in occurring any number

  of times in the same packet.  This Information Element echoes the

  order of extension headers and number of consecutive occurrences

  of the same extension header type in an IPv6 packet.



  The same extension header type may appear several times in an

  ipv6ExtensionHeaderCount Information Element (see Section 4.1 of

  [RFC8200].  For example, if an IPv6 packet includes a Hop-by-Hop

  Options header, a Destination Options header, a Fragment header,

  and Destination Options header, the ipv6ExtensionHeaderCount

  Information Element will report two counts of the Destination

  Options header: the occurrences that are observed before the

  Fragment header and the occurrences right after the Fragment

  header.

Cheers,
Med

De : OPSAWG  De la part de Eric Vyncke (evyncke)
Envoyé : vendredi 6 octobre 2023 14:49
À : opsawg@ietf.org
Cc : ip...@ietf.org
Objet : [OPSAWG] Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

Benoît and Med,

Thanks for this useful document, please find below some comments (obviously 
without any hat).

Should the "No Next-Header" (next-header=59) be included (cfr my other remarks 
on the companion I-D) ?

There should be a way to convey the information that the exporter was (un)able 
to parse the *full* extension header chain due to HW limitation. This could be 
done by adding a bit/counter "KNOWN" (the opposite of UNKNOWN in the sense of a 
known layer-4 header).

About having counters per extension header how is "This Information Element 
echoes the order and number of occurrences" to be interpreted for the following 
flow?

HBH-RH-DST
HBH-DST-RH-FRA0-DST
HBH-DST-RH-FRA1-...
RH-DST

Will it be a single IE with HBH=3, DST=5, RH=3, FRA0=1, FRA1=1 or 4 IE exported 
(one for each chain) ?

I think that the 4 IE sounds more logical and useful, then there is no need to 
count the occurrences of one specific EH but more how often a specific EH chain 
was seen.

I still wonder why the tcpOptions and ipv6ExtensionHeaders are in the same I-D 
though ;-)

Hope this helps,

-éric


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.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Full or Truncated EHs RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

[mohamed . boucadair]

Hi Éric,

"There should be a way to convey the information that the exporter was (un)able 
to parse the *full* extension header chain due to HW limitation. This could be 
done by adding a bit/counter "KNOWN" (the opposite of UNKNOWN in the sense of a 
known layer-4 header)."

I think that it would be simple to return that in a separate IE. Please refer 
to the proposal at: Extended TCP Options and IPv6 Extension Headers IPFIX 
Information Elements 
(boucadair.github.io).

The absence of this IE is an indication that any EH-related IE reflect the full 
set of enclosed EHs.

Cheers,
Med

De : OPSAWG  De la part de Eric Vyncke (evyncke)
Envoyé : vendredi 6 octobre 2023 14:49
À : opsawg@ietf.org
Cc : ip...@ietf.org
Objet : [OPSAWG] Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

Benoît and Med,

Thanks for this useful document, please find below some comments (obviously 
without any hat).

Should the "No Next-Header" (next-header=59) be included (cfr my other remarks 
on the companion I-D) ?

There should be a way to convey the information that the exporter was (un)able 
to parse the *full* extension header chain due to HW limitation. This could be 
done by adding a bit/counter "KNOWN" (the opposite of UNKNOWN in the sense of a 
known layer-4 header).

About having counters per extension header how is "This Information Element 
echoes the order and number of occurrences" to be interpreted for the following 
flow?

HBH-RH-DST
HBH-DST-RH-FRA0-DST
HBH-DST-RH-FRA1-...
RH-DST

Will it be a single IE with HBH=3, DST=5, RH=3, FRA0=1, FRA1=1 or 4 IE exported 
(one for each chain) ?

I think that the 4 IE sounds more logical and useful, then there is no need to 
count the occurrences of one specific EH but more how often a specific EH chain 
was seen.

I still wonder why the tcpOptions and ipv6ExtensionHeaders are in the same I-D 
though ;-)

Hope this helps,

-éric


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.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02

[mohamed . boucadair]

Hi Éric,

Thank you for the review.

Please see inline.

Cheers,
Med

De : OPSAWG  De la part de Eric Vyncke (evyncke)
Envoyé : vendredi 6 octobre 2023 13:46
À : opsawg@ietf.org
Cc : ip...@ietf.org
Objet : [OPSAWG] Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02

Benoît and Med,

Thanks for this document, please find below some comments on the IPv6 sections 
(4.1 and 9.1), obviously wearing no hat. I like the idea of creating a registry 
mapping IPFIX IE bits to IPv6 extension headers, even if there won't be any new 
IPv6 extension headers.

Another important issue is to export whether the full extension header chain 
has been parsed as some HW can only process so many headers or so many bytes. 
In this case, the bit mask is obviously incomplete. This could of course be 
another bit in the mask and could be specified in the companion I-D, 
draft-ietf-opsawg-ipfix-tcpo-v6eh.

[Med] Added this note:

"Some implementations may not be able to export all enclosed extension headers 
because of a hardware of software limit (see, e.g., 
{{?I-D.ietf-6man-eh-limits}}. The specification of the ipv6ExtensionHeaders 
Information Element does not discuss whether it covers all enclosed extension 
header or only update to a limit."

Let's discuss whether an explicit signal is needed to be encoded for this in 
draft-ietf-opsawg-ipfix-tcpo-v6eh.


# Section 9.1

Should there be an entry to "no next header" value ?
[Med] Not sure there is a value in exporting this one as part of the set. Do 
you see any? Thanks.

Should there be different bits for "destination options" as this one can happen 
*before* and *after* routing header ? Similar to FRA0 and FRA1 bits ?
[Med] This would be a major change to the IE while 
draft-ietf-opsawg-ipfix-fixes is supposed to cover simple "fixes". 
draft-ietf-opsawg-ipfix-tcpo-v6eh addresses this as part of 
ipv6ExtensionHeaderCount.

Please replace the "IPv6 options" column by "IP protocol number" or "IPv6 
Next-Header Values"
[Med] OK, changed to "Protocol Number"

Use "IPv6 Hop-by-Hop Options" (plural) per RFC 8200 (even the IANA-EH registry 
is singular)
[Med] ACK.

The first "Note" already appears a couple of lines above ;-)
[Med] Yes, the second one is for action by IANA.

Hope this helps
[Med] Thank you.

-éric







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.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Desambiguite unknwon EH vs. unknown upper layer headers RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

[Eric Vyncke (evyncke)]

Med,

You may also want to state the obvious, i.e., the subsequent EH are neither 
parsed nor counted.

From: mohamed.boucad...@orange.com 
Date: Friday, 6 October 2023 at 16:20
To: Eric Vyncke (evyncke) , opsawg@ietf.org 
Cc: ip...@ietf.org 
Subject: Desambiguite unknwon EH vs. unknown upper layer headers RE: Some 
comments on draft-ietf-opsawg-ipfix-tcpo-v6eh
Re-,

Your comment about “unknown L4” reminded me another comment you had about how 
to disambiguate unknown EH vs. upper layer headers:

Our local copy includes now the following NEW text:
   If an implementation determines that it includes an extension header
   that it does no support, then the exact observed code of that
   extension header will be echoed in the ipv6ExtensionHeadersFull IE.
   How an implementation disambiguates between unknown upper layers vs.
   extension headers is not IPFIX-specific.

See Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh-01.txt - 
draft-ietf-opsawg-ipfix-tcpo-v6eh.txt

Please let us know if you think this is (not) sufficient. Thanks

Cheers,
Med

De : OPSAWG  De la part de Eric Vyncke (evyncke)
Envoyé : vendredi 6 octobre 2023 14:49
À : opsawg@ietf.org
Cc : ip...@ietf.org
Objet : [OPSAWG] Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

Benoît and Med,

Thanks for this useful document, please find below some comments (obviously 
without any hat).

Should the “No Next-Header” (next-header=59) be included (cfr my other remarks 
on the companion I-D) ?

There should be a way to convey the information that the exporter was (un)able 
to parse the *full* extension header chain due to HW limitation. This could be 
done by adding a bit/counter “KNOWN” (the opposite of UNKNOWN in the sense of a 
known layer-4 header).

About having counters per extension header how is “This Information Element 
echoes the order and number of occurrences” to be interpreted for the following 
flow?

HBH-RH-DST
HBH-DST-RH-FRA0-DST
HBH-DST-RH-FRA1-...
RH-DST

Will it be a single IE with HBH=3, DST=5, RH=3, FRA0=1, FRA1=1 or 4 IE exported 
(one for each chain) ?

I think that the 4 IE sounds more logical and useful, then there is no need to 
count the occurrences of one specific EH but more how often a specific EH chain 
was seen.

I still wonder why the tcpOptions and ipv6ExtensionHeaders are in the same I-D 
though ;-)

Hope this helps,

-éric




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.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [radext] draft-ietf-opsawg-ucl-acl: User Access Control Group ID RADIUS Attribute

[mohamed . boucadair]

Hi Alan, 

Thank you for the review and comments.

We prepared a PR to address these at: 
https://github.com/boucadair/policy-based-network-acl/pull/18/files

Please note that for this one:  

>   It may be good to give an example packet, but that may also be too
> restrictive.  What should be discussed is what format is used by the
> credentials.  i.e. User-Password or CHAP-Password.  Given other
> discussions and research in RADEXT, it would be good to suggest here
> that User-Password is strongly preferred to the alternatives.

I think that it is better to refer to a RADEXT doc (e.g., Section 7.3 of 
draft-dekok-radext-deprecating-radius) rather than duplicating the reco in the 
doc. 

Cheers,
Med

> -Message d'origine-
> De : radext  De la part de Alan DeKok
> Envoyé : mardi 26 septembre 2023 14:37
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : rad...@ietf.org; opsawg ; draft-ma-opsawg-ucl-
> a...@ietf.org
> Objet : Re: [radext] draft-ietf-opsawg-ucl-acl: User Access Control
> Group ID RADIUS Attribute
> 
> On Sep 26, 2023, at 8:00 AM, mohamed.boucad...@orange.com wrote:
> >
> > Hi RADEXT,
> >
> > FWIW, the document specifies the following new RADIUS attribute:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbouc
> adair.github.io%2Fpolicy-based-network-acl%2Fdraft-ietf-opsawg-ucl-
> acl.html%23name-user-access-control-group-
> i=05%7C01%7Cmohamed.boucadair%40orange.com%7C305c160d37f64930767b
> 08dbbe8d6976%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638313286796
> 267255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=TnIp9ejIAK5V6F%2BAvk
> Y8c%2BeZ93Ph9hQwahIv%2FqgobRc%3D=0
> >
> > Your review of that part of the spec is appreciated.
> 
>   My $0.02 as someone jumping on these kinds of things.  Mostly nits.
> 
> > The value fields of the Attribute are encoded in clear and not
> encrypted as, for example, Tunnel- Password Attribute [RFC2868].
> 
>   This text isn't necessary and can be omitted.
> 
> > The User-Access-Group-ID Attribute MAY appear in a RADIUS
> Accounting- Request packet.
> 
>   What is the interpretation of the attribute there?
> 
>   i.e. in Access-Request, it's a hint / request.  In Accounting-
> Request, it means... ?
> 
>   I think the requirement here is that if the User-Access-Group-ID
> attribute appears in an Accounting-Request packets, it MUST have the
> same value as given in the Access-Accept.
> 
>   That is, the value in Accounting-Request is an acknowledgment by the
> NAS that it has received the attribute in the Access-Request, and is
> enforcing that policy.
> 
> > The User-Access-Group-ID Attribute is structured as follows:
> 
>   I would suggest following the attribute definition format suggested
> in 8044:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Frfc%2Frfc8044%23section-
> 2.1.3=05%7C01%7Cmohamed.boucadair%40orange.com%7C305c160d37f64930
> 767b08dbbe8d6976%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63831328
> 6796267255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=k1J421hRuReCJAlY
> ZCrMCWZYa%2BsixIs0eC86%2BHdWNLw%3D=0
> 
>   It's only a minor change from what is there now.  Add a "data type"
> field, and remove the "extended type" field.
> 
> > The User-Access-Group-ID Attribute is associated with the following
> identifier: 241.TBA1.
> 
>   This text isn't necessary and can be omitted.  Just leave a "TBD" in
> the Type field as recommended by 8044.
> 
> > The following table provides a guide as what type of RADIUS packets
> that may contain User-Access-Group-ID Attribute, and in what quantity.
> 
>   It's not necessary to list the attribute number here.  Just omit
> that column.  Identifying the attribute by name is enough
> 
>   I'll also note that this table allows for multiple copies of the
> attribute to exist (i.e. "0+").  The rest of the text in the section
> doesn't mention that more than one attribute are allowed.  The text
> should be updated to explain what that means.
> 
>   Perhaps something like "If more than one copy of the User-Access-
> Group-ID attribute appears in an Access-Accept packet, it means that
> the user is a member of all of those groups."
> 
>   I haven't taken a detailed look at the rest of the document, but
> this text in Section 4.1 jumped out at me:
> 
> > Step 3: The authentication request is then relayed to the AAA server
> using a protocol such as RADIUS [RFC2865]. It is assumed that the AAA
> server has been appropriately configured to store user credentials,
> e.g., user name, password, group information and other user
> attributes.
> 
>   It may be good to give an example packet, but that may also be too
> restrictive.  What should be discussed is what format is used by the
> credentials.  i.e. User-Password or CHAP-Password.  Given other
> discussions and research in RADEXT, it would be good to suggest here
> that