Re: [OPSAWG] ipfix-fwd-exceptions - Request WG adoption

2023-11-16 Thread mohamed . boucadair 
Hi all,

I agree with Benoît that the justification of limited space (64 values) seems 
to be weak given existing codes and proposed new ones. However, after reading 
RFC 7270, I think that there might be a value in refreshing the existing IE#89 
for the sake of better interoperability and promoting it to the Standard Track. 
Please note also that some of the subcodes are weakly defined (e.g., adjacent, 
for us) in RFC7270.

Cheers,
Med

De : OPSAWG  De la part de Benoit Claise
Envoyé : mardi 14 novembre 2023 14:40
À : Venkata Naga Chaitanya Munukutla ; 
opsawg@ietf.org
Cc : Shivam Vaid ; Vishnu Pavan Beeram 
; Aditya Mahale ; 
pateldev...@google.com
Objet : Re: [OPSAWG] ipfix-fwd-exceptions - Request WG adoption

Dear Chaitana,

If finally read the draft.

You mentioned:

There is an existing IE 89 - forwardingStatus 
[IANA-IPFIX<https://www.iana.org/assignments/ipfix>] but it allows a very 
limited number of exceptions to be reported from the system (6-bit reason code)
But at the same time, you just present a couple of entries in your table 3

++--+

| Forwarding |   Reason |

| Exception Code |  |

++--+

|   1| FIREWALL_DISCARD |

|   2| TTL_EXPIRY   |

|   3| DISCARD_ROUTE|

|   4| BAD_IPV4_CHECKSUM|

|   5| REJECT_ROUTE |

|   6| BAD_IPV4_HEADER (Version incorrect or IHL < 5)|

|   7| BAD_IPV6_HEADER (Version incorrect)  |

|   8| BAD_IPV4_HEADER_LENGTH (V4 frame is too short)   |

|   9| BAD_IPV6_HEADER_LENGTH   |

|   10   | BAD_IPV6_OPTIONS_PACKET(too many option headers) |

|   ..   | ..   |

++--+

   Table 3: Forwarding Status Codes




If I look at the series of Dropped Reason for IPFIX IE ForwardingStatus, at 
https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status, this list 
is even more complete.
Binary [https://www.iana.org/assignments/_support/sort_none.gif]
Hex [https://www.iana.org/assignments/_support/sort_none.gif]
Description [https://www.iana.org/assignments/_support/sort_none.gif]
Reference [https://www.iana.org/assignments/_support/sort_none.gif]
10 00b
0x80
Unknown
[RFC7270<https://www.iana.org/go/rfc7270>]
10 01b
0x81
ACL deny
[RFC7270<https://www.iana.org/go/rfc7270>]
10 10b
0x82
ACL drop
[RFC7270<https://www.iana.org/go/rfc7270>]
10 11b
0x83
Unroutable
[RFC7270<https://www.iana.org/go/rfc7270>]
10 000100b
0x84
Adjacency
[RFC7270<https://www.iana.org/go/rfc7270>]
10 000101b
0x85
Fragmentation and DF set
[RFC7270<https://www.iana.org/go/rfc7270>]
10 000110b
0x86
Bad header checksum
[RFC7270<https://www.iana.org/go/rfc7270>]
10 000111b
0x87
Bad total Length
[RFC7270<https://www.iana.org/go/rfc7270>]
10 001000b
0x88
Bad header length
[RFC7270<https://www.iana.org/go/rfc7270>]
10 001001b
0x89
bad TTL
[RFC7270<https://www.iana.org/go/rfc7270>]
10 001010b
0x8A
Policer
[RFC7270<https://www.iana.org/go/rfc7270>]
10 001011b
0x8B
WRED
[RFC7270<https://www.iana.org/go/rfc7270>]
10 001100b
0x8C
RPF
[RFC7270<https://www.iana.org/go/rfc7270>]
10 001101b
0x8D
For us
[RFC7270<https://www.iana.org/go/rfc7270>]
10 001110b
0x8E
Bad output interface
[RFC7270<https://www.iana.org/go/rfc7270>]
10 00b
0x8F
Hardware
[RFC7270<https://www.iana.org/go/rfc7270>]
0x90-0xBF
Unassigned
Status 11b: Consumed

If this list is not complete, we should update it with some additional drop 
reasons, as opposed to define yet a new overlapping IPFIX IE... Especially at 
the time where we try to clean up the IPFIX registry.
Note: I know of at least two vendors that implemented forwardingStatus.

Regarding forwardingNextHopID, we already have a series of nexthop-related 
IPFIX IE. As a matter of fact, even the IPv4 and IPv6 are different IPFIX IEs 
in the IANA registry (whether this is right or wrong is irrelevant, that was a 
decision taken years ago)

Therefore, I am afraid I can't support WG adoption of this draft.

Regards, Benoit

On 11/6/2023 3:56 PM, Venkata Naga Chaitanya Munukutla wrote:
Hello OPSAWG experts,

We've posted version v08 for IPFIX Extensions for Forwarding Exceptions (minor 
editorial changes).
https://datatracker.ietf.org/doc/draft-mvmd-opsawg-ipfix-fwd-exceptions/08/

The document has been stable for a while and we believe it is sufficiently 
baked to be considered for WG adoption. The las

Re: [OPSAWG] ipfix-fwd-exceptions - Request WG adoption

2023-11-14 Thread Benoit Claise 

Dear Chaitana,

If finally read the draft.

You mentioned:

   There is an existing IE 89 - forwardingStatus[IANA-IPFIX
   ]but it allows a very
   limited number of exceptions to be reported from the system (6-bit
   reason code)

But at the same time, you just present a couple of entries in your table 3

++--+ | 
Forwarding | Reason | | Exception Code | | 
++--+ | 
1 | FIREWALL_DISCARD | | 2 | TTL_EXPIRY | | 3 | DISCARD_ROUTE | | 4 | 
BAD_IPV4_CHECKSUM | | 5 | REJECT_ROUTE | | 6 | BAD_IPV4_HEADER (Version 
incorrect or IHL < 5)| | 7 | BAD_IPV6_HEADER (Version incorrect) | | 8 | 
BAD_IPV4_HEADER_LENGTH (V4 frame is too short) | | 9 | 
BAD_IPV6_HEADER_LENGTH | | 10 | BAD_IPV6_OPTIONS_PACKET(too many option 
headers) | | .. | .. | 
++--+ 
Table 3: Forwarding Status Codes




If I look at the series of Dropped Reason for IPFIX IE ForwardingStatus, 
at https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status, 
this list is even more complete.


Binary  Hex Description Reference
10 00b  0x80Unknown [RFC7270 
]
10 01b  0x81ACL deny[RFC7270 
]
10 10b  0x82ACL drop[RFC7270 
]
10 11b  0x83Unroutable  [RFC7270 
]
10 000100b  0x84Adjacency   [RFC7270 
]
10 000101b 	0x85 	Fragmentation and DF set 	[RFC7270 
]
10 000110b 	0x86 	Bad header checksum 	[RFC7270 
]
10 000111b 	0x87 	Bad total Length 	[RFC7270 
]
10 001000b 	0x88 	Bad header length 	[RFC7270 
]

10 001001b  0x89bad TTL [RFC7270 
]
10 001010b  0x8APolicer [RFC7270 
]
10 001011b  0x8BWRED[RFC7270 ]
10 001100b  0x8CRPF [RFC7270 ]
10 001101b  0x8DFor us  [RFC7270 ]
10 001110b 	0x8E 	Bad output interface 	[RFC7270 
]

10 00b  0x8FHardware[RFC7270 
]

0x90-0xBF   Unassigned  


   Status 11b: Consumed


If this list is not complete, we should update it with some additional 
drop reasons, as opposed to define yet a new overlapping IPFIX IE... 
Especially at the time where we try to clean up the IPFIX registry.

Note: I know of at least two vendors that implemented forwardingStatus.

Regarding forwardingNextHopID, we already have a series of 
nexthop-related IPFIX IE. As a matter of fact, even the IPv4 and IPv6 
are different IPFIX IEs in the IANA registry (whether this is right or 
wrong is irrelevant, that was a decision taken years ago)


Therefore, I am afraid I can't support WG adoption of this draft.

Regards, Benoit


On 11/6/2023 3:56 PM, Venkata Naga Chaitanya Munukutla wrote:


Hello OPSAWG experts,

We've posted version v08 for IPFIX Extensions for Forwarding 
Exceptions (minor editorial changes).


https://datatracker.ietf.org/doc/draft-mvmd-opsawg-ipfix-fwd-exceptions/08/ 



The document has been stable for a while and we believe it is 
sufficiently baked to be considered for WG adoption. The last time we 
presented this draft (IETF116), there seemed to be a reasonable amount 
of interest in the work (as captured in the meeting notes 
--https://notes.ietf.org/notes-ietf-116-opsawg 
).


We would like to invite more feedback on this document and also 
formally request WG adoption.


Thanks,

Chaitanya (on behalf of co-authors/contributors)


Juniper Business Use Only


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

Re: [OPSAWG] ipfix-fwd-exceptions - Request WG adoption

2023-11-06 Thread Thomas.Graf 
Dear Chaitanya,

Thanks a lot for the updated document. As previously stated, as a network 
operator, I value contributions describing reasons why packets are being 
dropped.

I reviewed the latest document revision and have the following comments:

Looking at 
https://datatracker.ietf.org/doc/html/draft-mvmd-opsawg-ipfix-fwd-exceptions-08#section-4.2.1
 and comparing to https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12, the 
listed examples in table 3 are rather generic and do not justify to be 
enterprise and could or even should be IANA. I support that IE89 
ForwardingStatius reason codes are being added, and your provided list is a 
good starting point, 
https://datatracker.ietf.org/doc/html/draft-opsawg-evans-discardmodel#name-information-model
 has also some interesting input to be considered.

Regarding 
https://datatracker.ietf.org/doc/html/draft-mvmd-opsawg-ipfix-fwd-exceptions-08#section-4.2.2,
 I welcome that the author detailed the meaning of the entity. As I commented 
in with the -02 review, it was not clear how it differentiates to

IE15  ipNextHopIPv4Address
IE18  bgpNextHopIPv4Address
IE62  ipNextHopIPv6Address
IE63  bgpNextHopIPv6Address
IE47  mplsTopLabelIPv4Address

Reading now the section, I understood that the authors try to capture the 
exception of a hierarchical lookup failure. Is that correct?

Reading 
https://datatracker.ietf.org/doc/html/draft-mvmd-opsawg-ipfix-fwd-exceptions-08#section-4.2.3,
 I understand that you would like to gain insights at which level of the 
hierarchical lookup the failure occurred. Correct?

Reading 
https://datatracker.ietf.org/doc/html/draft-mvmd-opsawg-ipfix-fwd-exceptions-08#section-4.2.4,
 I did not understood the difference to IE252 ingressPhysicalInterface. My 
expectation is that if sampling is being applied to a logical LACP interface 
that with IE252 the physical interface ifindex where the packet is being 
received is exported and with IE10 ingressInterface the logical LACP ifindex.

Best wishes
Thomas

From: OPSAWG  On Behalf Of Venkata Naga Chaitanya 
Munukutla
Sent: Monday, November 6, 2023 3:56 PM
To: opsawg@ietf.org
Cc: Shivam Vaid ; Vishnu Pavan Beeram 
; Aditya Mahale ; 
pateldev...@google.com
Subject: [OPSAWG] ipfix-fwd-exceptions - Request WG adoption

Hello OPSAWG experts,

We've posted version v08 for IPFIX Extensions for Forwarding Exceptions (minor 
editorial changes).
https://datatracker.ietf.org/doc/draft-mvmd-opsawg-ipfix-fwd-exceptions/08/

The document has been stable for a while and we believe it is sufficiently 
baked to be considered for WG adoption. The last time we presented this draft 
(IETF116), there seemed to be a reasonable amount of interest in the work (as 
captured in the meeting notes -- https://notes.ietf.org/notes-ietf-116-opsawg) .

We would like to invite more feedback on this document and also formally 
request WG adoption.

Thanks,
Chaitanya (on behalf of co-authors/contributors)


Juniper Business Use Only


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg